Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: IAR: вопрос типа "глазам не верю"
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
ARV
Jan 20 2012, 07:08
Неужели правда в 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
Jan 20 2012, 07:12
Цитата(ARV @ Jan 20 2012, 11:08) *
Неужели правда в IAR в результате такого кодав PORTB действительно будет выведен 0? наткнулся на тему на другом форуме - говорят, таки да...

А почему бы и нет?
255 + 2 = 1;
1 == 1;
PORTB = 0;
ARV
Jan 20 2012, 07:13
ну потому, что как бы 1 должно выводиться... WinAVR, например, именно так поступает sm.gif
arttab
Jan 20 2012, 07:27
ff это 255 т.е. максимальное значение. 255 + 1 = 0. поясню ff + 1h = 100h поскольку unsigned char получаем 00h
соответственно ffh +2 = 101h -> 01h
ARV
Jan 20 2012, 07:39
а как же быть с тем, что по стандарту языка Си в выражениях char автоматически преобразуется к int?
MrYuran
Jan 20 2012, 07:48
Цитата(ARV @ Jan 20 2012, 11:39) *
а как же быть с тем, что по стандарту языка Си в выражениях 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
Jan 20 2012, 07:59
я не супер-знаток стандарта, и тем более его пунктов и подпунктов, но точно помню, что в нем сказано буквально следующее: при вычислении выражений переменные типа 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
Jan 20 2012, 08:14
Цитата(ARV @ Jan 20 2012, 11:59) *
я не супер-знаток стандарта, и тем более его пунктов и подпунктов, но точно помню, что в нем сказано буквально следующее: при вычислении выражений переменные типа char и unsigned char всегда неявно преобразуются к типу int и unsigned int соответственно.

Ну вот теперь все встало на свои места.
Спасибо за разъяснения!
То, что у ИАРа своя логика, иногда противоречащая стандартам, и так известно.
У меня с ним отношения не сложились, и как раз касательно if()-ов. Столько раз получал граблями в лоб, но постепенно привык.
А теперь вот на GCC переполз.
ARV
Jan 20 2012, 08:21
Цитата(MrYuran @ Jan 20 2012, 12:14) *
Ну вот теперь все встало на свои места.
Спасибо за разъяснения!
оно-то, конечно, пожалуйста... но как бы я сам разъяснения просил rolleyes.gif
sparcmaster
Jan 20 2012, 08:22
Цитата из Шилдта:
Цитата
Преобразования типов в выражениях

Если в выражении встречаются переменные и константы разных типов, они преобразуются к одному типу. Компилятор преобразует "меньший" тип в "больший". Этот процесс называется продвижением типов (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 прав.
Сергей Борщ
Jan 20 2012, 08:22
QUOTE (ARV @ Jan 20 2012, 09:59) *
собственно, я и задал вопрос с целью разобраться в этом вопросе
Да, все верно вы рассуждаете. 255+2 = 257, 257 != 1. Сравнение должно производиться в intах. Оптимизатор может выкинуть проверку старшего байта если это не повлияет на результат, как в вашем примере с v4. Что ИАР там творит - не могу сказать, у него случайно не включена опция вроде "8-битный int"?
ARV
Jan 20 2012, 08:31
ну, если я рассуждаю верно - это меня сильно успокоило. а что там включено в IAR-е я не знаю: я прочел на другом форуме спор по этой теме, и поразился. а там народ, юзающий IAR, просто утверждает, что у них работает вот так. настройки не были озвучены.

спасибо.
Палыч
Jan 20 2012, 08:34
Цитата(Сергей Борщ @ Jan 20 2012, 12:22) *
Да, все верно вы рассуждаете.

Верно ли? Цитата из стандарта
Цитата
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
Jan 20 2012, 08:49
ваша цитата четко подтверждает 2 вещи:
1. int promotions для char на самом деле определено в стандарте
2. для варианта С ПРИСВАИВАНИЕМ переменной типа char на самом деле смысла в promotions нет - я приводил пример ранее.
Палыч
Jan 20 2012, 09:06
Цитата(ARV @ Jan 20 2012, 12:49) *
для варианта С ПРИСВАИВАНИЕМ переменной типа char на самом деле смысла в promotions нет - я приводил пример ранее.

ИМХО, стандарт допускает не использовать promotions с переменными типа char не в зависимости от оператора (присваивание или сравнение), а от
Цитата
...without overflow, or with overflow wrapping silently...
Кроме того, если выражение справа вычислять отдельно (как в вашем примере), то и выполнение оператора сравнения меняет результат. Что, по-моему, слабо согласуется с "correct result", упомянутому в стандарте.
ARV
Jan 20 2012, 09:15
лично я совсем не усматриваю того, что вы.

если выражение справа вычислять отдельно, то в конечном итоге мы получаем сравнение char == char, которое с учетом promotion превращается в int == int, но, т.к. переменная v4 содержит УЖЕ УСЕЧЕННЫЙ результат вычисления, то promotion заключается в "приписывании" в старший байт 0 - делается это для обоих переменных и никак не меняет результата. в то время как в первом случае promotion делается так же для обоих сторон выражения, но при этом слева к переменной приписывается 0 в старший байт, а справа - старший байт ВЫЧИСЛЯЕТСЯ. promotion делается независимо от оператора, просто результатом оперции присваивания являтся значение переменной, которая получает значение, и этот результат просто никому не нужен (в данном примере).
demiurg_spb
Jan 20 2012, 09:17
OFF:Не понимаю, почему народ не пишет
Код
PORTB = (v1 != (v2+v3));
это абсолютно равнозначно тому что написал ТС, но компактнее на 3 сторчки!
ReAl
Jan 20 2012, 09:27
Promotion можно не выполнять (удалять в процессе оптимизации) только тогда, когда observable behavior не изменяется.
Т.е. если результат у «абстрактной машины», которая медленно и печально делает все строго по стандарту, и у реального кода не отличается.
В случае присваивания c3 = c1 + c2; результат (содержимое c3, которое будет из него прочитано следующими операторами) с promotion и без оного не отличается, это известно заранее, поэтому можно и не делать.
В случае if ( а тут вычисления ) — не так. Поэтом делать обязательно.

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

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

Цитата(ARV @ Jan 20 2012, 11:15) *
если выражение справа вычислять отдельно, то
...
в то время как в первом случае promotion делается так же для обоих сторон выражения, но при этом слева к переменной приписывается 0 в старший байт, а справа - старший байт ВЫЧИСЛЯЕТСЯ.
Именно так.
На мой взгляд, IAR перестарался с оптимизацией. Так таки всё нормально? Это кто-то где-то недоразобравшись бочку покатил?
_Ivana
Jan 20 2012, 09:27
Насколько я ничего не знаю в стандарте С, то тут или это дыра в стандарте, или пока никто не привел прямую цитату с однозначным толкованием данного случая.

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

Кстати, глупый вопрос - а если поменять местами и написать if ((v2 + v3) == v1) результат не поменяется ни в каком компиляторе?
И ещё один - с превышением разрядности при сравнении суммы переменных типа int такой дырки в стандарте нет?
ARV
Jan 20 2012, 09:29
Цитата(ReAl @ Jan 20 2012, 13:17) *
Ну и на закуску — этот пример на codepad (там можно набирать любой код, жать кнопку submit и смотреть результат компиляции и выполнения)
а доверять такой проверке можно ВСЕГДА? то есть там механизм строко по стандарту делает просчет?

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

что стандарт говорит по поводу порядка вычисления выражения? имеем выражение вида A # B # C # D, где A,B,C и D - любые допустимые выражения, а # - любые допустимые операции/операторы с одинаковым приоритетом. что стандарт говорит по поводу порядка вычисления A,B,C и D? или даже чуть иначе: в выражении
Код
(A # B) == (C # D)
определена очередность выражения слева и справа, а так же что будет "первее" вычислено: A или B (С или D) ?
Палыч
Jan 20 2012, 09:34
Цитата(ARV @ Jan 20 2012, 13:15) *
лично я совсем не усматриваю того, что вы.

Может быть Вы и правы, но выглятит как-то "странным" получить разные результаты выполнения двух, следующих друг за другом условных операторов в таком примере
Код
if (v1 == (v4 = (v2+v3) ) ) { .... }
if (v1 == v4 ) { .... }
Idle
Jan 20 2012, 09:38
предлагаю, наконец, _проверить_ в IAR
ReAl
Jan 20 2012, 09:39
Цитата(_Ivana @ Jan 20 2012, 11:27) *
Насколько я ничего не знаю в стандарте С, то тут или это дыра в стандарте, или пока никто не привел прямую цитату с однозначным толкованием данного случая.
Ну так вот и почитайте стандарт самостоятельно. Стандарт существует и независимо от приведения цитаты, так что «или - или» тут не катит. Искать и приводить цитату на этот раз не буду — чем больше я это делаю, тем больше мне говорят, что я выпедриваюсь никому не нужными знаниями. Потрудитесь получить их самостояельно.


Цитата(_Ivana @ Jan 20 2012, 11:27) *
Если при проверке на равенство вычисляется тип и значение левого выражения, а правое приводится к этому же типу - то будет один результат. Если вычисляются типы и значения обоих выражений и меньший тип расширяется до большего, то другой. Если они сразу приводятся к int, то может быть ещё моменты.
Ну так вот и найдите в стандарте это место. Аглицкое слово promotion уже подсказали, осталось поиск по тексту произвести самостоятельно.

В вычислениях приводится к самому «старшему» из принимающих участие типов. Достатончо простой логики. Иначе в
Код
unsignd long total;
unsigned char value;
total = total + value;
total никода не превысит 255.
В вычислениях типы меньше int — приводится к int. Это уже специфика С.

Цитата(_Ivana @ Jan 20 2012, 11:27) *
Кстати, глупый вопрос - а если поменять местами и написать if ((v2 + v3) == v1) результат не поменяется ни в каком компиляторе?
Если поменяется — то это вообще п’яный какой-то компилятор.

Цитата(_Ivana @ Jan 20 2012, 11:27) *
И ещё один - с превышением разрядности при сравнении суммы переменных типа int такой дырки в стандарте нет?
Тут ВООБЩЕ ДЫРКИ НЕТ.
Rst7
Jan 20 2012, 09:40
QUOTE
наткнулся на тему на другом форуме - говорят, таки да...


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

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
Jan 20 2012, 09:41
Прогнал этот код в 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


Всё нормально у ИАРа со стандартами.
А вот оптимизатор слабенький и всё ещё не дотягивает до оного в Кейле sad.gif
Rst7
Jan 20 2012, 09:44
QUOTE
Прогнал этот код в IAR 6.30.4 для ARM:


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

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


Это Вам кажется.
ARV
Jan 20 2012, 09:48
Цитата(Rst7 @ Jan 20 2012, 13:40) *
А проверить религия не позволила?
я не использую IAR по религиозным принципам (он не бесплатный). так что вы правы sm.gif
ReAl
Jan 20 2012, 09:48
Цитата(Палыч @ Jan 20 2012, 11:34) *
Может быть Вы и правы, но выглятит как-то "странным" получить разные результаты выполнения двух, следующих друг за другом условных операторов в таком примере
Код
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
Jan 20 2012, 09:51
Цитата(Rst7 @ Jan 20 2012, 13:44) *
Ну вообще-то речь об AVR, если уж быть до конца корректным.
речь была вообще-то о Си.

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


sonycman
Jan 20 2012, 09:53
Цитата(Rst7 @ Jan 20 2012, 13:44) *
Это Вам кажется.

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

Пока ещё компилятор ИАР не конкурент для RealView, к сожалению.
ReAl
Jan 20 2012, 09:59
Цитата(ARV @ Jan 20 2012, 11:29) *
а доверять такой проверке можно ВСЕГДА? то есть там механизм строко по стандарту делает просчет?
«Я не знаю, но эти двое его шефом называют» © анек про цены на трёх попугаев.
1) На программистских форумах часто встречал ссылки на codepad. Их таких много http://en.wikipedia.org/wiki/Comparison_of_pastebins. В данном случае у меня кроме gcc, головы и интернета рядом ничего нет, поэтому для увеличения явки на голосование ещё и туда послал.

Цитата(ARV @ Jan 20 2012, 11:29) *
что стандарт говорит по поводу порядка вычисления выражения? имеем выражение вида 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
Jan 20 2012, 10:06
QUOTE
я не использую IAR по религиозным принципам


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

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


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

Ну да ладно, тут это оффтоп крепкий.
ARV
Jan 20 2012, 10:06
Цитата(ReAl @ Jan 20 2012, 13:59) *
p.s. иду работать, а то так весь день уйдёт.
преогромное Вам спасибо!

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


_Ivana
Jan 20 2012, 10:06
ReAl, спасибо за наводку, попозже внимательно проштудирую стандарт самостоятельно (сейчас тоже работаю у заказчиков, неудобно) sm.gif У меня ещё всего ~25 сообщений только, я не успел вам ни разу сказать что вы не к месту хвастаетесь знаниями sm.gif
Rst7
Jan 20 2012, 10:09
QUOTE
я надеялся, что Си в любом компиляторе одинаков


Си одинаков, а вот оптимизатор может и ошибаться. Он-то пилен под каждый таргет свой.
ARV
Jan 20 2012, 10:10
Цитата(Rst7 @ Jan 20 2012, 14:06) *
Тогда, позвольте спросить - зачем открыли тему?
извольте, я отвечу: я стараюсь постоянно учиться. и вот в один момент я вижу, как кое-кто приводит пример со ссылкой на IAR, причем пример этот переворачивает с ног на голову все то, чему я уже научился. и что прикажете делать? вот я и начал тему, по-моему, ее название говорит само за себя, и раздел форума соответствующий. по слухам-то IAR очень хороший продукт, а тут - такое...
Rst7
Jan 20 2012, 10:13
QUOTE
а тут - такое...


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

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


Вот именно. Очень толстый вброс detected.
sonycman
Jan 20 2012, 10:17
Цитата(Rst7 @ Jan 20 2012, 14:06) *
Версия компилятора, что за декодер и так далее. Классический прокол - в декодере всякая низкоуровневая математика запилена с использованием inline-ассемблера GCC, а для других компиляторов - просто сишный код, не самый оптимальный.

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

Сорри за офтоп.
ARV
Jan 20 2012, 10:19
Цитата(Rst7 @ Jan 20 2012, 14:13) *
Какое - такое? Сами Вы проверить информацию отказались по религиозным соображениям.
Вот именно. Очень толстый вброс detected.
сам я проверил в WinAVR и получил прогнозируемый результат (не тот, о котором говорили на стороне те, кто проверял в IAR-е).а что касается вброса - то лично я, пока не стал вам отвечать, не развивал холивар и не поддерживал его. так что вбросом становится не бросок камня в воду, а круги, им порождаемые. все, что меня интересовало - я уже получил, спасибо тем, кто помог, я уже сказал.


Genadi Zawidowski
Jan 20 2012, 16:28
Цитата(ARV @ Jan 20 2012, 11:59) *
но точно помню, что в нем сказано буквально следующее: при вычислении выражений переменные типа char и unsigned char всегда неявно преобразуются к типу int и unsigned int соответственно


Хотел бы уточнить/проинформировать уважаемое собрание. Процитированное поведение было предложено K&R в первом варианте языка (который так и называется). В последующих редакциях, в том числе и перешедьшей в ANSI стандарт, и signed char и unsigned char (каждый своим способом) преобразуются к int перед выполнением остальных действий по integer promotion.
zombi
Jan 20 2012, 23:03
off biggrin.gif biggrin.gif biggrin.gif biggrin.gif biggrin.gif
Хотите чтоб всё работало правильно пишите на асме!!!!! disco.gif
_Артём_
Jan 21 2012, 01:24
Цитата(zombi @ Jan 21 2012, 01:03) *
off biggrin.gif biggrin.gif biggrin.gif biggrin.gif biggrin.gif
Хотите чтоб всё работало правильно пишите на асме!!!!! disco.gif


Изыди сатана!
Асм - зло!
Отладчики суть диавольское искушение!
Хекс - грех!
Истинны только "0" и "1"!
Программировать тумблерами в двоичном коде!
Так обретёте рай и спасение!
zombi
Jan 21 2012, 07:05
Цитата(_Артём_ @ Jan 21 2012, 05:24) *
...
Программировать тумблерами в двоичном коде!
...

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

Я просто хочу сказать что при сложении двух байтов в случае переполнения выставляется бит Carry и это единственный СТАНДАРТ которому приходится доверять!!!
Анализировать этот бит или нет или не допустить его возникновения личное дело программиста.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.