avr-libc и uint64_t арифметика, или баг, или я чего-то не понимаю... Опции

[ARV]

Код

volatile uint64_t v1;
volatile uint32_t v2;

int main(void)
{
    v2 = v1/v2;
    PORTD = 12;
    while(1);
}

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

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

[_Pasha]

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

[klen]

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

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

.file "int64.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global main
.type main, @function
main:
push r2
push r3
push r4
push r5
push r6
push r7
push r8
push r9
push r10
push r11
push r12
push r13
push r14
push r15
push r16
push r17
/* prologue: function */
/* frame size = 0 */
lds r18,v1
lds r19,v1+1
lds r20,v1+2
lds r21,v1+3
lds r22,v1+4
lds r23,v1+5
lds r24,v1+6
lds r25,v1+7
lds r2,v2
lds r3,(v2)+1
lds r4,(v2)+2
lds r5,(v2)+3
movw r10,r2
movw r12,r4
clr r14
clr r15
ldi r16,lo8(0)
ldi r17,lo8(0)
call __udivdi3
movw r24,r18
movw r26,r20
sts v2,r24
sts (v2)+1,r25
sts (v2)+2,r26
sts (v2)+3,r27
ldi r24,lo8(12)
out 50-0x20,r24
.L2:
rjmp .L2
.size main, .-main
.comm v1,8,1
.comm v2,4,1

для -Os -mmcu=attiny2313

.file "int64.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global main
.type main, @function
main:
push r2
push r3
push r4
push r5
push r6
push r7
push r8
push r9
push r10
push r11
push r12
push r13
push r14
push r15
push r16
push r17
/* prologue: function */
/* frame size = 0 */
lds r18,v1
lds r19,v1+1
lds r20,v1+2
lds r21,v1+3
lds r22,v1+4
lds r23,v1+5
lds r24,v1+6
lds r25,v1+7
lds r2,v2
lds r3,(v2)+1
lds r4,(v2)+2
lds r5,(v2)+3
movw r10,r2
movw r12,r4
clr r14
clr r15
ldi r16,lo8(0)
ldi r17,lo8(0)
rcall __udivdi3
movw r24,r18
movw r26,r20
sts v2,r24
sts (v2)+1,r25
sts (v2)+2,r26
sts (v2)+3,r27
ldi r24,lo8(12)
out 50-0x20,r24
.L2:
rjmp .L2
.size main, .-main
.comm v1,8,1
.comm v2,4,1

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

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

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

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

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

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

[ReAl]

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

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

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

[_Pasha]

Можно даже сразу два варианта

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

[klen]

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

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

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

[Petka]

.... зато подход работает всегда!

т.е. такой большой код не потому, что так написали для AVR в GCC, а потому что соответствующий код для GCC не написан, и была взята реализация написанная на Си?