В IAR 5.4 нашел баг Опции

[MALLOY2]

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

Error[4]: Unexpected end of file encountered D:\DEVELOP\Filin\FirmWare\Source\Internet_crc.s 52
Error while running Assembler

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

[uriy]

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

[mdmitry]

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

[KRS]

Код маленькой буквы я совпадает с символом конца файла.

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

[fmdost]

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

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

[rezident]

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

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

Эскизы прикрепленных изображений

 

[aaarrr]

Получилось? У меня нет. Программа аварийно завершается

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

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

[AHTOXA]

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

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

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

[Xenia]

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

[zltigo]

Просьба испытать и сообщить, как у нее обстоит дело с буквой 'я'.

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

[Xenia]

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

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

[Andy Mozzhevilov]

И тем не менее, в новой версии от 1 октября (5.40.4 build 1619 full) баг пропал!

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

[Xenia]

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

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

[prottoss]

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

Код

...
INT i, sw_size, cnt, i_head, free;
...
/* Get SW FIFO fields */
        ptr = p_eps->data;
        sw_size = p_eps->sw_size;    
        i_head = p_eps->i_head;
        free = sw_size - p_eps->len;    /* Calculate size for new data payload */
...
while(free--)    /* Read new data */
{
     ptr[i_head++] = AT91C_BASE_UDP->UDP_FDR[ep];
    if(i_head >= sw_size)
          i_head = 0;
}

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

[aaarrr]

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

[prottoss]

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

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

[Alechek]

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

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


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

[Сергей Борщ]

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

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

[atlantic]

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

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 ?

[ZZmiy]

при компиляции асмовских файлов (*.s) если в коментах встречается буква "я"

Не только в комментариях, но и в коде (например, 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 ;я"); и скомпилировать...

[atlantic]

Не только в комментариях, но и в коде (например, 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 ;я"); и скомпилировать...

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

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

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

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

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

[VslavX]

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

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

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

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

Код

00000000 <__aeabi_uread4>:
   0:    6800          ldr    r0, [r0, #0]
   2:    4770          bx    lr

[miv]

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

Код

...
INT i, sw_size, cnt, i_head, free;
...
/* Get SW FIFO fields */
        ptr = p_eps->data;
        sw_size = p_eps->sw_size;    
        i_head = p_eps->i_head;
        free = sw_size - p_eps->len;    /* Calculate size for new data payload */
...
while(free--)    /* Read new data */
{
     ptr[i_head++] = AT91C_BASE_UDP->UDP_FDR[ep];
    if(i_head >= sw_size)
          i_head = 0;
}

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

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

Сообщение отредактировал miv - Apr 16 2010, 12:24

[halfdoom]

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

CODE

Сравнение файлов aavr.old и AAVR.EXE
0000AF21: BE B6

[kv_addr]

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

Код

Сравнение файлов aavr.old и AAVR.EXE
0000AF21: BE B6

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