ATmega64 - Operand 1 out of range: 0x36?, Ругается компилятор ассемблера. Опции

[jokolemene]

Написал программу для ATmega64 на Си. Использовал IAR C. Всё нормально, всё работает. Теперь встала задача написать бутлоадер, чтобы грузить прошивку в проц удалённо. Решил писать на ассемблере. Выяснилось, что ассемблер IAR-а балдеет от русских комментариев - то повиснет, то какие-то другие глюки начинают происходить. Пришлось с IAR перейти на AVR Studio 4 и AVR Assembler. Теперь другая проблема - компилятор ругается на совершенно легальные команды типа "sbi tifr,icf1", что мол "Operand 1 out of range: 0x36". По доке на процессор видно, что адрес 0x36 попадает в область I/O этого проца и с включенным режимом совместимости с ATmega103 и с выключенным. Что за тема, не въеду? Как это победить?

[rezident]

Выяснилось, что ассемблер IAR-а балдеет от русских комментариев - то повиснет, то какие-то другие глюки начинают происходить.

Вовсе не от любого комментария на русском, а только от маленького кириллического символа "я", который в кодировке WIN-1251 имеет код конца файла (0xFF). Для компиляции в IAR уже готового исходника достаточно средствами реактора заменить маленькую "я" на большую "Я". Читаемость комментариев нисколько не ухудшиться, но ошибки, связанные с этим символом, пропадут.

[zltigo]

только от маленького кириллического символа "я", который в кодировке WIN-1251 имеет код конца файла (0xFF).

Это не конец файла - "конец" ^Z, т.е. 0x1A
Болезьнью 0xFF до сих пор болели текстовые редакторы, которым необходимо было в процессе редактирования иметь во внутреннем представлении редактируемого файла иметь виртуальные разделители. Для компиляторов это явный баг, видимо отрыжка unicode .
Если не требуется вывод кирилицей в WIN кодировке, то лечится использованием нормальных редакторов поддерживающих разные кодировки и работа в "досовской" CP866. Кстати, нормальные редакторы можно попросить и менять 'я' на 'Я' при вводе. А еще можно не писать комментарии на русском экономит время на переключении раскладок .

[rezident]

Это не конец файла - "конец" ^Z, т.е. 0x1A

Я имел в виду символ EOF, а не скан-код.

[zltigo]

Я имел в виду символ EOF

С этими еще проще - он по жизни int, посему с 0xFF не соотносится.

[XVR]

С этими еще проще - он по жизни int, посему с 0xFF не соотносится.

К сожалению, у некоторых 'софтописателей' (язык не поворачивается назвать их програмистами) есть некоторое непонимание того факта, что char может быть по умолчанию знаковым (т.е. signed char), а буквы могут занимать и вторую половину ASCII таблицы. Так что 0xFF после расширения знака замечательно преобразуется в -1, каковая и является EOF.