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, Анатолий Соколов польет это сверху цементом используя комит в транк эсвэна.