Недокументированные возможности IAR, extended keywords __x_z, __z? Опции

[Old1]

Просматривал хидер pgmspace.h и обратил внимание на модификаторы __x_z и __z, в мануале на компилятор про их назаначение ничего не нашел (или плохо искал?...), в апликашках они тоже вроде бы не встречаются. Решил попробовать использовать их наугад, написал простенький код на С++ (описал две одинаковых функции одна с __x_z, другая без, исходный код и результат компиляции см. в присоединенных файлах), скомпилировал, оказалось что код функции с модификатором компактнее (за счет ИМХО более рационального использования регистров-указателей) и выполняется быстрей (на 30% в данном примере). Вопросы: кто, что о них (модификаторах) знает (особенности их использования)? Какие мысли есть о том, почему ИАР ничего не пишет о них ( ведь ИМХО вещ вроде бы полезная)?

Прикрепленные файлы

 modifikaori.rar ( 1.71 килобайт ) Кол-во скачиваний: 92

 

[dxp]

Просматривал хидер pgmspace.h и обратил внимание на модификаторы __x_z и __z, в мануале на компилятор про их назаначение ничего не нашел (или плохо искал?...), в апликашках они тоже вроде бы не встречаются. Решил попробовать использовать их наугад, написал простенький код на С++ (описал две одинаковых функции одна с __x_z, другая без, исходный код и результат компиляции см. в присоединенных файлах), скомпилировал, оказалось что код функции с модификатором компактнее (за счет ИМХО более рационального использования регистров-указателей) и выполняется быстрей (на 30% в данном примере). Вопросы: кто, что о них (модификаторах) знает (особенности их использования)? Какие мысли есть о том, почему ИАР ничего не пишет о них ( ведь ИМХО вещ вроде бы полезная)?

Если в объявлении функции присутствует модификатор __z, или, __x или комбинированный, то передача параметров в такую функцию будет производиться не через пару r16:17, через пару, образующую соответсвующий указатель (z или x). Особенно это рулит для функций-членов классов, в которых первым параметром всегда скрыто передается указатель this. Но есть случаи, когда так делать не выгодно, несколько лет назад спрашивал у саппорта, но уже не помню, чем они обосновали отказ от повсеместного использования такой схемы передачи параметров. Что-то типа того, что в большинстве случаев при передаче первым параметром не указателя потребуется дополнительное копирование для освобождения Z-указателя. Конечно, можно было бы сделать более гибкую схему, чтобы компилятор соображал, если указатель, то передавать его через Z, если не указатель, то через 16:17. Но до этого они не дошли, делать не стали. Считают, что и так неплохо.

Т.ч. никто не мешает использовать обсуждаемые квалификаторы. Есть только два минуса - 1) переносимость; 2) нет гарантий, что в очередной версии эти вещи не уберут или не изменят их функциональность. Хотя вероятность этого, имхо, стремится к нулю.

[IgorKossak]

Для улучшения скорости и компактности некоторых функций, особенно static, применяю эти квалификаторы.
О ни действительно в руководствах ничего нет.
Некоторые замеченные особенности:
- квалификаторы действуют только на указатели, в остальных случаях игнорируются;
- не существует квалификатора __z_x ;
- ...

[Rst7]

Для улучшения скорости и компактности некоторых функций, особенно static, применяю эти квалификаторы.
О ни действительно в руководствах ничего нет.
Некоторые замеченные особенности:
- квалификаторы действуют только на указатели, в остальных случаях игнорируются;
- не существует квалификатора __z_x ;
- ...

Cуществует и __z_x и __x_z - соответственно, как передавать первый и второй указатель.

По поводу только указателей - если очень надо, преобразуй например int в void * и передай, а потом наоборот.

На форуме "Точка опоры" я писал про недокумментированные фичи иара, всякие "__raw", "__no_return" и прочее. Поищи там, давненько дело было.

Также есть еще SBRA и CBRA - это коммады какие-то AVR, иар их может использовать. Что за хрень - не знаю.

[IgorKossak]

...По поводу только указателей - если очень надо, преобразуй например int в void * и передай, а потом наоборот.

В том то и дело, что кроме головной боли такие преобразования не принесут, а выигрыша никакого.

На форуме "Точка опоры" я писал про недокумментированные фичи иара, всякие "__raw", "__no_return" и прочее. Поищи там, давненько дело было.

Хорошие фичи, применяю.
__raw - в прерываниях, обслуживаемых ОСРВ (там свои функции сохранения/восстановления контекста);
__no_return - в бутлоадере (немного сокращает размер).

Также есть еще SBRA и CBRA - это коммады какие-то AVR, иар их может использовать. Что за хрень - не знаю.

Ни в стандартном, ни в расширенном наборе (по крайней мере для ATmega) таких инструкций нет. Что имели в виду ИАРовцы - не понятно.

[dxp]

Хорошие фичи, применяю.
__raw - в прерываниях, обслуживаемых ОСРВ (там свои функции сохранения/восстановления контекста);

А что в EWAVR тоже __raw включили? В 4.10А я специально смотрел, не было там (не нашел ни в доке, ни в перечне ключей компилятора).

[Old1]

А что в EWAVR тоже __raw включили? В 4.10А я специально смотрел, не было там (не нашел ни в доке, ни в перечне ключей компилятора).

В 4.11А точно есть, и (как выяснилось ) даже документирован, правда в самом мануале на компилятор про этот квалификатор ничего нет, а вот в файлах ...\avr\doc\iccavr.htm и ...\avr\doc\manuals.htm он описан... Смутно вспоминаю, что ранее кто-то здесь задавал вопрос: как отключить сохранение регистров в функции обслуживания прерывания если в ней вызывается функция... теперь появилась возможность сделать это корректно...

[ig_z]

Как то пытался переписывать порты под вытесняющие ОСи на чистом С в иар для мсп430.
__no_return не оказывает никакого эффекта. Т.е. компилятор не ругается, но и рет не подавляет.
Плюс __interrupt разрешают применять только для обработчиков прерываний, так что красота не получается пока

__no_return - в бутлоадере (немного сокращает размер).

Подавляет ret, тем самым позволяет на С создавать конструкции типа "несколько точек входа на одну точку выхода", я правильно понимаю?
И почему в бутлоадере? Это как-то связанно с АВР или больше нигде не возникает необходимость в подобном механизме?

[Rst7]

.....
Подавляет ret, тем самым позволяет на С создавать конструкции типа "несколько точек входа на одну точку выхода", я правильно понимаю?
И почему в бутлоадере? Это как-то связанно с АВР или больше нигде не возникает необходимость в подобном механизме?

Подавляет не ret. Подавляет сохранение регистров. Но как-то отличается от __root. Особо не разбирался.

По поводу гемороя с передачей значений как указатели. Используя такой метод (с __x_z) можно за раз передать в функцию не 8 (R16-R23), а 12 (R16,R23,X,Z) байт БЕЗ ИСПОЛЬЗОВАНИЯ СТЕКА. В некоторых случаях очень удобно и позволяет повысить производительность. Единственное, нельзя сделать функцию с _z в любой комбинации, если используется вызов данной функции по указателю.

[Old1]

Подавляет не ret. Подавляет сохранение регистров. Но как-то отличается от __root. Особо не разбирался.

Непонятно (по поводу __noreturn), если я правильно перевел, этот квалификатор указывает компилятору, что программа после выполнения функции не возвращается к точке ее вызова (если я не прав поправьте), в этом случае ИМХО функция уже вроде как не функция (заметил, что после добавления __noreturn переход на функцию осуществляется при помощи RJMP) и как следствие регистры уже не сохраняются (но это вторично)... И какое отношение __root имеет к сохранению регистров?

[IgorKossak]

Подавляет ret, тем самым позволяет на С создавать конструкции типа "несколько точек входа на одну точку выхода", я правильно понимаю?

Не правильно. Это лишь означает, что функция не будет иметь возврата, а значит, что не нужно сохранять контекст в начале и восстанавливать его в конце (т. к. конца функции нет). Это обычно функция main().

И почему в бутлоадере? Это как-то связанно с АВР или больше нигде не возникает необходимость в подобном механизме?

Бутлоадер желательно впихнуть в как можно меньшую область из 8, 4, 2, 1 кБайт.
Поэтому экономия на сохранении\восстановлении контекста может в этом помочь.

[zltigo]

а значит, что не нужно сохранять контекст в начале и восстанавливать его в конце (т. к. конца функции нет). Это обычно функция main().

Заманчиво было :-(, кроме main() это еще все 'задачи'. Попробовал __noreturn и __root на
IAR ARM ANSI C/C++ Compiler V4.30A-P050906/W32
Слова худого не сказал в ответ, но и не сделал абсолютно ничего - сохранение контекста
осталось :-(. Похоже было, но похерено.

Сообщение отредактировал zltigo - Dec 19 2005, 12:02

[IgorKossak]

Для задач я обычно применяю __task.
Помогает однозначно.
Что касается __root, то он скорее предназначен для переменных, оптимизация которых нежелательна.

[ig_z]

Подавляет не ret. Подавляет сохранение регистров. Но как-то отличается от __root. Особо не разбирался.

Непонятно (по поводу __noreturn), если я правильно перевел, этот квалификатор указывает компилятору, что программа после выполнения функции не возвращается к точке ее вызова (если я не прав поправьте), в этом случае ИМХО функция уже вроде как не функция (заметил, что после добавления __noreturn переход на функцию осуществляется при помощи RJMP) и как следствие регистры уже не сохраняются (но это вторично)... И какое отношение __root имеет к сохранению регистров?

Очень странно. Какой у вас компилер и версия?
У меня мсп430 3.30

итак:
__raw и __task подавляют сохранение/восстановление регистров в для "прерывательных" и "обычных" функций
__interrupt -заменяет рет на ирет
__root обязывает компилятор/линкер включать функцию в объектный/бинарный файл, даже если на нее нет ни одной ссылки
__noreturn keyword can be used on a function to inform the compiler that the function will not return. Т.е. не будет возврата из функции - будет выполняться следующий по порядку оператор. О подавлении/сохранении регистров ни слова. Точно так же очень сомнительно выглядит вызов функции по jmp. По крайней мере мсп430 3.30 вызывает __noreturn функцию через call. Чесно предупреждает, что больше не сможет вернуться в точку вызова . Но т.к. не подавляет ret в вызываемой функции, благополучно возвращается в точку вызова

На мсп430 3.30 __noreturn не делает ничего. Т.е. ret не подавляется, а регистры сохраняются. Все остальные extended keywords работают корректно.

[zltigo]

Очень странно. Какой у вас компилер и версия?
У меня мсп430 3.30

итак:
__raw и __task подавляют сохранение/восстановление регистров в для "прерывательных" и "обычных" функций
__interrupt -заменяет рет на ирет
__root обязывает компилятор/линкер включать функцию в объектный/бинарный файл, даже если на нее нет ни одной ссылки
__noreturn keyword can be used on a function to inform the compiler that the function will not return. Т.е. не

Эксперимент:
IAR ARM ANSI C/C++ Compiler V4.30A-P050906/W32
__raw и __task - знать не знает, ведать не ведает таких :-(. Ругается долго и мучительно (вообще с локализацией ошибки IAR далеко не в первых рядах).
__interrupt - тоже не знает, но не беда, ибо __irq имеет место быть...
__root - не ругается, ну может и работает, как описано
__noreturn - не делает ничего.

[Old1]

Очень странно. Какой у вас компилер и версия?
У меня мсп430 3.30

Компилятор IAR EWAVR 4.11A

итак:
__raw и __task подавляют сохранение/восстановление регистров в для "прерывательных" и "обычных" функций
__interrupt -заменяет рет на ирет

тут все понятно...

__root обязывает компилятор/линкер включать функцию в объектный/бинарный файл, даже если на нее нет ни одной ссылки

не только функции но и переменные...

__noreturn keyword can be used on a function to inform the compiler that the function will not return. Т.е. не будет возврата из функции - будет выполняться следующий по порядку оператор. О подавлении/сохранении регистров ни слова. Точно так же очень сомнительно выглядит вызов функции по jmp. По крайней мере мсп430 3.30 вызывает __noreturn функцию через call. Чесно предупреждает, что больше не сможет вернуться в точку вызова . Но т.к. не подавляет ret в вызываемой функции, благополучно возвращается в точку вызова

На мсп430 3.30 __noreturn не делает ничего. Т.е. ret не подавляется, а регистры сохраняются. Все остальные extended keywords работают корректно.

Поделюсь результатами своих экспериментов. Программа выполняет тело функции __noreturn а затем выполняет инструкцию RET функции из которой была вызвана ф-ция __noreturn, все что было между функцией __noreturn и RET игнорируется. Причем если функция __noreturn (по какой-то причине) описана как возвращающая значение, она это значение вычисляет, но не возвращает (это логично, поскольку после выполния функции, возврата к точке вызова нет). Переход на выполнение __noreturn функции осуществляется при помощи инструкции RJMP (или JMP). Например:

Код

unsigned char A=10, B=0;
__noreturn unsigned char Funk10(unsigned char V1)
{
  return(V1+3);
}

void Funk8(void)
{
  A+=10;
  return;
}

void Funk9(void)
{
  B+=2;
  A=Funk10(23);
  Funk8();//это не выполняется
  --B;//и это тоже
}

В результате выполнения Funk9 имеем A=10, В=2...
Заметил, что при включенном режиме оптимизации Function inlining все выполняется как будто __noreturn нет в природе, но это, думаю, от того, что все функции у меня были определены в одном модуле (и они выполнялись как inline-функции), как только функцию __noreturn определил в отдельном модуле все стало на свои места...
Если __noreturn-функцию вызвать непосредственно внутри функции main то все работает как описано выше, если __noreturn-функция определена как void, и внутри main нет бесконечного цикла, в противном случае компилятор выдает ошибку...
В результате пришел к выводу, что механизм выполнения __noreturn-функции сводится к следующему: выполняется тело __noreturn-функции функции (без RET), после этого инструкция RET функции непосредственно внутри которой вызвана __noreturn-функция...
З.Ы. Насчет подавления сохранения регистров: если __interrupt-функцию сделать еще и __noreturn, то регистры не сохраняются, и по крайней мере чисто внешне все выглядит так же как при использовании __raw...

[Rst7]

Да, господа, по поводу __root прогнал. Конечно, __noreturn не имеет отношения к __root. Я больше имел в виду __task. Для EWAVR отличия вот в чем. __noreturn не сохраняет контекст. __task также не сохраняет контекст, но если вы вызываете процедуру с __task, контекст сохраняется в ВЫЗЫВАЮЩЕЙ процедуре. Точнее, даже не контекст сохраняется, а вызывающая процедура устраивается так, чтобы не зависеть от изменения контекста.

[dxp]

Эксперимент:
IAR ARM ANSI C/C++ Compiler V4.30A-P050906/W32
__raw

Это ключевое слово было введено изначально только в пакет EW430 исключительно по личной просьбе. До него в версиях пакета до 2.20 включительно эту функциональность выполняло сочетание __task __interrupt (выглядит забавно-шокирующе, но работало), в дальнейшем в версии 2.21 такое сочетание было запрещено по идеологическим причинам (что, в общем, правильно). Но поскольку потребность в выполняемой ими функциональности никуда не делась, то в версиях 3.хх появилось новое слово __raw (еще рассматривался вариант __naked, как в ГНУтых компиляторах, но IAR'овцы открестились от него - gcc наиболее серьезный конкурент их продуктам). Такова вкратце история появления оного ключевого слова. Поскольку все это шло в контексте EW430, то неудивительно, что в пакетах под другие платформы такого слова нет. Возможно, это только временно. Я ожидал, что в EWAVR 4.10А это появится. Не появилось. Поэтому и удивился, когда сказали, что в 4.11[2] появилось. Видать, осознали. Т.ч. может и для АРМов тоже со временем появится. Хотя не факт.

и __task - знать не знает, ведать не ведает таких

Хм, это странно. Такое слово было всегда. Сначала оно называлось C_task. Потом __C_task. Потом привели к общему виду __task. Смысл в нем был, есть и будет всегда. Странно, если EWARM этого не имеет. Может оно там просто по-другому называется?

[zltigo]

Хм, это странно. Такое слово было всегда. Сначала оно называлось C_task. Потом __C_task. Потом привели к общему виду __task. Смысл в нем был, есть и будет всегда. Странно, если EWARM этого не имеет. Может оно там просто по-другому называется?

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

[ig_z]

Это ключевое слово было введено изначально только в пакет EW430 исключительно по личной просьбе.

Пару лет назад в переписке с Harry Zhurov впервые прочитал эту фразу.
Да и по вашим ответам складывалось впечатление что это вы и есть. Я прав?

[dxp]

Да и по вашим ответам складывалось впечатление что это вы и есть. Я прав?

Вам бы аналитиком в контрразведке работать. Ни один шпион бы мимо не прошел.

[IgorKossak]

Да и по вашим ответам складывалось впечатление что это вы и есть. Я прав?

Вам бы аналитиком в контрразведке работать. Ни один шпион бы мимо не прошел.

Это ж надо!!!
Сколько переписывался с Harry Zhurov, а в лицо то и не узнал!!!

[dxp]

Это ж надо!!!
Сколько переписывался с Harry Zhurov, а в лицо то и не узнал!!!

Я Вас тоже смог идентифицировать только после того, как Вы у меня сорцы библиотек из EWAVR 4.хх спросили (у меня не оказалось), а потом этот же вопрос на форуме задали. Тут-то я и сообразил, кто у нас модератор.

[ig_z]

2 dxp
scmRTOS планируете развивать?
Интересно было бы видеть отладочные фичи. Типа мюкосвью. И какой нибудь генератор orti файла для дебугера. Мои эксперименты к сожалению продвигаются очень медленно

[dxp]

2 dxp
scmRTOS планируете развивать?
Интересно было бы видеть отладочные фичи. Типа мюкосвью. И какой нибудь генератор orti файла для дебугера. Мои эксперименты к сожалению продвигаются очень медленно

Ничего определенного сказать не могу. Проект некоммерческий, делается в свободное время, которого что-то все меньше и меньше. Пока в планах две задумки, одна - в связи с появлением __raw в EWAVR, другая помасштабнее (подробности не хочу пока раскрывать, связано с механизмом перепланировки). В скором времени подойдет работа с процом, на ней и обкатаю.

Что касается отладки, то не очень понимаю, что там нужно. Вещица очень простая, прозрачная, чего там, собсно, отлаживать. Если только написать монитор, к нему интерфейс и ГУИ на ПК, чтобы смотреть загрузку процессов... Не знаю, такая работа сама по себе достаточно трудоемка, а смысла в ней большого, имхо, нет. К тому же, такой монитор внесет тормозов, во всяком случае его оверхед будет соизмерим с оверхедом самой RTOS. Поскольку главный смысл этой RTOS - получить максимальное быстродействие при минимальных накладных расходах (а также максимальную простоту использования), то любая сколько-нибудь посторонняя фишка в той или иной степени нивелирует эту самую основную идею. Т.ч., исходя из перечисленных причин, даже не задумывался об каких-то специальных средствах отладки.

[Turion]

По поводу инструкций SBRA и CBRA - попробуйте в www.google.com
набрать SBRA CBRA instructions avr и посмотрите сохраненные в кэше
результаты по первой ссылке.
Вкратце это инструкции ядра SecureAVR версии AVR3+, информацию по ним
достать очень тяжело, т.к. Atmel ее дает при подписании соглашения о нераспостранении.
Сохраненная страница гласит:

SBRA - Set bit in RAM

Operation: RAM(A,В) <- 1
Syntax: SBRA A,b
Operand: 0<= A <= 15, 0<= b <= 7
Program Counter: PC <- PC+1
16-bit Opcode: 1001 001A AAAb 01bb


example:
sbra 14,0 ; Sets bit 0 in the RAM adress $xxx + $0E ($xxx depends on MCU)

CBRA - Clear bit in RAM
same as above but with Opcode: 1001 00AA AAbb b011

Сообщение отредактировал Turion - Dec 27 2005, 12:32

[Old1]

Вот еще один квалификатор (или атрибут типа функции): __version_3. Узнал о нем получив вот такое сообщение об шибке: Error[Ta027]: Cannot combine function type attributes '__x_z' and '__version_3'... Кто-нибудь знает, что за атрибут такой?

[Rst7]

Вот еще один квалификатор (или атрибут типа функции): __version_3. Узнал о нем получив вот такое сообщение об шибке: Error[Ta027]: Cannot combine function type attributes '__x_z' and '__version_3'... Кто-нибудь знает, что за атрибут такой?

Хм, странно, я так понял, что __version_3 - это как раз по умолчанию. А поподробней, где ты нарыл применение этого модификатора?

[Old1]

Вот еще один квалификатор (или атрибут типа функции): __version_3. Узнал о нем получив вот такое сообщение об шибке: Error[Ta027]: Cannot combine function type attributes '__x_z' and '__version_3'... Кто-нибудь знает, что за атрибут такой?

Хм, странно, я так понял, что __version_3 - это как раз по умолчанию. А поподробней, где ты нарыл применение этого модификатора?

О применении его я, как раз, ничего не знаю, потому и спрашиваю. А узнал о нем из сообщения об ошибке (см. выше) после того как пытался скомпилировать код (см. аттачмент). Если подробнее, то ошибка выскакивает при попытке инициализации массива указателей на функции, при определении которых я пытался использовать квалификатор __z_x. Если этот самый __z_x убрать, то все нормально компилируется. Возможно проблема в нестытковке определения типа указателя на функции и определении самих функций...

Прикрепленные файлы

 main.rar ( 600 байт ) Кол-во скачиваний: 45

 

[Rst7]

...
О применении его я, как раз, ничего не знаю, потому и спрашиваю. А узнал о нем из сообщения об ошибке (см. выше) после того как пытался скомпилировать код (см. аттачмент). Если подробнее, то ошибка выскакивает при попытке инициализации массива указателей на функции, при определении которых я пытался использовать квалификатор __z_x. Если этот самый __z_x убрать, то все нормально компилируется. Возможно проблема в нестытковке определения типа указателя на функции и определении самих функций...

Нельзя при использовании модификатора с _z использовать вызов функции по указателю, т.к. IJMP имеет адрес в Z. Идея ясна?

[Old1]

Нельзя при использовании модификатора с _z использовать вызов функции по указателю, т.к. IJMP имеет адрес в Z. Идея ясна?

Ну...если быть точным то не IJMP, а ICALL... Похоже, что так оно и есть, при вызове функции по указателю Z занят (и Х тоже используется). Для меня странно другое: в других случаях, если компилятор считал, что применение квалификаторов с _z и _х недопустимо (или нерационально?), он их игнорировал (по крайней мере в результате экспериментов я пришел к такому выводу), а здесь выдает ошибку...
И все таки неясно, что за атрибут __version_3?

[Old1]

Если кому интересно, в версии ИАР 4.20а атрибуты __x, __z __x_z, __z_x уже документированы (см. avr/doc/iccavr.htm):

Miscellaneous
...
__x, __z __x_z, __z_x
The compiler defines the function type attributes __x, __z __x_z, and __z_x which are used by parts of the runtime library. These attributes can give very efficient code in a local perspective, but should be used with care as they change the calling convention and may have a negative effect on the size of the entire application.

Keyword
Description

__x The first pointer in the parameter list is placed in register X
__z The first pointer in the parameter list is placed in register Z
__x_z The first pointer in the parameter list is placed in register X and the second one in register Z
__z_x The first pointer in the parameter list is placed in register Z and the second one in register X

[_Bill]

Также есть еще SBRA и CBRA - это коммады какие-то AVR, иар их может использовать. Что за хрень - не знаю.

Ни в стандартном, ни в расширенном наборе (по крайней мере для ATmega) таких инструкций нет. Что имели в виду ИАРовцы - не понятно.

Вчера мне ответили на "Телесистемах" cbra/sbra

[PrSt]

Cуществует и __z_x и __x_z - соответственно, как передавать первый и второй указатель.
По поводу только указателей - если очень надо, преобразуй например int в void * и передай, а потом наоборот.
На форуме "Точка опоры" я писал про недокумментированные фичи иара, всякие "__raw", "__no_return" и прочее. Поищи там, давненько дело было.
Также есть еще SBRA и CBRA - это коммады какие-то AVR, иар их может использовать. Что за хрень - не знаю.

Да, да, знаю - эта тема уже давно гремучий баян(2005г) и подняда с анала истории, но вот только щас наткнулся... ))

Дима, сегодня разбирал твой AVR код от NikeE и напоролся на __x_z - раньше ни когда не встречал, это было как выстрел в лоб
я так и не нашел твою статью на какойто там "Точка опоры", даже сайта не нашел. А так хотелось...

Хочу уточнить(это вопрос) - На сколько я понял из всего тут написанного то если в АВРке не использовать этот самый __x_z(и ему подобные модификаторы) то просто будет менее оптимальный код и соответсвенно медленее исполняться. Я всё верно понял?

[Rst7]

Хочу уточнить(это вопрос) - На сколько я понял из всего тут написанного то если в АВРке не использовать этот самый __x_z(и ему подобные модификаторы) то просто будет менее оптимальный код и соответсвенно медленее исполняться. Я всё верно понял?

Да.

[grand1987]

Здравствуйте, у меня есть вопрос подобный тем что обсуждались в этой ветке :

при помощи какого атрибута/прагмы можно указать ИАР-овскому компилятору для ARM не добавлять сохранение/восстановление контекста для функции/прерывания, т.е. аналог __attribute__((naked)) в GCC.

Пробовал __task - никакого эффекта.

Использую бесплатную версию среды (EWARM 7.10, IAR C/C++ Compiler for ARM (7.10.1.6676)), с ограничение до 32КБ.
Заранее благодарю.

Сообщение отредактировал grand1987 - Mar 15 2014, 13:31

[dxp]

Здравствуйте, у меня есть вопрос подобный тем что обсуждались в этой ветке :

при помощи какого атрибута/прагмы можно указать ИАР-овскому компилятору для ARM не добавлять сохранение/восстановление контекста для функции/прерывания, т.е. аналог __attribute__((naked)) в GCC.

Пробовал __task - никакого эффекта.

Использую бесплатную версию среды (EWARM 7.10, IAR C/C++ Compiler for ARM (7.10.1.6676)), с ограничение до 32КБ.
Заранее благодарю.

У IAR такое есть только для AVR, называется - __raw (если ещё не убрали). Было добавлено давно по специальной просьбе. В других компиляторах IAR нет (видимо, никто не просил). Вроде так, если я не отстал от жизни.