ARV писал(а):а в чем проблема с 16-битными числами? если я не ошибаюсь, по стандарту все числа считаются типа int, чтобы они были другого типа. надо объявлять это. так в чем вы видите проблему: в соблюдении стандарта?
Главное, что запись типа (a+1)<<2, где a и b имеют тип char вполне может быть преобразована компилятором в сдвиг 16-битного числа, который выполняется в цикле. И естественно скорости это совершенно не добавляет.
Во многих компиляторах(особенно для МК) в таких случаях в качестве типа константы берётся наименьший тип в котором она помещается.
ARV писал(а):а оптимизатор, по-моему, отлично справляется со всеми поставленными задачами... опять же: какие претензии?
Я регулярно наблюдаю как оптимизатор сначала преобразует переменную к нужному типу и затем производит операцию не только с нужными регистрами, но и с несколькими, которые он незадолго до этого заполнил нулями.
ARV писал(а):и, наконец, последнее: только что тут было рассказано (с уклоном в историю) о том, что Си не имеет и не должен иметь никакого понятия о РАЗНЫХ типах памяти и потому НЕ ОБЯЗАН реализовывать на уровне языка доступ к этим разным памятям... и если какой-то компилятор умеет работать с ячейкой eeprom, как с обычной переменной (без функций) - то это скорее недостаток, чем достоинство!
Хоть компилятор по стандарту и не обязан поддерживать другие типы памяти, но тем не менее поддерживать их нужно. Причём делать такую поддержку крайне желательно на уровне компилятора(а не костылями типа ассемблерных вставок), поскольку в этом случае во-первых оптимизатор может произвести оптимизацию(например, avr-gcc не может использовать инструкцию LPM Rd, Z+) и во-вторых уменьшается число мест где можно сделать ошибку(тот же avr-gcc при обращении к указателю со спецификатором PROGMEM как к обычной памяти даже варнинг не выдаст).
Поддержки прерываний, кстати, в стандарте C тоже нет. И что компилятор для МК может их не поддерживать?
ARV писал(а):это делает программу непереносимой
Если для указания того, что переменная находится в другом типе памяти требуется только её спецификатор, то программу легко сделать переносимой с помощью обычных #define'ов. А вот если при каждом обращении нужно вызывать функцию, то для переноса кода потребуется переделывать весь код.
ARV писал(а):но главное, полностью скрывает от программиста контроль за скоростью исполнения. не только скорость, но и просто процесс записи, например, 32-битной переменной long в EEPROM происходит неизвестно как: то ли с использованием прерывания по окончанию записи, то ли нет, то ли с запретом прерываний (атомарно), то ли нет...
Язык высокого уровня и должен скрывать от программиста тонкости реализации. Естественно при этом программисту нельзя забывать, что указав другой тип памяти он может значительно снизить быстродействие и он должен это учитывать. А для возможности доступа по прерываниям можно и дополнительно дать возможность чтения и записи вручную и никаких проблем с таким доступом я не вижу.
А скорость доступа к flash в AVR вообще не сильно меньше, чем к SRAM: всего на 2-6 тактов в зависимости от способа доступа.
ARV писал(а):кстати, по вышеупомянутым причинам avr-gcc-программисты даже не подозревают о наличии каких-то проблем с указателями и т.п. при доступе к разным видам памяти!
Но им иногда приходится делать конструкции типа pgm_read_word(((PROGMEM struct1 *)pgm_read_word(dataaddr+a))->fld1) .
какие-такие трехбайтовые generic-указатели? avr-gcc про них что-нибудь знает?
