Satyr писал(а):Признаки какого арма ? АРМы - это отнюдь не только app-процессоры для установки winCE/linux'а.
ARM7TDMI поддерживал и Thumb, и нативный режим, а что толку ? На кортексах Thumb2 оставили, т.к. шустрее и компактнее нативного кода получилось для микроконтрллерных применений.
Именно АРМа как такового. Первые три версии АРМа имели только одну систему команд -- ту, которую сейчас и называют АРМовской. Тумбу прикрутили уже позже. Оправдано или нет отказались от АРМа в Кортехах-М -- это уже другой вопрос, я лишь говорю о том, что Кортех-М -- это, по сути, уже не АРМ, а процессор другой архитектуры.
Кстати говоря, вся эта история с развитием АРМов фактически показала ошибочность изначальной концепции RISC-процессоров: использование только простых инструкций фиксированной длины в противовес "медленным и сложным" CISC'ам. Хотя само название АРМ прямо говорит, что это РИСК-архитектура, на сегодняшний день от этой концепции почти ничего не осталось. Система команд постоянно разбухала и усложнялась, ну а с появлением Тумбы-2 отказались от предпоследней особенности РИСКа -- кодирования любой команды фиксированным числом разрядов (родные АРМовские команды занимают всегда 32 бита, что часто избыточно -- вот и лишний расход памяти; команды Тумбы всегда занимают 16 бит -- а это сильно ограничивает гибкость; в итоге пришли к тому, что в Тумбе-2 применяется переменная длина команды -- 16 или 32-разряда). Последним признаком РИСК-архитектуры в АРМах остаётся только их неспособность выполнять операции регистр-память (и тем более память-память): сначала изволь всё нужное загрузить в регистры.
Ну а возвращаясь к Кортеху-М... В общем-то, использование более компактной кодировки в микро
контроллерах однозначно оправданнее. Флэш-память по сравнению с ОЗУ -- вещь медленная, поэтому вполне возможна ситуация, что алгоритмически (т.е. по числу необходимых инструкций для решения задачи) более медленная, но более компактная система команд (Тумба) на практике будет работать быстрей, чем алгоритмически более быстрая, но неэкономная в плане памяти (АРМ). Если не изменяет память, у АТМЕЛовских АРМв4 (AT91SAM7...) частота выборки из флэш-памяти была раза в два меньше, чем максимальная частота собственно процессорного ядра, причём за каждый такт из флэша выбиралось всего одно слово -- т.е. одна команда АРМ или же Тумбы. Если я прав, то получается, что эти процессоры почти за одно и то же время выполняли либо одну команду АРМ, либо две Тумбы, что, понятное дело, выгоднее. Так что ориентация именно на расширенную Тумбу в Кортехах-М вполне закономерно и оправданно. В микро
процессорах ситуация сложней. Программы там гоняют из ОЗУ, а не из флэш-памяти; кроме того, у них обычно достаточно приличный объём кэша. Тем не менее, расход этого самого кэша на громоздкую систему команд АРМ существенно выше, чем на Тумбу, поэтому не факт, что программа на АРМе будет однозначно быстрей, чем на Тумбе. Думается, тут очень сильно зависит от эффективности транслятора (ну или умений программиста, если программа пишется на ассемблере): сумеет ли он воспользоваться всей гибкостью системы команд АРМ.
Что касается сравнения АРМа и АВР8, то с технической точки зрения первый безусловно выгодней и по скорости, и по памяти. Например, простой, но часто встречающийся на практике случай: сложение или вычитание 32-разрядных целых чисел. На АВР8 в общем случае для этого потребуется 16 команд (8 загрузок из памяти, 4 сложения/вычитания, 4 записи в память), которые займут 32 байта. На АРМе -- 4 команды (2 загрузки, одно сложение/вычитание и одна запись), 16 байт. На Тумбе -- те же 4 команды, но уже 8 байт. Если рассматривать 16-разрядное сложение/вычитание, то у АВР8 число команд сократится вдвое (8 команд, 16 байт), у АРМа останется тем же самым -- 4 команды и 16/8 байт, что как минимум не хуже по памяти и уж точно лучше по скорости.
У АВР8 больше регистров (32 против реально 13 у АРМа -- ещё 3 имеют специальное назначение; у Тумбы и вовсе свободно можно использовать только
, но у АРМа они в 4 раза "толще", что при сколько-нибудь сложных расчётах безусловно предпочтительней. Кроме того, АРМовские регистры универсальнее (так, в АВР8 результат умножения всегда кладётся в R0:R1; для чтения-записи с автоинкрементом или автодекрементом можно использовать только три пары из шести последних регистров, ну и т.д.; у АРМа все 13 регистров равноправны).
В общем, получается, что программа под АРМ должна занимать меньше памяти и работать существенно быстрей. Почему на практике так получается далеко не всегда, надо разбираться. Возможно, компилятор и компоновщик тащат в выполняемый файл всё подряд, а не только то, что нужно. Может также быть, что под АВР8 используется компилятор Си, а вот АРМ -- Си++, и последний порождает кучу ненужной в данном случае фигни для ООП, обработки исключений и т.д. и т.п. В общем, надо тщательно разбираться в параметрах трансляторов и компоновщиков, а заодно изучить код, который получен в результате: по крайней мере, станет понятно, что же именно столько места сожрало. Наконец, стоит помнить, что подготовка АРМа к работе намного сложней (куча периферии, ПЛЛ и т.д. и т.п.) -- а это тоже память. Так что, думается, наиболее правильный подход -- сравнение размера именно "целевых" функций, которые, собственно, и выполняют полезную работу. В тестовых задачах их объём может быть невелик по сравнению с инициализационным кодом, вот и создаётся впечатление, что АРМ менее эффективен по памяти. Но если задача крупная, то вся эта инициализация будет занимать лишь небольшой размер по сравнению с объёмом в целом -- и там можно увидеть реальную картину.
