13-Jul-04 05:31 Harry Zhurov wrote to Alexander Derazhne:
AD>> Пойдёт в качестве "два, три"?
HZ> [4] Убогий указатель стека. Гораздо лучше было бы, если бы указатель HZ> стека HZ> был бы регистровой парой. Тогда не было бы необходимости в раздельных HZ> стеках HZ> (для данных и для адресов возвратов), которые юзает ИАР. GCC использует HZ> один стек, но это, имхо, еще хуже (по эффективности кода). Как хотя бы слабую моральную компенсацию этого (4) могли бы хотя бы автоматом запрещать прерывания на 1 такт после команды out в SPH, тогда на мелких кристаллах без SPH вообще ничего не поменялось бы, а на более толстых gcc вместо in __temp_reg__,sreg cli out SPH,r29 out sreg,__temp_reg__ out SOL,r28
спокойно мог бы делать
out SPH,r29 out SPL,r28
Ну а нормальный стек на одной из регистровых пар и никаких идиотских SPH/SPL это было бы просто счастьем :-)
HZ> [5] Неполноценный указатель X (r26:r27). Отсутствие у него режимов HZ> адресации со смещением порождает порой геморройный код. Особенно это HZ> заметно на HZ> ИАР 2.27(2.28). В 3.хх сделали уже лучше, но все равно кривизны это не HZ> убавляет.
HZ> [6] Несбалансированный регистровый файл. ИМХО, вместо 32 регистров HZ> лучше бы HZ> было их 16, но чтобы они при этом были полностью симметричными (позволяющими HZ> работу с любыми командами) и чтобы любая регистровая пара могла быть HZ> указателем, а не только старшие три. И, как уже говорилось, чтобы одна HZ> из регистровых пар была указателем стека. Эти два пункта взаимосвязаны. 32 регистра сожрали 10 бит в КОП-ах
2-адресных команд и 5 бит в кодах одноадресных команд, из-за чего стало тесно и не хватает кодов ни для нормального X, ни для большего количества регисторвых пар. Кстати, вполне возможно, что и для 16 регистров не хватило бы кодов для того, чтобы они все могли быть парами. Но вот старшие 8 из них чтобы были парами, одинаковыми по методам адресации, да чтобы самые старшие были указателем стека -- это точно хватило бы. Я не уверен, что 7 указателей (кроме SP) прямо так нужны. Полная симметрия это "красиво", но вот экономично ли? А вот SP с адресацией смещением и к этому ещё три "нормальных" пары - это IMHO было бы достаточно. Это было бы в два раза лучше, чем сейчас (у IAR - один SP на Y и ещё Z, X практически не в счёт). А освободившиеся коды лучше отправить на загрузку/выгрузку по указателю регистровых пар и т.п. Т.е. код адресной пары
7 ld/st в регистр косвенно по паре 7
6 6
5 5
4 4
3 пусть лучше ld/st пары регистров по паре 7, чем одного регистра по паре 3. Тебе бы очень понравилась загрузка/выгрузка всей старшей пары (указателя стека!) одной неразрывной командой по паре 6 :-)
2 и т.д.
1
0
Но это при чётном номере регистра-получателя :-) А при нечётном - ld пусть в памяти берёт один байт, и знаково его расширяет в пару по (номеру dst) & 0b110
HZ> [7] Все-таки, имхо, медленная работа с памятью. Она все гробит - при HZ> элементарном инкременте ячейки ОЗУ - 80% накладных расходов на копирование. HZ> Это явный перекос. Опять вопрос на тему свободного кодового пространства.
На эту же тему [8] Аназачем они сделали это идиотское пространство ввода-вывода? in/out им захотелось? Как я уже говорил, "если ядро AVR разрабатывали и программисты, то программисты на визуалбейсике, а не на С". Целых 6 бит в КОП-ах под номер порта! И всё равно портов не хватило, ещё во время появления меги 103 было ясно, что SFR скоро не влезут в 64 байта. Итого у меги128 вместо того, чтобы иметь два одинаковых UART и иметь возможность работать с ними обеими одним кодом через указатель на начало их регистров - имеем какую-то такое... Вместо этого надо было бы сделать (не инкремент памяти, нет, это не надо) возможность только с одним методом адресации, а именно (ptr+disp) установить/сбросить/проверить бит. Это то, что сейчас можно сделать с SFR кроме in/out, заменяемых на ld/st. in r0,port10 => ld r0,Y+10 out port11,r1 => st Y+11,r1 sbi port12,3 => bset Y+12,3 cbi port13,4 => bclr Y+13,4 sbis port14,5 => skpbs Y+14,5 sbic port15,6 => skpbc Y+15,6 хм... ещё две комбинации просятся :-) ну тогда btg и skpbsc (пропуск при установелнном со сбросом :-) Перед началом работы с SFR можно было бы прсто загрузить в какую-то пару адрес начала нужной области SFR. У мелких типа tiny и младших classic хватило бы загрузки только младшего регистра из пары. На них при даже всего 4-х парах можно было бы в самом начале программы загрузить, скажем, в XL начало области SFR (всех, у мелких их мало) и в течении всей программы спокойно работать "в нынешнем стиле" (в мелких кристаллах часто вся работа состоит в махании ножками). А в программах с работой с IO в небольшом кол-ве подпрограмм загружать указатель адресом зоны SFR только где надо а в остальное время использовать его для работы с областью ОЗУ. При этом на толстых кристаллах с SFR больше 64 байт особых проблем не возникло бы, одновремённо со всеми всё равно работа не идёт. А то, что малость работа с портами удлиннилась бы и частота лапкоймахания упала бы -- так это по большому счёту фигня :-) Зато уж про битовые флаги претензии пропали бы (сейчас где-то раздаётся восторжённое АГГААА!!! :-)
Хотя это ещё кодовое пространство смотреть надо - не понадобится ли мне ГЗМ увеличенной мощности :-)
HZ> Вот это, имхо, самые серьезные недостатки AVR. Все относится к HZ> архитектуре. Убить мало за то, что они наворотили :-(
wbr,