Так не полагайтесь на CSE там, где это не надо.
Поясню: если в выражении присутствует хоть одна volatile-переменная, она все равно испортит общую оптимизацию выражения. Надо ж думать, прежде чем писать!

И смысла в if (~(PINB)&(KeyMask)) много меньше, чем в if( ! (PINB & KeyMask) ). Ой, уже опередили.

Сообщение отредактировал _Pasha - Nov 18 2011, 06:26

neiver , _Pasha да действительно, можно и так написать, результат будут тотже что и в моем варианте ! С этим более менее понятно.

Неа, результат другой:

На ЦЕЛУЮ команду меньше

Это неправильное утверждение! Если из выражения "volatile register int8_t a asm ("r16");" убрать квалификатор volatile, то компилятор воообще обходит использование указанных регистров, используя свои. И хотя код получается короче, неизвестно как дальще поведет себя "оптимизатор" , если программа усложниться !


На ОДНУ команду не считается
Так исторически сложилось что я проверяю на нулевой рез-т (не нажата не одна кнопка) и зацикливаю в начало

Если Вы пытатесь заставить GCC генерить вместо if(!(PINB & KeyMask)) одну команду SBRS (или SBRC), то у Вас ничего не получится. Хотя Atmel и утверждает, что система команд AVR ориентированна на язык Си, то компиляторописатели так не считают... В Вашем первом и втором случаях компилятор действует по шаблону: 1) берёт значение на регистр r24 (то, что Вы расположили некую переменную в регистр - изменит только источник данных: значение будет взято из другого регистра или из ОЗУ): 2) на регистре r24 вычисляет выражение; 3) при необходимости, из регистра r24 сохраняет вычисленное выражение; 4) сравнивает значение выражения (регистр r24) с нулём... Только ну очень хороший оптимизатор заменит эту последовательность одной командой. GCC так сделать не сможет. Для AVR я не знаю компилятора, в который встроен настолько сильный оптимизатор, что сможет повторить Вашу программу на ассемблере.
Имхо, если компилятор с ЯВУ генерит код "съедающий" на 10-15% больше ресурсов, чем аналогичная программа на ассемблере, на сегодняшний день - это ОЧЕНЬ хороший компилятор. Заметьте - программа(!!!, причем обычно довольно большая), а не отдельный оператор.

GCC прекрасно может сгенерировать одну команду sbis (или sbiс), но не когда в маске установлены два бита:
#define KeyMask ((1<<Btn1)|(1<<Btn2))
Оставим обин бит и будет вам счастье:

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

Да, согласен...
Я собирался написать об операторе if ((--Cnt)==0) и команде DEC, но обширное обсуждение в этой теме оператора if(!(PINB & KeyMask)) сбило с мысли...

Вдумайтесь, что вы написали. Авторы компилятора указывают, что использовать volatile и register совместно нельзя. Вы обвиняете их во лжи. Достаточно смело, но бесперспективно - во-первых авторы компилятора не читают этот форум, а во-вторых - ну, продолжайте бороться с ветряными мельницами. Напоминает FAQ про яйцо и микроволновку.

ГЦЦ не умеет сливать ПП из разных точек входа в поток с одной командой возврата. Еще - бывают напряги при работе с битовыми полями, сильное юзание регистра Х в адресных выражениях, не использует бит Т и не "подглядывает" за функциями, вызываемыми из прерываний - длинный контекст сохраняется. Больше никаких шероховатостей мною не замечено. А большую программу на асме еще написать надо, чтобы "сделать" современный Си на эти 10-15%.

Подглядывает, еще как если функция inline.

с этим место собственно я разобрался.


Не понятно о чем вы говорите


большая - маленькая зависит от типа МК. Привожу конкретный пример:

программка писалась на асме под ATtiny2313, нехватило памяти программ под вторую таблицу мелодий для звонка. Если бы тогда писал на Си то вообще не хватилобы памяти на одну таблицу ! Это при том что я еще проводил оптимизацию программы в ассеблере


Что хотели написать то ?

Ну, да.
Но иногда такие места удаётся оформить в маленькие подпрограмки, которые вызывать в конце (в вумных книгах по программированию давно пишут, что не стоит бояться мелких подпрограмок :-) ). Тогда вкупе с --relax и получается слияние.

Вот еще до LTO нужно добраться, так там должно за всем подглядывать уметь. Вроде бы к 5-ой аврстудии компилятор идёт уже с LTO.
Klen-овые сборки под Linux для ARM дают неплохой эффект. Для AVR у меня не запустились, что-то с библиотеками не срослось.


Возможно то, что без зауми с asm("r19") и прочими проявлениями детской болезни левизны dec сам бы появился, и заставлять не пришлось бы (ну тут не dec, но ни по размеру кода, ни по времени выполнения не отличается — возможно, и это сказать хотели):

Паша верно перечислил основные недочёты avr-gcc, сравнив видимо с IAR, ну так и всё же IAR коммерческий продукт.
И кому так важны эти последние 5-10 % упущенной выгоды используют IAR.
А большинству это не принципиально и оно это большинство получает кайф от гнутого софта (и это не шутка).
Топик-стартеру прежде всего стоит перестать считать себя умнее компилятора и просто методично читать доки по Си и по компилятору. Глядишь через годик-другой всё наладится в голове и все нынешние "претензии" будут восприниматься с улыбкой.
ЗЫЖ приводить приемеры как мол круто я подковал блоху в позапрошлом столетии - это по меньшей мере не актуально и никого давно уже не удивляет.

К сожалению, в avr-gcc LTO не работает. Компилятор к 5-ой аврстудии скомпилирован без поддержки LTO, я пытался скомпилировать avr-gcc сам со включеной LTO - не собрался, видимо чего-то в в AVR бекэнде не хватает.

Жаль.