этот тривиальный код компилируется для attiny2313 в 3940 байтов flash и 278 байт ОЗУ!!!! это как такое называется?! при этом если обе переменные v1 и v2 сделать uint32_t, то размер кода становится практически в 20 раз меньше: 200 байт flash !!! что там такое в libc понаделано, что получается такое разрастание кода?! ведь если руками написать функцию деления "в столбик" - получится код значительно меньше...

P.S. разумеется, оптимизация -Os

Ну дык никто не мешает посмотреть получившийся код...
Первое, что бросается в глаза - при 64 бит активно используется стек, в то время как при 32 бит обходится только регистрами. Плюс появляется множество ненужных пересылок. Вообще создалось впечатление, что тут "не ступала нога оптимизатора", несмотря на -Os.

я не вижу смысла смотреть в получающийся код - и так понятно, что там ужос... вопрос лишь в том, как это разработчики avr-libc такое допустили?! и каковы пути обхода проблемы?

А чего ей там ступать, если все переменные volatile...

ARV, Вы полагаете, что разработчики где-то здесь, чтобы Вам ответить?
Или это просто так, чтобы повозмущаться?

По аналогии все волатильные лонги тогда нужно перечитывать побайтно. Ведь в операции "v2 = v1/v2" и v1 и v2 считываются только 1 раз, а уж где их потом разместит компилятор - его личное дело, хоть в регистрах, хоть в стеке, но это месторасположение уже не будет волатильным. ИМХО - это недоработка оптимизации. Однозначно надо исправлять.


А в attiny2313 стока есть?

Сообщение отредактировал GetSmart - Sep 28 2009, 19:25

Там таки явно что-то не то.
Зачем-то большая таблица в ОЗУ

и сам код деления какой-то странный, толи на С писанный, толи совсем непонятно что.
Надо исходники качнуть, глянуть.

upd: Фигушки, это не avr-libc надо смотреть, а libgcc

upd: оййо....
В общем исходнике на libgcc2.c , которій в зависимости от #defin-ов по разному работает и пітается типа оптимизировать скорость проверяя на 0-не0 старшие части и подвызывая другие функции (в комментариях что-то про встроенній асм, но я их вообще не нашёл).
Таблица в .data от того же исходника, она не используется, но и не выбрасывается даже по -Wl,-gc-sections, так как библиотека собрана без -fdata-sections

Не оптимизации, а библиотеки поддержки. Её нужно "персонализировать" как-то. Может проще будет так, как с другими вещами сделано, многое в libm затолкано, которая из avr-libc - если её подключить, то размер кода уменьшается, так как берутся оптимизированные версии оттуда.

Там все сводится к функции __udivmodsi4 (деление 32бит/32бит) которая для AVR в файле gcc/config/avr/libgcc.S ,
и __udivmodsi4 написана вполне прилично,
а вот то что в libgcc2.c это конечно кошмар кошмар

слабость знания английского не позволяет мне запостить вопрос в ином месте...
здесь время от времени появляется Aesok, которого я причислил к лику разработчиков во всяком случае он не раз давал советы/ответы из самых глубин GCC - на него надеюсь и уповаю

кстати, -lm не помогает уменьшить размер кода.

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

учитывая то, что мне часто нужны быстрые умножения 16*16=32, перестал морочить голову, завел файл с асмовыми вставками. Теперь там будут и для 64 битных. Тут уже по две версии - регистровая и через указатели.

скомпилял этот пример

вот что получилось для -Os -mmcu=atmega64


для -Os -mmcu=attiny2313


я не заметил криминала по размеру, на счет правильности нада конечно проверить но.. я изредко интами 64 пользуюсь - вроде работало.

теперь нада лесть в __udivdi3

avr-libc как я понимаю вообще нипричем. операции над стандартными целыми типами - исключительно компиллер в libgcc реализует

тут какято поППа - 3312 инструкций... нада поглядеть исходнички!
посмотрел...

в исходничке libgcc2.c есть реализация на асме операции деления 32/32 , как мне кажется можно по образу и подобию изготовить 64/64

если найдется доброволец взятся за эту учебную задачку высеч сей гранитный монумент я поробую всунуть его под основание фундамента avr GCC, Анатолий Соколов польет это сверху цементом используя комит в транк эсвэна.

Гляну в выходные, ничего особого в задаче нет.
Можно даже сразу два варианта - глянуть на тему деления без восстановления остатка - немного больше по коду, но быстрее. И подкинуть монетку - что вписывать (на ребро - под условную компиляцию).

Кстати, и это может больше к Анатолию вопрос - если в структуре gcc есть места для делений 64/32, 32/16 и т.п. и их ещё нет, то можно одним махом дописать.

Поскольку оно (деление) хавает 24+1 регистров, может еще и в варианте работы с памятью через указатели ? А то ведь столько push/pop' ов некрасиво...

интерфейс(способ передачи) входных и выходных переменных определен (компиллером). нада делать с вычислением остатка. иначе компиллер несможет использовать. Вроде предварительно так видется.

К пониманию вопроса.
В GCC как требуют стандарты должны быть реализованы полный минимальный(орнтогональный) набор операций с СТАНДАРТНЫМИ типами языка который он реализует (сложение, вычитание, умножение, деление, сдвиг, ....... ). ВСЕ это реализовано в ВИДЕ КОДА!! То что я описал это "типо ядро". Этот подход гарантирует что компиллер сгенерит код для любой операции с стандартными типами - следовательно гарантировано сможет скомпилять исходник на языке высокого уровня. Далее все интересней. Начинается портирование! нижний слой GCC учитывает то на каком таргете он пасется. Тоесть используется реализация операций с СТАНДАРТНЫМИ типами написанная отделно для этого таргета (обычно это асм). Это позволяет не снижая общности верхненго слоя для любого таргета, учесть ресурсы конкретного процессора. Таким образом например как в нашем случае нет в порте реализации деления 64x64 компиллер берет свою "ппрограмную реализацию" со всеми вытекающими.... зато подход работает всегда!