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

нет такого

Это потому, что у AVR регистров явный избыток. Полемика на эту тему уже была на форуме неоднократно.
У ARM регистров не так много и они более функциональны. Если же необходимость выделения регистра связана с нехваткой быстродействия, то Вы, на мой взгляд, ошиблись камнем, выбирайте что-нибудь побыстрее.

Вообще-то актуальность отнятия регистров возникает в основном для быстрой работы процедур обработки прерывания. Стоит вспомнить, что в архитектуре ARM7/9 в режиме FIQ банкируются регистры R8-R14. Стек FIQ можно не пользовать (освобождается R13), R14 хранит адрес возврата (так уж и быть, пусть будет занят), итого есть 6 регистров. Вполне.

Вообще очень странно что у IAR для ARM нет блокирования регистров.
У RVCT и GCC есть. Причем если взять родной ARM документ по calling conversion, там есть рекомендации какие регистры можно блокировать и сколько.
Например для ARM7 Atmel использовать режим ARM смысла нет ( из-за медленной флеш), а регистры R8-R11 IAR обычно не использует вообще в режиме THUMB их было бы удобно зарезервировать для контекста или ...

Да ничего странного. Слишком мало регистров.



Очень спорное утверждение.



Вы имеете в виду этот документ - http://infocenter.arm.com/help/topic/com.a...0042C_aapcs.pdf ?

Что-то в нем не видать рекомендаций по блокированию регистров. Ну кроме platform-specific R9 usage.

На максимальной частоте для ARM режима один WAIT state у атмела.
получается при опреациях с регистрами инструкция THUMB будет выполняться в 2 раза быстрее!
У NXP где то видел что в среднем ARM код процентов на 30 быстрее, но THUMB код процентов на 70 плотнее.
Но у NXP флеш не вносит задержки.
В свое время IAR компилер генерировал самый лучший THUMB код и atmel рекомендовал сам THUMB использовать что бы задержек не было.


Ну да там только названия регистров, и про R9 написано. его надо вместе с докой на RVCT читать там написано сколько регистров для какого режима можно заблокировать.

Ну, если учесть их 4x ширину, то не очень-то и мало . Но основная причина это именно наличие банков регистров.

Да. Просто Автор смотрит через призму работы c восьмью битами данными и видит много "лишнего" в 32bit формате команды.




Только таких инструкций будет в 3 раза больше .

Если брать обычный код - то по статистике не в 3 раза больше, а менее чем в 1.5

У всех разная статистика. Вот например отсюда:
http://winarm.scienceprog.com/arm-mcu-type...of-arm-mcu.html

Как более-менее атомарной единицы хранения данных - маловато. Извраты типа 4 переменных типа uint8 в одном регистре рассматривать смысла нет.



Дык правильно тогда формулируйте. Ваш исходный посыл:

Причем тут дока на RVCT к официальному документу ARM? Другое дело, что компилятор RVCT позволяет отнять столько-то таких-то регистров.



Обычный код - это написанный левой ногой без оглядки на архитектуру Load/Store? Не возражаю

Я уже намекал - обычный для восьмибитовика. Как только алгоритм начинает работать с размерностями более 8bit - шеснадцатибитовые ограничения начинают сказываться очень сильно. Попробуйте, например, просто загрузить в регистр значение 0x100 и посмотрите на результат в разных режимах. Да и сложные констукции

компиляторы уже умееют укладывать в что-то типа одной команды
eqadds r1, r2, r3, lsl #2
В свое время лично подробно проверял - портировал с 16битовиков несколько исходников - пролет у TUMB полный. Если изначельно сильно заточенное под 8bit портировать, то картина много благостнее. Но если писать именно в рассчете на 32bit контроллеры, то бессмысленно - выигрыш по размеру стремится к полному 0, а производительнось падает отнюдь не "незначительно".

дока на RVCT - тоже официальный документ ARM и в ней не указаны имена регистров ( как R0, R8....) а указаны как a1, v5...


обычный - это, например, не расчет какого нибудь фильтра...
В том то и дело что у ARM архитектура Load/Store и все компилеры это учитывают.
И есть официальная статисика из разных источников.

Кого тогда трогает оптимизация?



Да, только программеры не учитывают. Вместо того, чтобы, например, в начале функции (или функционального блока) загрузить все в локальные переменные, а потом в конце выгрузить - занимаются онанизмом по месту хранения переменных.



На компилятор, но не на ядро!

Одно радует - THUMB2 решает эти проблемы с выбором режима.

Но если вернуться к теме топика. Очень странно что у IAR нет блокировки регистров! Потому что и у GCC и у RCVT они есть и переменную в заблокированном регистре можно объявить.

Можно. Но не нужно Нужно курить про банки регистров в режиме FIQ и крепко думать, зачем нужна переменная в регистре для обычного режима.

А причем здесь банки и FIQ?
С FIQ и банками все понятно - убыстряет прерывание за счет того, что не надо регистры в стек пихать и переменные локальные именно для прерывания хранить и то только для FIQ. А в Cortex уже нет никаких банков!

А вот для передачи данных между прерыванием и задачей. Для хранения указателя TCB на текущую задачу как раз и удобно блокировать регистр. Тем более что как раз R9 и можно использользовать как TR (thread register)

Извините, но это - бред. Выигрыш от удаления пары LDR/STR указателя на TCB никак не может пересилить отнятие полноценного регистра у компилятора.



И это серьезнейший минус.

В 99,999% Вашей задаче зачем-то быстро-быстро получившей информацию в регистре много полезнее будет иметь "лишний" регистр для быстрой обработки сией информации. Тем более быстро она об изменении этого волшебного региста и не узнает. Но обычно чего-нибудь ускоряя всеми силами гораздо о более суровых вещах "забывают"






Разумеется - у продавцов товара всегда другая , я уже конкретный писатель конкретных вещей а не попугае и членомеров.



Так ядро M0/M3 и делалось, как БОЛЕЕ простое и дальше теснящее восьмибитовики, За счет упрощения стало дешевле и попугаистее ( особенно на "попугаемерах" ) - вот и хит сезона.

"...Первое правило оптимизации: не оптимизируйте.
Второе правило оптимизации(только для экспертов): не оптимизируйте ни в коем случае.
Семь раз отмерь, один раз оптимизируй..."
Саттер, Александреску. Стандарты программирования на С++.

Очередной афтар книг в стиле "Крутая оптимизация для чайников" и "Сто советов по домоводству"... КГ/АМ, извините за сленг.

Без вариантов