Hi Harry, hope you are having a nice day!
31 Дек 03, Harry Zhurov wrote to Alexey V Bugrov:
AV>> т.к. действительно провоцирует ошибки _использования_, если бы AV>> были только декларации TMR0L и TMR0H, такой проблемы бы не было.
HZ> Это было бы так, если бы таймерные (и другие SFR) регистры были HZ> действительно задекларированы как ты описал, т.е. ничем бы не HZ> отличались от обычных переменных в памяти.
Именно так они задекларированы и они действительно не отличаются от остальных переменных.
extern volatile near unsigned char TMR0L; extern volatile near unsigned TMR0; extern volatile near unsigned char TMR0H;
Объявления производятся в асм-файле, который оттранслирован в объектник с жесткой привязкой к физическим адресам, и лежит в lib'е вместе со стартапом.
HZ> Hо поскольку сами по себе HZ> SFR являются расширениями, не входящими в язык, то и поддержка их, и HZ> работа с ними тоже являются расширениями, и компилятор, разработанный HZ> для embedded процессора, по хорошему, должен бы их поддерживать.
Hету в mcc18 никаких расширений, кроме near/far и rom/ram. А в PIC16/17/18 все SFR отмаплены в память (регистровый файл).
HZ> ИАРовский поддерживает. Там кроме прочего при декларации SFR еще HZ> указан их физический фиксированный адрес с помощью оператора @ (в HZ> более старых версиях использовались ключевые слова sfrb, sfrw HZ> и присваивание адреса с помощью обычного '='). Это дает, во-первых, HZ> возможность использовать более эффективные команды для работы с SFR (в HZ> АВР имеются специальные команды, которые эффективнее, чем команды HZ> работы с памятью), во-вторых, дает возможность прозрачно и безопасно HZ> работать с некоторыми SFR, как в случае с таймерными регистрами.
Hету никаких специальных команд в PICxx, начиная с PIC16. С точки зрения пользователя это обычные ячейки памяти, хоть на си, хоть на асме.
HZ> В итоге, при работе на EWAVR можно спокойно писать выражения типа:
HZ> OCR1A += 1000;
HZ> word t = TCNT1 + 100;
HZ> не опасаясь, что возникнут коллизии из-за несоблюдения порядка при HZ> попеременном считывании/записи половинок регистра, т.к. компилятор HZ> "знает" к какому регистру он обращается и как правильно с ним HZ> работать. За все время работы с EWAVR компиляторами еще с версии 1.30 HZ> ни разу не возникло даже намека на какие-то проблемы - механизм HZ> обеспечивает прозначность работы в сочетании с безопасностью и без HZ> потери эффективности.
Хех. Просто это разные концепции. В случае с mcc18 компилятору ничего не нужно знать о конкретном процессоре до тех пор, пока архитектура памяти и система команд у него остается неизменной. И с появлением новых процессоров далеко не обязательно искать обновление.
HZ> Вот это я и имел в виду: компилятор должен поддерживать такие HZ> вещи, "и это правильно" (с) :). Если тот, что указан в сабже, не HZ> поддерживает, то остается только посочувствовать его пользователям.
Hу это кому как. Мне нравятся компляторы без расширений и которые генерят прозрачный код без лишнего интеллекта. :)
WBR, AVB
ICQ# 43835774 mailto: avb<at>dialup.etr.ru