- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
.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
j123123 04.02.2016 15:16 # 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
https://electronics.stackexchange.com/questions/153481/avr-gcc-how-do-i-improve-code-optimization
TarasB 04.02.2016 15:49 # +4
(a>>24)|((a&0xff0000)>>8)|((a&ff00)<<8)| (a<<24)
j123123 04.02.2016 15:56 # +3
Лучше всего оптимизируется через вот эту вот конструкцию shit_union tmp2 = (shit_union){{tmp.bytes[3],tmp.bytes[2],tmp.bytes[1],tmp.bytes[0]}};
Dummy00001 05.02.2016 12:39 # +1
судя по генереной ахинее в ГК, avr бэк-энд на чем-то спотыкается, и пытается в промежуточные вычисления делать аккуратно. что здесь в принципе не нужно.
govnokod3r 05.02.2016 00:43 # +1
j123123 05.02.2016 01:39 # +1
Odin 03.11.2018 17:45 # 0
j123123 05.02.2016 01:47 # +1
и компилятор посвежее взять. Все кто говорят про мегакрутость современных компиляторов и что вот ассмблер нинужно потому что компилятр круче заоптимизирует, должны заткнуться и пойти пилить эти самые компиляторы, чтобы они перестали генерировать говнокод в ответ на ДОСТАТОЧНО ИЗВЕСТУЮ И ШИРОКО ИСПОЛЬЗУЕМУЮ КОНСТРУКЦИЮ. Всякие там htons htonl именно так через сдвиги и написаны, но компилятор делает из этого кода какое-то дичайшее говно на ассемблере
Dummy00001 05.02.2016 12:24 # +1
сам виноват что говно-непроцессором пользуешься. гцц сам по себе и не виноват то - ругайся на авторов AVR которые поддержку оного в гцц и добавляли.
с одной стороны. с другой стороны компилером пользоватся надо уметь. тот огород типов и конверсий который городишь в оригинальном коде указывает что ты просто не дорос еще до почётного звания байтоёба.
PS авр нету. но на intel & arm, байтсвап как описан ниже генерирует 2-3 инструкции (weak alignment, и может быть дюжину при побайтовом чтении из памяти). твое говно генерит кучу потому что ты идиот ренундантно типы конвертишь.
Dummy00001 05.02.2016 12:31 # 0
bormand 05.02.2016 12:47 # +3
Там int 16-битный.
P.S. Пишут, что в 2006 году avr-gcc вообще 47 команд генерил в ответ на bswap32... Так что прогресс :)
P.P.S. Вот и отличный пруф про хуёвые конпеляторы в embedded, о которых я упоминал в недавнем треде.
Dummy00001 05.02.2016 13:12 # 0
я несколько месяцев с IAR работал и могу это только подтвердить.
но и приоритеты у них другие: насколько можно более компактный код сгенерить, потому что производительность на далеком втором месте.
почему гцц на типичной коммерческой встроенщине и подсасывает: фокус у гцц-шников это (поддержка стандартов и) максимальная производительность на популярных процах. то что народ пишет на коммерческой встроенщине это просто ужас - и в каком-то смысле это просто чудо что (на арме) keil & iar это вообще в нечто юзабельное оптимизируют. я видел что народ в кернеле с гцц делает: насколько народ код вылизывает что бы гцц мог оптимальный код генерить. на коммерческих проектах фокус как правило style guide conformance, почему и пользуются кучами неоптимальных копипащиных повсюду конструкций. keil/iar реально в ж оптимизируют эту всю копипасту. даже сложно представить себе какие именно оптимизации они там делают, но навярняка как минимум с O(n^2) производительностью. на встроенщине, с 128К фирмваре это может быть и допустимо, но для десктопного 10-20МБ объектного кода проекта эти оптимизации будут смертельны (с точки зрения времени компиляции).
j123123 06.02.2016 14:38 # 0
Не совсем. Если надо чтоб реалтаймовость, чтоб там кусок кода гарантированно отрабатывал за определенное время, да еще ж можно прерывания по таймеру делать, если не успело. К тому же там может быть очень наркоманская архитектура в этих контроллерах с переключением банков памяти. Это вам не в хаскеле монадки заворачивать
Вот cтатья http://www.wasm.ru/article/276 история одного байта
bormand 06.02.2016 16:52 # 0
> история одного байта
Мне всегда было интересно, под какой чип писал ГГ этого рассказа...
j123123 06.02.2016 14:46 # 0
Не думаю что оно там будет сильно круче. Я так прикинул, для некоторых оптимизаций вообще надо чуть ли не какой-то 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)
Dummy00001 08.02.2016 18:12 # 0
Dummy00001 08.02.2016 18:16 # 0
j123123 08.02.2016 18:42 # 0
По-моему это самый лучший вариант:
что оно инструкцию rev тут втулило в ответ на __builtin_bswap32()
IAR походу не знает про эти __builtin т.к. это гццшные экстеншены, и соотвественно не смогло заоптимизировать эти копирования памяти. Попробуй туда memcpy просто втулить, может оно что-то умное сделает
Dummy00001 08.02.2016 19:08 # 0
про какие-то он знает. дока дерьмовая - лень искать какие именно он поддерживает.
но memcpy() с константным размером (только что протестил) он в лоб не оптимизирует: на встроенном арме со статической памятью вызов функции относительно дешевый.
в добавок под IAR (если пользоватся IAR-specific функциями) твоей проблемы в какой то мере не существует: переменную можно объявить как __big_endian или __little_endian, и все остальное компилер сам сделает за тебя. или же встроенными асм макросами. (я этой магией сам не пользовался, и на простом быстром эксперименте ничего не вышло.)
Dummy00001 08.02.2016 18:13 # 0
стоить заметить что новые армы преимущественно strict-alignment и соптимизировать побайтовое чтение невозможно.
guest8 03.11.2018 17:51 # −999
bormand 03.11.2018 17:56 # −1
Или просто хуйню вернёт.
inkanus_gray 03.11.2018 19:16 # −1
bormand 03.11.2018 19:24 # 0
inkanus_gray 03.11.2018 19:33 # 0
inkanus_gray 03.11.2018 19:46 # 0
guest8 04.11.2018 03:01 # −999
govnokod3r 05.02.2016 01:46 # 0
j123123 05.02.2016 01:59 # 0
Вот например для | шланг смог тут узнать ror, а для + уже не http://goo.gl/Vrcq0S
Dummy00001 05.02.2016 12:14 # 0
AVR - стрикт алаймент?
каноничейский байт свап на GCC это:
читаешь число из памяти, и вот так его байт-свапишь.
PS читай линуховы и/или u-boot сырцы.
bormand 05.02.2016 12:35 # 0
Он осьмибитный. Ему даже передать unsigned long int - уже боль.
Dummy00001 05.02.2016 12:40 # +2
j123123 05.02.2016 13:40 # 0
http://goo.gl/moktyM
Dummy00001 05.02.2016 14:12 # −1
по генерируемому коду очевидно что компилер вообще обламался что-то соптимизировать: все операции в асме один ко одному к сишному сырцу. avr бэк-энд не предоставляет достаточное количество информации для оптимизиций или насильственно рубит оптимизации что бы эмуляция 32-бит чисел работала.
Dummy00001 05.02.2016 14:40 # 0
всего 4 инструкции.
j123123 05.02.2016 14:57 # +1
bormand 05.02.2016 15:04 # 0
j123123 05.02.2016 15:52 # +2
http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_EOR.html