И что? Тип char - тоже integer type, что не мешает ему иметь размер 8 бит...
Тут проблема совсем в другом: результат выражения (flags & 0xe0) всегда дает нули во всех байтах кроме младшего. Поэтому вменяемый оптимизатор должен выкинуть их вычисление из генерируемого кода. У меня так и происходит (см. выше). Почему этого не происходит у sonycman, непонятно...

не "стандартам больших машин", а правилам языка C.
Поверь, тебе это не нужно. Я слышал о компиляторах, у которых такая опция есть. Но писать программы с рассчетом на такую опцию - значит писать их не на языке C. То есть сразу теряется совместимость с любыми другими C компиляторами, у которых такой опции нет. Плюс периодически ломать голову над тем, почему результат выражения получился вот такой, а не такой, какой ожидался. Ты хочешь, чтобы у тебя (127 + 127) / 2 давало -1? И все ради чего? Ради экономии пары процентов машинного кода?

byte определён как unsigned char.
Версия компилятора - 4.3.2 - последний релиз кандидат.
Оптимизациия Оs.
Полностью командные строки компилятора и линкера я приводил немного ранее.

Странно всё это...

Расмотрим пример (x = 20):
#define LCD_WIDTH 240

void lcdPrintText(PGM_P text, byte flags, unsigned char x, signed char y)
{
x = (LCD_WIDTH + x ) / 2;
}

Если расчеты выполняються в 16-битном виде то:
x = (240 + 20) / 2 = 260 /2 = 130.

Если в 8-битной то:
x = (240 + 20) / 2 = 4 /2 = 2.

Вы все еще хотите такую оптимизацию?

Анатолий.

2aesok
Если у меня в программе операнд имеет тип char, то это значит, что ни при каких условиях не будет достигнуто переполнение.
Следуя вашей логике, можно и операнды типа word обрабатывать, расширяя до double word...

Все понятно. Просто я немного в другом стиле пишу, посему стараюсь ручками прикручивать в нужных местах принудительные касты. Давно это делаю на автоматизме, посему малость торможу.

Только не надо спрашивать, как это - "в другом стиле", на форуме выложенно достаточно, чтобы оценить кривость моих рук

Я вам привел пример когда оба операнда имеют тип char, и происходит переполнение.



Компилятор это за вас не сделает, но если Вы не хотите получит ошибку переполнения, то Вы проанализируете исходные данные и формулы, и возжможно, да будете выполнять промежуточные расчеты с 32-битными числами, даже если операнды и результат 16-битные.

Анатолий.



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

Анатолий.

Этот пример не имеет ничего общего с моим приложением.
Как не трудно было заметить из моего примера, константа LCD_WIDTH всегда складывается с отрицательным числом. Плюс операнды имеют значения, не допускающие переполнения.

Насчёт кривости рук - что вы скажете про то, откуда берутся странные предупреждения об обязательной инициализации и так инициализированных строковых массивов, расположенных в памяти программ?

Это Ваш пример?


(LCD_WIDTH + x - lcdGetStringWidth(text)) = 96 + [-128..-1] - [0..255] = [95..-287]

Это чисто попещаеться в signed char? В unsigned char?



Исходники GCC находяться здесь http://gcc.gnu.org/viewcvs/ Вы можете убрать мешающие Вам предупреждения сами.

Анатолий.

Сообщение отредактировал aesok - Nov 27 2008, 19:54

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

Как? Я, у которого в программе переполнения на каждом шагу, должен исправлять глюки "умного" компилятора, который стараеться генерировать правильный код в не зависимости от кривости рук програмиста?


Что-то мне кажется, что мы ведём непродуктивный диалог.

После того, как было установлено, что приведение операндов к 16-ти битам делается для того, чтобы просто удовлетворять стандарту, вы хотите сказать, что это не так?
Что на самом деле этот шаг направлен на предотвращение переполнения?




Добрался до компа. На всякий случай повторю повнятнее:
У меня WinAVR 20081118rc2 с компилятором GCC 4.3.2.
Оптимизация Os плюс ещё несколько "фишек".
Командная строка компилятора:

Скомпилировал твой пример, вот что получилось:

и листинг:

Причем тут я? Я человек я мог бы Вас и понять. Я Вам показываю как думает тупая железка, тоесть компилятор. Где Вы ему сказали что " операнды имеют значения, не допускающие переполнения"?

Я Вам показывал вариант как это ему сказать:
x = (byte) (LCD_WIDTH + x - lcdGetStringWidth(text)) / 2;

И компилятор начал вычислять выражение как 8-битное.



Я не говорил что у Вас кривые руки, Я говорил что компилятор должен компилировать программу написанную даже кривыми руками, при этом программа должна работать в соответствии со стандартом, а в стандарте никаких указазий о скорости выполнения программы нет. Это оставленно на осмотрение разработчика компилятора.



Я попытался на примере Вам показать почему так написан стандарт.




Пока не знаю.

Анатолий.

Сообщение отредактировал aesok - Nov 27 2008, 22:28

Хм... то есть, разработчики стандарта таким образом подстраховали все вычисления с операндами типа char?
Мне всё равно трудно понять рациональность этого хода.
Потому, что ошибка с переполнением может возникнуть с любым по размеру операндом: 8, 16, 32, 64 и так далее бит.
Почему для 8-ми бит сделали исключение?


Зачем "правильно" считать результат на 16-ти битах, если в конце концов он будет разрушен, будучи "обрезанным" и "запиханным" в signed char?
Если программист не продумал все варианты - ошибка обязательно вылезет всё равно.

Да...
Но всё-же, спасибо за попытку всё объяснить. Извиняюсь за некоторое раздражение в моём тоне.
В любом случае, стандарты придумывают весьма умные дядьки, не чета таким, как я
Порой трудно бывает понять их мотивы. Воистину, пути их неисповедимы

На самом деле исключение сделано для int. Это как бы тип по умолчанию,
разрядность int обычно равна разрядности регистров общего
назначения, что гарантирует максимальную производительность для этого типа.
Для AVR разрядность int больше разрядности регистра. Сделать int 8-битным
нельзя, в стандарте требуется - размерность указателя равна размерности int,
а 8-битный указатель это слишком мало.


Если быть совсем точным то avr-gcc имеет ключ:
-mint8 Use an 8-bit 'int' type

Его практическая ценность его мала, avr-libc не совместима с этим ключом, и
никогда не будет. Но если будете писать что нибудь маленькое, можете с ним
поиграться.



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



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

Анатолий.

Сообщение отредактировал aesok - Nov 27 2008, 23:26

Ну, не думаю, что компилер будет строить такие предположения.
Исходное положение:

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

то есть весь код сводится к простым операциям. Заметьте - результат выражения по-прежнему будет:

"невлезающим" в char, и "простая железка" может это просчитать как два пальца...
Но не хочет

То же самое будет, если вывести деление во вторую строку:

Первое и последнее выражения абсолютно эквивалентны по результату! Зато какие разные по размеру кода?
Тут явно что-то в этом делении...

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


Ну дай-то бог!

ЗЫ: Всем спокойной ночи!

тем самым в процессе присваивания неявно приводя результат типа int к типу x, т.е. signed char, что и советовал вам aesok:Так что, как видите, никаких чудес.
А тут деление signed char x на int 2 тоже с приведением результата. Tут компилятор смог сообразить и отбросить расширение.

как показали эксперименты, как только в switch появляется второй case, в ассемблерном коде появляется вычисление незначащего старшего байта. Склоняюсь к выводу о недостатке оптимизатора в данном случае.

Я не знаю точно, из каких соображений язык C сделан именно так, но выскажу свои соображения по этом поводу.
Во-первых, с последним утверждением согласен. Исходим из предположения, что кодер подумал, и ошибок в коде нет.

Во-вторых, я подозреваю, что вероятность выхода результата неких вычислений за границы диапазона (-128...127) намного выше чем диапазона (-32768...32767). Поэтому кодеру очень часто пришлось бы писать явное приведение к типу int, например писать (0 + a + b) / 2 вместо (a + b) / 2. Лично мне это бы не понравилось, т.к. во-первых, больше текста - больше вероятность ошибиться, а во-вторых, ухудшается читаемость кода. Почему тип приводится к int, а не к long или long long - я думаю, это компромисс между удобством и эффективностью. Случаи, когда диапазон значений int для вычислений недостаточен - достаточно редки чтобы явное приведение к long (long) не доставляло больших неудобств.

Наконец, что результат "в конце концов будет разрушен, будучи "обрезанным" и "запиханным" в signed char" - просто неверно, об этом aesok уже сказал.

Не эквивалентны. В первом случае преобразование к типу char производится перед делением, во втором - после. Например при LCD_WIDTH=96, x=32 и lcdGetStringWidth(text)=0 результат этих выражений будет разным.

Сообщение отредактировал alx2 - Nov 29 2008, 11:53