IAR: вопрос типа "глазам не верю" Опции

[ARV]

Неужели правда в IAR в результате такого кода

Код

volatile unsigned char v1 = 1;
volatile unsigned char  v2 = 255;
volatile unsigned char  v3 = 2;


if (v1 == (v2+v3))
   PORTB = 0;
else
   PORTB = 1;

в PORTB действительно будет выведен 0? наткнулся на тему на другом форуме - говорят, таки да...

[MrYuran]

Неужели правда в IAR в результате такого кодав PORTB действительно будет выведен 0? наткнулся на тему на другом форуме - говорят, таки да...

А почему бы и нет?
255 + 2 = 1;
1 == 1;
PORTB = 0;

[ARV]

ну потому, что как бы 1 должно выводиться... WinAVR, например, именно так поступает

[arttab]

ff это 255 т.е. максимальное значение. 255 + 1 = 0. поясню ff + 1h = 100h поскольку unsigned char получаем 00h
соответственно ffh +2 = 101h -> 01h

[ARV]

а как же быть с тем, что по стандарту языка Си в выражениях char автоматически преобразуется к int?

[MrYuran]

а как же быть с тем, что по стандарту языка Си в выражениях char автоматически преобразуется к int?

Озвучьте номер стандарта, где такое описано.

Код

#if !defined(__STDINT_H_)
#define __STDINT_H_

/*
*    ISO C99: 7.18 Integer types <stdint.h>
*/

#ifndef __int8_t_defined
#define __int8_t_defined
typedef signed char                             int8_t;
typedef int                                     int16_t;
typedef long int                                int32_t;
__extension__ typedef long long int             int64_t;

typedef unsigned char                           uint8_t;
typedef unsigned int                            uint16_t;
typedef unsigned long int                       uint32_t;
__extension__ typedef unsigned long long int    uint64_t;
# endif

Это в mspgcc. Не думаю, что WinAVR сильно отличается.

Из другого места:

Код

#ifndef __INTTYPES_H_
#define __INTTYPES_H_

#ifndef __int8_t_defined
#define __int8_t_defined
/* Use [u]intN_t if you need exactly N bits.
   XXX - doesn't handle the -mint8 option.  */

typedef signed char int8_t;
typedef unsigned char uint8_t;

typedef int int16_t;
typedef unsigned int uint16_t;

typedef long int32_t;
typedef unsigned long uint32_t;

typedef long long int64_t;
typedef unsigned long long uint64_t;
#endif

Правда, со сложением char-ов тоже какая-то засада была, при вычислении контрольной суммы.
По-моему, помогла маска, наложенная на старший байт результата.

[ARV]

я не супер-знаток стандарта, и тем более его пунктов и подпунктов, но точно помню, что в нем сказано буквально следующее: при вычислении выражений переменные типа char и unsigned char всегда неявно преобразуются к типу int и unsigned int соответственно. именно результат такого преобразования я наблюдаю в WinAVR, который, если не ошибаюсь, декларирует полное соответствие стандарту Си. более того, если упомянутый ранее код слегка видоизменить, то он работает именно так, как вы и говорите:

Код

volatile unsigned char v1 = 1;
volatile unsigned char  v2 = 255;
volatile unsigned char  v3 = 2;

unsigned char v4;
v4 = v2 + v3;
if (v1 == v4)
   PORTB = 0;
else
   PORTB = 1;

в данном случае на самом деле v4 будет содержать значение 0x01, хотя результат ВЫРАЖЕНИЯ v2+v3 будет равен 0x0101;

собственно, я и задал вопрос с целью разобраться в этом вопросе: жду, пока Сергей Борщ или иной специалист, хорошо знающий стандарт, даст пояснения.

[MrYuran]

я не супер-знаток стандарта, и тем более его пунктов и подпунктов, но точно помню, что в нем сказано буквально следующее: при вычислении выражений переменные типа char и unsigned char всегда неявно преобразуются к типу int и unsigned int соответственно.

Ну вот теперь все встало на свои места.
Спасибо за разъяснения!
То, что у ИАРа своя логика, иногда противоречащая стандартам, и так известно.
У меня с ним отношения не сложились, и как раз касательно if()-ов. Столько раз получал граблями в лоб, но постепенно привык.
А теперь вот на GCC переполз.

[ARV]

Ну вот теперь все встало на свои места.
Спасибо за разъяснения!

оно-то, конечно, пожалуйста... но как бы я сам разъяснения просил

[sparcmaster]

Цитата из Шилдта:

Преобразования типов в выражениях

Если в выражении встречаются переменные и константы разных типов, они преобразуются к одному типу. Компилятор преобразует "меньший" тип в "больший". Этот процесс называется продвижением типов (type promotion). Сначала все переменные типов char и short int автоматически продвигаются в int. Это называется целочисленным расширением. (В С99 целочисленное расширение может также завершиться преобразованием в unsigned int.) После этого все остальные операции выполняются одна за другой, как описано в приведенном ниже алгоритме преобразования типов:

IF операнд имеет тип long double
THEN второй операнд преобразуется в long double
ELSE IF операнд имеет тип double
THEN второй операнд преобразуется в double
ELSE IF операнд имеет тип float
THEN второй операнд преобразуется в float
ELSE IF операнд имеет тип unsigned long
THEN второй операнд преобразуется в unsigned long
ELSE IF операнд имеет тип long
THEN второй операнд преобразуется в long
ELSE IF операнд имеет тип unsigned int
THEN второй операнд преобразуется в unsigned int

У вас же случай, когда переменные одинаковых типов - т.е. IAR прав.

Сообщение отредактировал sparcmaster - Jan 20 2012, 08:24

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

собственно, я и задал вопрос с целью разобраться в этом вопросе

Да, все верно вы рассуждаете. 255+2 = 257, 257 != 1. Сравнение должно производиться в intах. Оптимизатор может выкинуть проверку старшего байта если это не повлияет на результат, как в вашем примере с v4. Что ИАР там творит - не могу сказать, у него случайно не включена опция вроде "8-битный int"?

[ARV]

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

спасибо.

[Палыч]

Да, все верно вы рассуждаете.

Верно ли? Цитата из стандарта

In executing the fragment
char c1, c2;
/* ... */
c1 = c1 + c2;
the ‘‘integer promotions’’ require that the abstract machine promote the value of each variable to int size
and then add the two ints and truncate the sum. Provided the addition of two chars can be done without
overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only
produce the same result, possibly omitting the promotions.

Мои знания английского языка - не ахти какие, но, по-моему, стандарт говорит, что в данном случае "promotions" можно не выполнять.

[ARV]

ваша цитата четко подтверждает 2 вещи:
1. int promotions для char на самом деле определено в стандарте
2. для варианта С ПРИСВАИВАНИЕМ переменной типа char на самом деле смысла в promotions нет - я приводил пример ранее.

[Палыч]

для варианта С ПРИСВАИВАНИЕМ переменной типа char на самом деле смысла в promotions нет - я приводил пример ранее.

ИМХО, стандарт допускает не использовать promotions с переменными типа char не в зависимости от оператора (присваивание или сравнение), а от

...without overflow, or with overflow wrapping silently...

Кроме того, если выражение справа вычислять отдельно (как в вашем примере), то и выполнение оператора сравнения меняет результат. Что, по-моему, слабо согласуется с "correct result", упомянутому в стандарте.

[ARV]

лично я совсем не усматриваю того, что вы.

если выражение справа вычислять отдельно, то в конечном итоге мы получаем сравнение char == char, которое с учетом promotion превращается в int == int, но, т.к. переменная v4 содержит УЖЕ УСЕЧЕННЫЙ результат вычисления, то promotion заключается в "приписывании" в старший байт 0 - делается это для обоих переменных и никак не меняет результата. в то время как в первом случае promotion делается так же для обоих сторон выражения, но при этом слева к переменной приписывается 0 в старший байт, а справа - старший байт ВЫЧИСЛЯЕТСЯ. promotion делается независимо от оператора, просто результатом оперции присваивания являтся значение переменной, которая получает значение, и этот результат просто никому не нужен (в данном примере).

[demiurg_spb]

OFF:Не понимаю, почему народ не пишет

Код

PORTB = (v1 != (v2+v3));

это абсолютно равнозначно тому что написал ТС, но компактнее на 3 сторчки!

[ReAl]

Promotion можно не выполнять (удалять в процессе оптимизации) только тогда, когда observable behavior не изменяется.
Т.е. если результат у «абстрактной машины», которая медленно и печально делает все строго по стандарту, и у реального кода не отличается.
В случае присваивания c3 = c1 + c2; результат (содержимое c3, которое будет из него прочитано следующими операторами) с promotion и без оного не отличается, это известно заранее, поэтому можно и не делать.
В случае if ( а тут вычисления ) — не так. Поэтом делать обязательно.

Ну и на закуску — этот пример на codepad (там можно набирать любой код, жать кнопку submit и смотреть результат компиляции и выполнения)

avr-gcc иногда страдает недовыбрасыванием promotion при оптимизации. Как я недавно где-то писал — пусть лучше так, чем он мне что-то не пос тандарту сделает, а я буду сидеть и думать в чём дело.

если выражение справа вычислять отдельно, то
...
в то время как в первом случае promotion делается так же для обоих сторон выражения, но при этом слева к переменной приписывается 0 в старший байт, а справа - старший байт ВЫЧИСЛЯЕТСЯ.

Именно так.
На мой взгляд, IAR перестарался с оптимизацией. Так таки всё нормально? Это кто-то где-то недоразобравшись бочку покатил?

[_Ivana]

Насколько я ничего не знаю в стандарте С, то тут или это дыра в стандарте, или пока никто не привел прямую цитату с однозначным толкованием данного случая.

Если при проверке на равенство вычисляется тип и значение левого выражения, а правое приводится к этому же типу - то будет один результат. Если вычисляются типы и значения обоих выражений и меньший тип расширяется до большего, то другой. Если они сразу приводятся к int, то может быть ещё моменты.

Кстати, глупый вопрос - а если поменять местами и написать if ((v2 + v3) == v1) результат не поменяется ни в каком компиляторе?
И ещё один - с превышением разрядности при сравнении суммы переменных типа int такой дырки в стандарте нет?

[ARV]

Ну и на закуску — этот пример на codepad (там можно набирать любой код, жать кнопку submit и смотреть результат компиляции и выполнения)

а доверять такой проверке можно ВСЕГДА? то есть там механизм строко по стандарту делает просчет?

кстати, ReAl, если не затруднит, еще один вопрос по стандарту...

что стандарт говорит по поводу порядка вычисления выражения? имеем выражение вида A # B # C # D, где A,B,C и D - любые допустимые выражения, а # - любые допустимые операции/операторы с одинаковым приоритетом. что стандарт говорит по поводу порядка вычисления A,B,C и D? или даже чуть иначе: в выражении

Код

(A # B) == (C # D)

определена очередность выражения слева и справа, а так же что будет "первее" вычислено: A или B (С или D) ?

[Палыч]

лично я совсем не усматриваю того, что вы.

Может быть Вы и правы, но выглятит как-то "странным" получить разные результаты выполнения двух, следующих друг за другом условных операторов в таком примере

Код

if (v1 == (v4 = (v2+v3) ) ) { .... }
if (v1 == v4 ) { .... }

[Idle]

предлагаю, наконец, _проверить_ в IAR

[ReAl]

Насколько я ничего не знаю в стандарте С, то тут или это дыра в стандарте, или пока никто не привел прямую цитату с однозначным толкованием данного случая.

Ну так вот и почитайте стандарт самостоятельно. Стандарт существует и независимо от приведения цитаты, так что «или - или» тут не катит. Искать и приводить цитату на этот раз не буду — чем больше я это делаю, тем больше мне говорят, что я выпедриваюсь никому не нужными знаниями. Потрудитесь получить их самостояельно.

Если при проверке на равенство вычисляется тип и значение левого выражения, а правое приводится к этому же типу - то будет один результат. Если вычисляются типы и значения обоих выражений и меньший тип расширяется до большего, то другой. Если они сразу приводятся к int, то может быть ещё моменты.

Ну так вот и найдите в стандарте это место. Аглицкое слово promotion уже подсказали, осталось поиск по тексту произвести самостоятельно.

В вычислениях приводится к самому «старшему» из принимающих участие типов. Достатончо простой логики. Иначе в

Код

unsignd long total;
unsigned char value;
total = total + value;

total никода не превысит 255.
В вычислениях типы меньше int — приводится к int. Это уже специфика С.

Кстати, глупый вопрос - а если поменять местами и написать if ((v2 + v3) == v1) результат не поменяется ни в каком компиляторе?

Если поменяется — то это вообще п’яный какой-то компилятор.

И ещё один - с превышением разрядности при сравнении суммы переменных типа int такой дырки в стандарте нет?

Тут ВООБЩЕ ДЫРКИ НЕТ.

[Rst7]

наткнулся на тему на другом форуме - говорят, таки да...

А проверить религия не позволила?

CODE

///////////////////////////////////////////////////////////////////////////////
// /
// IAR C/C++ Compiler V5.50.0.50277/W32 for Atmel AVR 20/Jan/2012 11:40:15 /
// Copyright © 1996-2010 IAR Systems AB. /
// /
// Source file = E:\AVR\TestVolatile\main.c /
// Command line = E:\AVR\TestVolatile\main.c --cpu=m128 -ms -o /
// E:\AVR\TestVolatile\Release\Obj\ -D NDEBUG -lCN /
// E:\AVR\TestVolatile\Release\List\ -lB /
// E:\AVR\TestVolatile\Release\List\ -y /
// --initializers_in_flash -s9 --no_clustering -e -I /
// D:\EWAVR-5501\avr\INC\ -I D:\EWAVR-5501\avr\INC\DLIB\ /
// --eeprom_size 4096 --dlib_config /
// D:\EWAVR-5501\avr\LIB\DLIB\dlAVR-3s-ec_mul-n.h /
// List file = E:\AVR\TestVolatile\Release\List\main.s90 /
// /
// /
///////////////////////////////////////////////////////////////////////////////

....

// 41 void foo(void)
foo:
// 42 {
// 43 if (v1 == (v2+v3))
LDS R20, v1
LDI R21, 0
LDS R18, v2
LDI R19, 0
LDS R16, v3
ADD R18, R16
ADC R19, R21
CP R20, R18
CPC R21, R19
BRNE ??foo_0
// 44 PORTB = 0;
OUT 0x18, R21
RET
// 45 else
// 46 PORTB = 1;
??foo_0:
LDI R16, 1
OUT 0x18, R16
// 47 }
RET

Integer Promotion в наличии, никаких отклонений.

[sonycman]

Прогнал этот код в IAR 6.30.4 для ARM:

Код

    volatile unsigned char v1 = 1;
    volatile unsigned char  v2 = 255;
    volatile unsigned char  v3 = 2;

    int result;
    if (v1 == (v2+v3)) result = 0;
    else result = 1;

результат - result = 1;
Сравнение производится в интах:

Код

   \   00000044   0xF89D 0x0002      LDRB     R0,[SP, #+2]
   \   00000048   0xF89D 0x1001      LDRB     R1,[SP, #+1]
   \   0000004C   0xF89D 0x2000      LDRB     R2,[SP, #+0]
   \   00000050   0x1851             ADDS     R1,R2,R1
   \   00000052   0x4288             CMP      R0,R1
   \   00000054   0xBF0C             ITE      EQ
   \   00000056   0x2100             MOVEQ    R1,#+0
   \   00000058   0x2101             MOVNE    R1,#+1

Всё нормально у ИАРа со стандартами.
А вот оптимизатор слабенький и всё ещё не дотягивает до оного в Кейле

[Rst7]

Прогнал этот код в IAR 6.30.4 для ARM:

Ну вообще-то речь об AVR, если уж быть до конца корректным.

А вот оптимизатор слабенький и всё ещё не дотягивает до оного в Кейле

Это Вам кажется.

[ARV]

А проверить религия не позволила?

я не использую IAR по религиозным принципам (он не бесплатный). так что вы правы

[ReAl]

Может быть Вы и правы, но выглятит как-то "странным" получить разные результаты выполнения двух, следующих друг за другом условных операторов в таком примере

Код

if (v1 == (v4 = (v2+v3) ) ) { .... }
if (v1 == v4 ) { .... }

Это третий пример. В нем в операторе == одним из операндов является резальтат «присваивающего выражения» (v4 = (v2+v3) ).
Результатом присваивающего выражения A = B по стандарту есть значение выражения B, приведённое к типу A со снятыми квалификаторами.

Т.е. запись

Код

if (v1 == (v4 = (v2+v3) ) ) { .... }

с точки зрения результата оператора == абсолютно эквивалентна

Код

if (v1 == (unsigned char)(v2+v3) ) { .... }

и Вы не будете удивлены.

[ARV]

Ну вообще-то речь об AVR, если уж быть до конца корректным.

речь была вообще-то о Си.

я надеялся, что Си в любом компиляторе одинаков, вот и спросил, когда увидел высказывания о том, что IAR делает нечто странное с моей т.з.

[sonycman]

Это Вам кажется.

Ага, особенно показалось, что МП3 декодер, скомпилированный этими компиляторами, отличается по скорости на 15%.

Пока ещё компилятор ИАР не конкурент для RealView, к сожалению.

[ReAl]

а доверять такой проверке можно ВСЕГДА? то есть там механизм строко по стандарту делает просчет?

«Я не знаю, но эти двое его шефом называют» © анек про цены на трёх попугаев.
1) На программистских форумах часто встречал ссылки на codepad. Их таких много http://en.wikipedia.org/wiki/Comparison_of_pastebins. В данном случае у меня кроме gcc, головы и интернета рядом ничего нет, поэтому для увеличения явки на голосование ещё и туда послал.

что стандарт говорит по поводу порядка вычисления выражения? имеем выражение вида A # B # C # D, где A,B,C и D - любые допустимые выражения, а # - любые допустимые операции/операторы с одинаковым приоритетом. что стандарт говорит по поводу порядка вычисления A,B,C и D? или даже чуть иначе: в выражении

Код

(A # B) == (C # D)

определена очередность выражения слева и справа, а так же что будет "первее" вычислено: A или B (С или D) ?

Сами вычисления подвыражений A, B, C, D — в произвольном порядке.
Вычисления операндов оператора == — в произвольном порядке (порядок вычисления операндов определён только для && и || да и то только в С и для неперегруженных в С++, перегруженные — это функции, а порядок вычисления аргументов функций неопределён).

Для цепочек операторов в выражениях — порядок слева направо или, редко, справа налево (например, A = B = C = D;).
Но там, где мне лично порядок важен, я ставлю скобки.

p.s. иду работать, а то так весь день уйдёт.

[Rst7]

я не использую IAR по религиозным принципам

Тогда, позвольте спросить - зачем открыли тему? Думали холиварчик локальный разжечь - "проприентарщина говно, опенсорс рулит"? Так это не на этот форум, пожалуйста.

Ага, особенно показалось, что МП3 декодер, скомпилированный этими компиляторами, отличается по скорости на 15%.

Версия компилятора, что за декодер и так далее. Классический прокол - в декодере всякая низкоуровневая математика запилена с использованием inline-ассемблера GCC, а для других компиляторов - просто сишный код, не самый оптимальный.

Ну да ладно, тут это оффтоп крепкий.

[ARV]

p.s. иду работать, а то так весь день уйдёт.

преогромное Вам спасибо!

неужели нет какой-то организации, которая официально переводит международные стандарты? хочется, наконец, самому все прочесть, но уровень владения языком позволит сделать это лишь к пенсии, а доверять переводу google-translator просто страшно...

[_Ivana]

ReAl, спасибо за наводку, попозже внимательно проштудирую стандарт самостоятельно (сейчас тоже работаю у заказчиков, неудобно) У меня ещё всего ~25 сообщений только, я не успел вам ни разу сказать что вы не к месту хвастаетесь знаниями

[Rst7]

я надеялся, что Си в любом компиляторе одинаков

Си одинаков, а вот оптимизатор может и ошибаться. Он-то пилен под каждый таргет свой.

[ARV]

Тогда, позвольте спросить - зачем открыли тему?

извольте, я отвечу: я стараюсь постоянно учиться. и вот в один момент я вижу, как кое-кто приводит пример со ссылкой на IAR, причем пример этот переворачивает с ног на голову все то, чему я уже научился. и что прикажете делать? вот я и начал тему, по-моему, ее название говорит само за себя, и раздел форума соответствующий. по слухам-то IAR очень хороший продукт, а тут - такое...

[Rst7]

а тут - такое...

Какое - такое? Сами Вы проверить информацию отказались по религиозным соображениям.

вот я и начал тему, по-моему, ее название говорит само за себя

Вот именно. Очень толстый вброс detected.

[sonycman]

Версия компилятора, что за декодер и так далее. Классический прокол - в декодере всякая низкоуровневая математика запилена с использованием inline-ассемблера GCC, а для других компиляторов - просто сишный код, не самый оптимальный.

Компилер 6.30.4, декодер от RealNetworks, почти всё там на си, код не сильно оптимальный, согласен, но этот же код RealView умеет готовить лучше
Я приводил результаты компиляции здесь, если Вам интересно.
В частности, там во втором посте приведён пример компиляции ИАРом простого цикла, на котором он просто "потерялся" и навернул нечто несуразное...

Сорри за офтоп.

[ARV]

Какое - такое? Сами Вы проверить информацию отказались по религиозным соображениям.
Вот именно. Очень толстый вброс detected.

сам я проверил в WinAVR и получил прогнозируемый результат (не тот, о котором говорили на стороне те, кто проверял в IAR-е).а что касается вброса - то лично я, пока не стал вам отвечать, не развивал холивар и не поддерживал его. так что вбросом становится не бросок камня в воду, а круги, им порождаемые. все, что меня интересовало - я уже получил, спасибо тем, кто помог, я уже сказал.

[Genadi Zawidowsk...]

но точно помню, что в нем сказано буквально следующее: при вычислении выражений переменные типа char и unsigned char всегда неявно преобразуются к типу int и unsigned int соответственно

Хотел бы уточнить/проинформировать уважаемое собрание. Процитированное поведение было предложено K&R в первом варианте языка (который так и называется). В последующих редакциях, в том числе и перешедьшей в ANSI стандарт, и signed char и unsigned char (каждый своим способом) преобразуются к int перед выполнением остальных действий по integer promotion.

Сообщение отредактировал Genadi Zawidowski - Jan 21 2012, 00:08

[zombi]

off
Хотите чтоб всё работало правильно пишите на асме!!!!!

[_Артём_]

off
Хотите чтоб всё работало правильно пишите на асме!!!!!

Изыди сатана!
Асм - зло!
Отладчики суть диавольское искушение!
Хекс - грех!
Истинны только "0" и "1"!
Программировать тумблерами в двоичном коде!
Так обретёте рай и спасение!

[zombi]

...
Программировать тумблерами в двоичном коде!
...

Это уже перебор! хотя и такое было

Я просто хочу сказать что при сложении двух байтов в случае переполнения выставляется бит Carry и это единственный СТАНДАРТ которому приходится доверять!!!
Анализировать этот бит или нет или не допустить его возникновения личное дело программиста.