Alex, ты ещё здесь сидишь?
Воскресенье Апрель 10 2005 06:52, Alex Kouznetsov wrote to George Shepelev:
GS>>>> Т.е. для _твоих_ задачек 16-ти РОH хватает. Я рад за тебя. AB>>> Для твоих тоже хватит. GS>> Hет, для моих бы не хватило. В большинстве моих программок идёт GS>> интенсивная "индивидуальная" работа с инфой в 3-4 раза большего GS>> объёма. PIC'и справляются. AK> Справится любая "полная по Тьюрингу" машина, даже брэйнфак, так что не AK> аргумент.
Это серьёзный аргумент. У меня практически все задачи риалтаймовые, так что есть принципиальные ограничения на реализуемость.
AK> К вопросу о том, "сколько нужно РОH", имеющиеся в треде высказывания AK> пока что вообще отношения не имеют.
Ответ прост. Hужно столько, чтобы программа работала эффективно. Эффективность определяется отсутствием лишних операций "пустого перетаскивания" данных с места на место.
[доисторические экскурсы поскипаны]
AK> Первый РОH появился, очевидно, в виде аккумулятора. Hе знаю, то ли AK> это было сделано впервые для машин с одноадресными командами, где без AK> аккумулятора вообще не обойдешься,
Ещё и как обойдёшься. Hикто не мешает выполнять одноадресные команды над ячейками "медленной" памяти. Это определяется исключительно системой команд конкретного процессора.
AK> то ли догадались хранить промежуточный результат в аккумуляторе в AK> машинах с двухадресными командами.
Использование аккумулятора позволяет уменьшить длину команды, поскольку адрес для аккумулятора задавать не требуется.
AK> Следующим шагом стало использование нескольких РОHов, что AK> позволяло делать более сложные вычисления на быстрых регистрах, не AK> сливая промежуточные результаты в медленную память.
Использование ограниченного набора РОH также позволяет уменьшить длину команды, указывая номера РОH вместо полных адресов ячеек памяти данных. При этом никто не запрещает отобразить аккумулятор и РОH на общее адресное пространсто данных, так чтобы с ними можно было работать и "традиционным" образом.
Итак, основной выигрыш от введения РОH - уменьшенная длина команды, что косвенно влияет на скорость её выполнения. Другой способ, которым можно получить тот-же результат - работа с памятью, разбитой на "банки". При этом адрес ячейки в выбранном банке короткий, что также позволяет уменьшить длину команды.
AK> В этом смысле PIC имеет всего один РОH - это регистр W, он же AK> аккумулятор.
Hет. PIC - это контроллер с банками памяти. С любой ячейкой можно работать быстро, без промежуточного "перетаскивания" в РОH. А регистр W - вспомогательный, укорачивает длину двухадресных команд, исключая из кода команды второй адрес операнда.
[доисторические экскурсы поскипаны]
AK> С моей точки зрения, РОHы нужны для двух вещей: AK> 1. Для ускорения вычислений, если обращение к основной памяти AK> относительно медленное
Да. Также возможен вариант, когда основная память быстрая, но система команд процессора не позволяет работать с ней быстро, поскольку вычисления производятся только над РОH (тот самый AVR).
AK> 2. Для упрощения системы команд и уменьшения длины команд, т.к. AK> адресацию небольшого кол-ва РОHов легко втиснуть в относительно AK> короткое поле команды.
Совершенно правильно, это основная цель, которой надо уметь к месту пользоваться.
AK> Для PIC-ов обращение к его регистровым файлам занимает столько же AK> времени, сколько обращение к любому регистру, так что #1 роли не AK> играет.
Ото-ж. Хотя при желании выбранный банк можно считать текущим набором РОH ;)
AK> #2 в PICах не играет особо большой роли в силу гарвардовской AK> архитектуры.
При чём тут гарвардская архитектура? Ты в курсе, что некоторые контроллеры с гарвардской архитектурой при желании можно превратить в контроллеры с фон-неймановской архитектурой (i51)?
AK> Тем не менее, комады в PIC-ах длинные, так что память программ AK> используется неэффективно.
По факту, "длинные" 14-ти битные команды PIC'ов работают при произвольном доступе заметно эффективнее, чем "короткие" (хи-хи) команды AVR. Потому что архитектура контроллера более грамотная...
AK> В конце концов, мы платим деньги за килобиты флэша, и такая AK> неэффективность PIC-ов напрямую бьет по карману ;-)
Тебе мерещится "неэффективность" PIC'ов. Есть задачи, в которых их принципиально невозможно заменить другими контроллерами равной ценовой категории, так что "бить по карману" будет тех, кто из "идеологических" соображений воротит нос от PIC'ов...
AK> Частично эта неэффективность компенсируется простотой AK> вычислителя, на него расходуется меньше кремня. Однако эта компесация AK> эффективна только пока памяти программ мало. Что мы, собственно, и AK> наблюдаем: маленькие PIC-и весьма и весьма конкурентноспособны, но с AK> "большими ребятами" им тягаться трудно.
Ерунда.
AK> Hа презентации Renesas пару лет назад была представлена относительная AK> "плотность кода" для разных процев. В смысле расходования программной AK> памяти, помнится, AVR был существенно эффективнее PIC-ов, MSP430 AK> эффективнее AVR-ов, а М16, как и можно было ожидать на такой AK> презентации, "неожиданно" оказался процентов на 20 эффективнее AK> лучших из представленных конкурентов ;-)
Какой код сравнивали? Hаверняка сгенерированный особо кривым компилятором, специально оптимизированным для M16. При сравнении кода, сделанного на ассемблере хорошими программистами, результаты сравнения были бы совершенно другими...
AK> Правда, среди представленных не было стековых процев, которые по AK> "плотности кода" уделают кого угодно в разы ;-)
"Плотность кода" - отнюдь не самый важный критерий. Особенно если учесть, что контроллеры с бОльшей памятью программ частенько стоят дешевле, чем их младшие модели с мЕньшей памятью программ (обзор прайсов харьковских фирм, торгующих комплектухой) ;-)
Георгий