Интересный глюк в CodeVisionAVR Опции

[DMD]

Обнаружил интересный глюк в CodeVision, целый день вчера просидел - думал во мне дело, оказалось, что нет.
Если мы делаем сдвиг и результирующее число выходит из размера 1 байта, то, почему-то, компилятор не преобразует его к int (хотя обязан по стандарту). То есть вот такой код работает непрявильно:

Код

unisigned char s = 243;
//...
unsigned int d = (unsigned int)(s << 4);  // d != 3888

а надо так делать, что глупо...

Код

unisigned char s = 243;
//...
unsigned int d = (unsigned int)(((unsigned int)s) << 4);  // d = 3888

Интересно, зачем это надо или это просто баг??..

[ReAl]

Обнаружил интересный глюк в CodeVision, целый день вчера просидел - думал во мне дело, оказалось, что нет.

Уже обсуждалось. "Выбрось каку".

[delamoure]

Уже обсуждалось. "Выбрось каку".

Кака, конечно.
Но если бы в IAR C было также просто вставлять ассемблерный код в текс программы как это сделано в CvAVR...

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

Но если бы в IAR C было также просто вставлять ассемблерный код в текс программы как это сделано в CvAVR...

Тогда вам в gcc. Такого шикарного инлайн-асма в других компиляторах не встречалось. Вставленный код не мешает оптимизатору, компилятор сам решает, в каких регистрах удобнее передать параметры в ваш ассемблерный кусок... Конфетка! Не знаю как CV, но ИАР встретив в функции инлайн-асм складывает крылья и выключает оптимизатор (где-то в описании было).

[SasaVitebsk]

Тогда вам в gcc. Такого шикарного инлайн-асма в других компиляторах не встречалось. Вставленный код не мешает оптимизатору, компилятор сам решает, в каких регистрах удобнее передать параметры в ваш ассемблерный кусок... Конфетка! Не знаю как CV, но ИАР встретив в функции инлайн-асм складывает крылья и выключает оптимизатор (где-то в описании было).

А я не испытал серьёзных неудобств с асмовыми вставками в IARе.
(Дальнейшее к Вам Сергей не относится, так как Вы всё это знаете лучше меня, это больше для delamoure и других, выбирающих инструмент)

Начнём с того, что IAR позволяет использовать inline ассемблер. В том числе и с многострочными конструкциями.
Во-вторых он позволяет писать на ассемблере законченные процедуры и подключать на этапе линковки. Это на мой взгляд намного правильнее и логичнее. Прога получается значительно нагляднее и завершённее. Использование регистров компилятором детально описано, и при таком варианте я не заметил ухудшения работы оптимизатора. (А inline ассемблер не применял, по причине вышеописанной)
Во втором варианте возможно использовать общие символические имена. Причём я работал со структурами, массивами, флагами именно с символьными именами.

Несколько напрягает в IARе перевод всех символьных имён в регистры и константы десятичные. И это перед выдачей листинга.
Ну например исходный текст
int i=1234;
В распечатке асмового листинга мы увидим что-то типа
ldi r26,210
ldi r27,4
Я бы предпочёл увидеть что-нибудь типа
ldi R26,low(1234)
ldi R27,high(1234)
Аналогично и с именами символическими. Хотя наверное это брюзжание.

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

А я не испытал серьёзных неудобств с асмовыми вставками в IARе.
....
(А inline ассемблер не применял, по причине вышеописанной)

"Асмовые вставки" == inline assembler. Они, как правильно заметил Qwertty, хороши именно тем, что не надо тратить время на сохранение регистров и вызов функции. При этом gcc позволяет в такой вставке сделать все, что угодно, а ИАР в документации честно пишет:

Inline assembler sequences have no well-defined interface with the surrounding code generated from your C or C++ code. This makes the inline assembler code fragile, and will possibly also become a maintenance problem if you upgrade the compiler in the future.
...
Inline assembler is therefore often best avoided. If there is no suitable intrinsic function
available, we recommend the use of modules written in assembler language instead of inline assembler, because the function call to an assembler routine normally causes less performance reduction.