Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+76
.global shit
.type shit, @function
shit:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
mov r30,r24
mov r31,r25
ldd r18,Z+1
ldd r22,Z+2
mov r24,r22
ldi r25,0
ldi r26,0
ldi r27,0
mov r26,r24
mov r27,r25
clr r25
clr r24
or r25,r18
ld r18,Z
or r24,r18
ldd r18,Z+3
mov r22,r24
mov r23,r25
mov r24,r26
mov r25,r27
or r25,r18
ret
.size shit, .-shit
Вот такое ГЛОБАЛЬНОЕ ГОВНО мне делает GCC под AVR
Код разворота байтиков:
unsigned long int shit(unsigned char *a)
{
return
( unsigned long int)a[0] << 0 |
((unsigned long int)a[1] << 8 ) |
((unsigned long int)a[2] << 16) |
((unsigned long int)a[3] << 24);
}#if defined (L_bswapsi2)
;; swap bytes
;; r25:r22 = bswap32 (r25:r22)
DEFUN __bswapsi2
bswap r22, r25
bswap r23, r24
ret
ENDF __bswapsi2
#endif /* defined (L_bswapsi2) */
Запостил: 
j123123,
04 Февраля 2016
Follow us!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
https://electronics.stackexchange.com/questions/153481/avr-gcc-how-do-i-improve-code-optimization
(a>>24)|((a&0xff0000)>>8)|((a&ff00)<<8)| (a<<24)
Лучше всего оптимизируется через вот эту вот конструкцию shit_union tmp2 = (shit_union){{tmp.bytes[3],tmp.bytes[2],tmp.bytes[1],tmp.bytes[0]}};
судя по генереной ахинее в ГК, avr бэк-энд на чем-то спотыкается, и пытается в промежуточные вычисления делать аккуратно. что здесь в принципе не нужно.
и компилятор посвежее взять. Все кто говорят про мегакрутость современных компиляторов и что вот ассмблер нинужно потому что компилятр круче заоптимизирует, должны заткнуться и пойти пилить эти самые компиляторы, чтобы они перестали генерировать говнокод в ответ на ДОСТАТОЧНО ИЗВЕСТУЮ И ШИРОКО ИСПОЛЬЗУЕМУЮ КОНСТРУКЦИЮ. Всякие там htons htonl именно так через сдвиги и написаны, но компилятор делает из этого кода какое-то дичайшее говно на ассемблере
сам виноват что говно-непроцессором пользуешься. гцц сам по себе и не виноват то - ругайся на авторов AVR которые поддержку оного в гцц и добавляли.
с одной стороны. с другой стороны компилером пользоватся надо уметь. тот огород типов и конверсий который городишь в оригинальном коде указывает что ты просто не дорос еще до почётного звания байтоёба.
PS авр нету. но на intel & arm, байтсвап как описан ниже генерирует 2-3 инструкции (weak alignment, и может быть дюжину при побайтовом чтении из памяти). твое говно генерит кучу потому что ты идиот ренундантно типы конвертишь.
Там int 16-битный.
P.S. Пишут, что в 2006 году avr-gcc вообще 47 команд генерил в ответ на bswap32... Так что прогресс :)
P.P.S. Вот и отличный пруф про хуёвые конпеляторы в embedded, о которых я упоминал в недавнем треде.
я несколько месяцев с IAR работал и могу это только подтвердить.
но и приоритеты у них другие: насколько можно более компактный код сгенерить, потому что производительность на далеком втором месте.
почему гцц на типичной коммерческой встроенщине и подсасывает: фокус у гцц-шников это (поддержка стандартов и) максимальная производительность на популярных процах. то что народ пишет на коммерческой встроенщине это просто ужас - и в каком-то смысле это просто чудо что (на арме) keil & iar это вообще в нечто юзабельное оптимизируют. я видел что народ в кернеле с гцц делает: насколько народ код вылизывает что бы гцц мог оптимальный код генерить. на коммерческих проектах фокус как правило style guide conformance, почему и пользуются кучами неоптимальных копипащиных повсюду конструкций. keil/iar реально в ж оптимизируют эту всю копипасту. даже сложно представить себе какие именно оптимизации они там делают, но навярняка как минимум с O(n^2) производительностью. на встроенщине, с 128К фирмваре это может быть и допустимо, но для десктопного 10-20МБ объектного кода проекта эти оптимизации будут смертельны (с точки зрения времени компиляции).
Не совсем. Если надо чтоб реалтаймовость, чтоб там кусок кода гарантированно отрабатывал за определенное время, да еще ж можно прерывания по таймеру делать, если не успело. К тому же там может быть очень наркоманская архитектура в этих контроллерах с переключением банков памяти. Это вам не в хаскеле монадки заворачивать
Вот cтатья http://www.wasm.ru/article/276 история одного байта
> история одного байта
Мне всегда было интересно, под какой чип писал ГГ этого рассказа...
Не думаю что оно там будет сильно круче. Я так прикинул, для некоторых оптимизаций вообще надо чуть ли не какой-то AI городить с системой символьных вычислений.
>фокус у гцц-шников это (поддержка стандартов и) максимальная производительность на популярных процах.
Следование стандартам часто несовместимо с максимальной производительностью. https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/simplify-rtx.c?view=markup&pathrev=232689#l2549 вот такая штука в GCC есть для какбы-символьных вычислений с плавучкой, которая срабатывает только если отрублено строгое следование стандарту вычислений с плавучкой. Оно там что-то через ассоциативность и коммутативность делает, например оно наверное сможет упростить a*b + a*c до a*(b+c)
По-моему это самый лучший вариант:
что оно инструкцию rev тут втулило в ответ на __builtin_bswap32()
IAR походу не знает про эти __builtin т.к. это гццшные экстеншены, и соотвественно не смогло заоптимизировать эти копирования памяти. Попробуй туда memcpy просто втулить, может оно что-то умное сделает
про какие-то он знает. дока дерьмовая - лень искать какие именно он поддерживает.
но memcpy() с константным размером (только что протестил) он в лоб не оптимизирует: на встроенном арме со статической памятью вызов функции относительно дешевый.
в добавок под IAR (если пользоватся IAR-specific функциями) твоей проблемы в какой то мере не существует: переменную можно объявить как __big_endian или __little_endian, и все остальное компилер сам сделает за тебя. или же встроенными асм макросами. (я этой магией сам не пользовался, и на простом быстром эксперименте ничего не вышло.)
стоить заметить что новые армы преимущественно strict-alignment и соптимизировать побайтовое чтение невозможно.
Или просто хуйню вернёт.
Вот например для | шланг смог тут узнать ror, а для + уже не http://goo.gl/Vrcq0S
AVR - стрикт алаймент?
каноничейский байт свап на GCC это:
читаешь число из памяти, и вот так его байт-свапишь.
PS читай линуховы и/или u-boot сырцы.
Он осьмибитный. Ему даже передать unsigned long int - уже боль.
http://goo.gl/moktyM
по генерируемому коду очевидно что компилер вообще обламался что-то соптимизировать: все операции в асме один ко одному к сишному сырцу. avr бэк-энд не предоставляет достаточное количество информации для оптимизиций или насильственно рубит оптимизации что бы эмуляция 32-бит чисел работала.
всего 4 инструкции.
http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_EOR.html