Собственно, суть вопроса в названии темы. Есть ли в ИАРЕ какие нибудь нормальные способы определить конец таблицы векторов. Необходимо именно после таблицы загнать некоторые константы. Я понимаю, что можно заглянуть в хедер МК, под который пишется проект, и с помощью #pragma location указать место компилятору, но хотелось бы узнать более грамотный способ, чтобы можно было портировать проект на другой МК, без лишних правок проекта...

Спасибо.

Если узнать и разместить надо на этапе компиляции - то в .xcl определить свой сегмент сразу после определения INTVEC и до остальных кодовых сегментов. В этот сегмент и поместить нужное. Если на этапе выполнения - __segment_end("INTVEC") в С и SFB(INTVEC) в асм.

Да, это работает, спасибо. Но хотелось бы, чтобы конец сегмента, или начало требуемого массива в тексте модуля *.с, а не в *.xcl , и адрес вычислялся на этапе компиляции

Можно написать сою библиотеку, которая по define чегото, подставляла бы нужные параметры для размещения Вашего сегмента. Похожие вещи видел, но сам не делал.

Думал-думал.. А отчего такое горячее желание "решить" задачу непредназначенными для этого средствами?

1.Самый "правильный" вариант - действительно завести свой сегмент и указать линкеру куда его линковать. Для решения каких-то "особенных" проблем можно передавать и линкеру и компилятору некий общий параметр (задаваемый в makefile/проекте) через командную строку.
2.Самый дубовый - добавляете свои "констанаты" прямо в файл с таблицей векторов (но см. примечание к п.3).
3.Самый "кривой" - Создаете файл c с указанием того, что результат компиляции слинковать в INTVEC (полагаю, что IAR линкер, как обычно, выполнит линковку в сегмент в порядке встретившимся ему упоминаний). Но *.xcl рожденный "автоматически" все равно править придется, ибо там скорее всего
INTVEC фиксированного размера.

А других я не знаю, да и не встречал в них когда-либо какой-либо необходимости.





Волшебное слово библиотека тут совсем не играет, как и #define, ибо размещением всего и вся за пределами кусочков сегмента ведает линкер и только линкер - вот и указанием ему что и как делать и предстоит мудрить. Мочему нужно "мудрить", вместо прямого и четкого указания - вопрос интересный.

Стоп. Вычислялся адрес или размещались данные? Для вычисления адреса вполне работает intrinsic-функция __segment_end("INTVEC"). А рулить размещением из .C можно только в одном случае: размещение констант по абсолютному адресу. Во всех остальных случаях это невозможно, ибо С с адресами не работает. Он знает только смещения в пределах перемещаемого сегмента (участка сегмента), а абсолютные адреса взамен этих смещений проставляет линкер после размещения сегмента.

Возможно имеет место неправильный подход к проблеме. Если программа не использует прерываний то INTVEC состоит из одного вектора (RESET). Далее возможны два варианта в зависимости от содержания .xcl: следующий за этим сегментом адрес будет равен двум(байтам) либо будет "дырка" на неиспользуемые вектора. Но опять же предугадать какой вариант будет в конкретном случае не смотря в .xcl невозможно.

Может вы изложите задачу более подробно, с каким-нибудь примитивным примером?

Я же сказал Про __segment_end, я знал, но мне надо, чтобы массив констант размещался именно СРАЗУ после таблицы векторов (не спрашивайте, почему мне это надо, please, так надо :-) ) . Допустим, я передал свой исходник другому человеку, а он пользуется не IAR, он включает мои сырцы в свой проект, и у него получается сами знаете что...

А ранее вопрос был:

В IARе есть. И во многих других есть. Но другие. Такие тонкости всегда интимное дело конкретного
компилятора и естественно решаются написанием "порта" под компилятор. Но это ведь уже ДРУГОЙ вопрос?

Я все понял...Значит простых путей нет...

Простых через некоторое интересное место может и нет, а стандартные для IAR методы просты - дальше некуда.
Есть средство заполнить сегмент константой (RETI) - линкер.
Есть средство разместить сегмент где угодно и как угодно - линкер.
Есть средство получить доступ из исходника куда угодно - компилятор.
Нет только средств изобретать свои правила игры.

:-)

Что Вы имеете ввиду?

Элементарно, коль скоро имеем то, что имеем.
Если уж сориентировались на ИАРовскую платформу, то почему бы не воспользоваться стандартными для ИАР средствами. Переделки, хоть и минимальные, но будут. Других способов всё равно нет и ИАР не станет, я думаю, создавать их под заказ.
Если же планируется переходить ещё и под другую среду программирования, то переделок будет ещё больше.
Здесь вся сложность именно не в языковых средствах, а в сильной аппаратной зависимости Ваших желаний. А в этом плане, как Вам уже говорили, что ни среда, то свои правила, которые кстати в определённой мере незыблемы.
Извините, если слишком сложно обьясняю.