Точнее это не баг, а скорее неудобство, для IAR это фича, при компиляции асмовских файлов (*.s) если в коментах встречается буква "я", компилятор выдает ошибку



в младших версиях такого не наблюдал.

Пишите большую букву Я если сильно хочется использовать кириллицу. Код маленькой буквы я совпадает с символом конца файла.

Старые версии MATLAB этим тоже грешили.

Это как он может совпадать? Код я - 255 ( в Win1251) , а конец файла ^Z( 26 = 0x1A)

В KEILе, в отладчике, терминал "я" тоже не кажет.

Маленькую "я" не только компиляторы не любят. Например, стандартная программка из комплекта Windows "Таблица символов" (\system32\charmap.exe) не переносит. Запустите программу. Выберите любой TrueType шрифт. Откройте доп. параметры просмотра. Смените кодировку на любую другую, отличающуюся от Юникод. Например, Windows: кириллица. А теперь прокрутите лифт окна символов до маленькой "я". Получилось? У меня нет. Программа аварийно завершается

Гы, а у меня получается без проблем.

А вообще, ИМХО, стоит избегать кириллицы в путях, именах пользователей и, конечно, в исходных текстах.
Английским языком на уровне написания лаконичных комментариев уважающий себя инженер владеть обязан.

А ещё виндовый гипертерминал "я" проглатывает.



Это конечно да, но иногда надо выводить русские надписи для пользователя Поэтому я использую кодировку DOS, там "я" на другом месте, и всё замечательно отображается.

Если речь идет о компиляторе для ARM, то позавчера вышел новый билд 5.40.4 build 1619 (full-версия). Выложена на FTP. Просьба испытать и сообщить, как у нее обстоит дело с буквой 'я'.

Полагаю, что не для того в IAR вводили фичу - дополнительный разделитель 0xFF дабы по стонам на электрониксе его сразу и убирать.

И тем не менее, в новой версии от 1 октября (5.40.4 build 1619 full) баг пропал!
Я не стала дожидаться пока народ отгуляет выходные и проинсталлировала новый продукт у себя. Инсталляется долго, но это не удивительно - компиляторы для ARM великаны по сравнению с остальными. Запустила на компиляцию один из примеров из папки "\example" и убедившись, что компиляция прошла успешно без ошибок и варнингов, отредактировала одну и строковых переменных, заменив в ней английские буквы русскими. Естественно, включяя злополучную маленькую "я". Повторная компиляция прошла нормально, без сучка и задоринки. Вообще-то с архитектурой ARM я дела никогда не имела, но компиляторы от IAR все на одно лицо. На всякий случай прошу поверить мой результат.
Полагаю, что дело тут не в стонах на электрониксе, а в вещах куда более серьезных - совсем недавно (21 сентября) была проведена "японизация" - выпущена версия EWARM-5401J. Я сначала подумала, что буква J относится к номеру версии, т.к. частенько у IAR'а выходят версии, маркируемые на конце буквой, и лишь недавно они перешли чисто на числовую кодировку (и то не везде). Я уж его на FTP успела выложить, а когда поняла, что это японская версия, стерла.
Вот и нынешняя версия несет на себе явные следы японизации - слово "Japanese" с мелким японским национальным флажком в правом верхнем углу заставки инсталлятора, и предложение двух языков на выбор - английского и японского (других нет).
Весьма вероятно, что символ 0xFF стал допустим из-за того, что компилятор они написали в расчете на юникод. Иначе японскую письменность никак не поддержать. Однако выбрала я при инсталляции английский вариант, в котором ничего японского не обнаружила. Все хелпы по-английски.
Короче говоря, всем рекомендую эту версию. Выложила на FTP, куда положено.

Только что попробовал. Никуда не пропал, все на месте.

Прошляпила, что баг касается языка ассемблера. На C и C++ он, по-видимому, не проявляется.
Если так, то дело не так плохо - на ассемблере для ARM мало кто пишет . А если пишет, то в комментариях можно вполне обойтись без буквы я.

Всем доброго времени суток!
Не стал создавать новую тему потому как мож у меня моск под утро двинулся.
IAR C/C++ Compiler for ARM 5.40.1.51558 (5.40.1.51558). Код:

переменная free не может быть меньше нуля, так как sw_size не может быть меньше len.
Поясню - sw_size - это размер FIFO буфера, len- количество полезных данных в пакете.
При очередном зависоне торможу программу и вижу, что sw_size равно len, при этом free в минусе
Если вместо while(free--) ставлю for(i = 0; i < free; i++) все работает прекрасно.
Вот такая ботва. Тока не пойму, у меня в голове или баг компилятора.

Для начала проверьте, не случается ли у вас, что free изначально меньше нуля (ловушку какую-нибудь влепите). Ну, и дизассемблер "подозрительной" части выложите.
ИМХО, вероятность того, что это глюк ИАРа стремится к нулю, хе-хе

...Ботва в голове все же...Пошел спать, рыдая.

А я так и не смог заставить
iccarm.exe
IAR ANSI C/C++ Compiler V5.40.0.21500/W32 EVALUATION for ARM
переварить
#pragma message("text")

Кушать то кушает, но на выходе ничего нет. Примечания разрешал - тишина.


--- добавка ---
проверил руками: кушает и переваривает. вот только в IDE оно почему-то не передается...

Tools->Options->Messages->Show build messages->All. Во всяком случае в оболочках 4.XX там было.

IAR Assembler for MSP430 v 4.21.6:

Думал, что это уже давно починили, а нет, в этой версии откатили назад:
ругается на символах в Си комментариях //
(Error[15] Invalid character encountered):
e0 e5 e8 ea eb ed ef f0 f2 f9 ff - - - аеиклнпртщя

если начало // комментариев заменить на ;
то работает до "я" - неожиданный конец

В предыдущей версии 4.20 все работало.

Интересно зачем они парсят комментарии, неужели там в асме могут быть как в verilog meta-comments ?

Не только в комментариях, но и в коде (например, DB 'я')...

Исправление бага при компиляции ассемблером файлов, содержащих маленькую русскую букву 'я' в кодировке WIN (код 0xFF):
(для a430.exe размером 2,035,712 (IAR Assembler V4.21.2.50066/W32 for MSP430))

Сравнение файлов a430.exe и a430patched.exe:
000250C1: BE B6
000250C3: 16 32

Для других версий a430.exe попробуйте найти последовательность кодов A3CC795F00 0FBE0416 03D53BD1 и заменить 0FBE0416 (код команды movsx eax,byte ptr [esi+edx]) на 0FB60432 (код команды movzx eax,byte ptr [esi+edx]).

Для icc430.exe это не подходит... Попробуйте в С-код вставить asm("mov r12,r12 ;я"); и скомпилировать...

Что-то патчить ассемблер абсолютно неприкалывает, тем более что


Вопрос был в другом, зачем они комменты парсят %) ?
(если точнее сказать, зачем внутри комментариев ищут что-то отличное от признака конца комментария)

И до каких пор 0xff для них будет признаком конца файла?
Что-то у них там неправильно с системностью.

Это скорее был вопрос/просьба к тем, кто с ихним суппортом официально общается, чтоб им ask/"намекнули" : )

Парсинг каментов - это капут. У меня в ассемблере инклудится многоуровневая конфигурация в виде вложенных h-файлов, там только куча #define-ов и других препроцессорных команд, и довольно много русскоязычных комментариев (это ж конфигурация, 90% специфично для проекта). Ото оно все радовалось "по самое не могу".

Сегодня еще классную фишку "нарыл". Проц - LPC1768, невыравненый доступ запрещен (отладка суровая идет), исключения летят вовсю. Разбираюсь, компилятору (5.41A) дан флажок --no_unaligned_access, он корректно генерирует вызов функции __eeabi_uread4, а там вот такой милый код:

Если Вы тормозите программу после исполнения while так оно и д.б.
Поскольку sw_size равно len, то free == 0 а следовательно при первом же while( free-- ) тело while испонятся не будет а free сразу после выхода free будет == -1 поскольку он int типа. Так устроен язык С
а с циклом for тело его тоже выполнятся не будет но free не станет -1 и даже i не станет 1.

Лечение aavr.exe 5-50 от заякания в комментариях:

Для aavr.exe v5.51 - патчить в том же месте.