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







При дизасме в первом случае, вижу на мой взгляд абсолютно бесполезную строчку

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

Кто-нибудь может пояснить значение этой строчки??? Рботающий и неработающий коды отличаются только ей. И чем собственно коснтрукция ? : ; для компилятора отличается от if else?

В первом случае в условии проверка на ненулевое значение, а во втором - на положительное. Может в этом разница ?

? : возвращает результат, if else - нет. Больше вроде бы ничем.

Собственно в строчке LDS R24,0x00CE , насколько я понял, и возвращается результат операции UDR1 = data.

Нескромный вопрос: tty у Вас volatile? Просто не могу себе представить ситуацию, когда селектором устройств является не volatile переменная...

Да собственно говоря в if можно и на равенство 0 проверять, асм будет такой же (постоянство радует ).

Меня просто напрягает, свободное обращение с регистром уарта UDR. Ведь и запись и чтение этого регистра запускают определённые физические процессы в уарте. А тут захотелось ему, он взял и вычитал значение из этого регистра в R24. Неприятное явление.

ЗЫ В IAR и тот и другой случаи работают нормально.




0x00CE это адрес UDR регистра, я не понимаю как это строчка может сообщать о результате операции.




К моему стыду действительно не volatile. Эта переменная часть структуры, описывающей уарт

Ну вероятно GGC полагает, что результатом операции a=b является значение "a" после операции присваивания. А "а" у вас - UDR1 - вероятно помеченный volatile или еще как-то. Вот его значение и вычитывается...

И еще вопросик - я не въеду, где в приведенном вами дизасме происходит сравнение tty c 0? Или вы привели только кусочек?

Выполняется (UDR1 = data) и результат выражения - это значение UDR1, которое надо предварительно прочитать, из-за того, что оно описано volatile. А то, что результат больше никому не нужен - это уже совсем другая история.

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

Да это кусок был...

вот более полная версия , с сравнением :


Это дизасм библиотечки, так что нет всех адресов

Ок. В принципе понял свою ошибку.

Кстати, по-идее даже просто запись UDR1=data должна приводить к вычитыванию UDR1

Т.е. получается что на один шаг оптимизатор срабатывает (выкидывая чтение в данном случае), а вот на два шага - в случае tty ? UDR1 = data : UDR0 = data - уже нет...

Вот автор сказал, что ИАР выкинул лишнее чтение, а мне грустно: если компилер таким изящным манером исправил логическую ошибку программиста (согласитесь, ошибка ведь была), то где гарантия, что не бывает обратных ситуаций, т.е. абсолютно правильные с точки зрения логики действия программера цензурируются оптимизатором и это рождает ошибку.
В общем, я все больше начинаю понимать gcc

А собственно компилятор ошибок и не исправляет, если уж на то пошло. А скорее всего это строчки убираются в процессе оптимизации. Так что я бы не стал обвинять ни iar ни gcc.

Просто как показала практика у iar оптимизация тщательней делается

Я собственно имел в виду, что обе строчки


Должны приводить к вычитыванию UDR1...

Только в первом случае это чтение оптимизится, а во втором нет...

Никакая оптимизация не должна выкидывать чтение volatile переменной. Обсуждение было в теме http://electronix.ru/forum/index.php?showtopic=54275

Ну тогда получается, что конструкции вида

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

Зачем доводить идею до абсурда.



А в случае с уартом в avr, будет полная неразбериха в линии.
И ещё смысл делать read для write-only регистров