[avr-gcc-list] dev and mod may not be optimized
I appologize if I'm misunderstanding something about the code that is being produced, but while auditing some code to try to make some code smaller I noticed that __udivmodqi4 is being called twice to generate code for: unsigned char a, b, c; c = some_input_function(); LABEL: a = c/10; b = c%10; ... * LABEL: mov r24,r18 ldi r22,lo8(10) call __udivmodqi4 mov r19,r24 .LM436: mov r24,r18 call __udivmodqi4 If I'm understanding __udivmodqi4 it produces the results of both of these with one call. My compile command is: avr-gcc -S -mmcu=atmega128 -Os -fno-delete-null-pointer-checks -Wall -Wstrict-prototypes -Wa,-ahlms=gekv2c.lst -DETHERNUT2 -D__HARVARD_ARCH__ -gdwarf-2 -IC:/ethernut-4.4.0/nut/include file.c -o file.s And as the -I tells, this is on Windows. The GCC version is 3.4.6 . I do not subscribe to this list, so please CC me on any replies. Nathan Moore ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
AW: [avr-gcc-list] dev and mod may not be optimized
The source of this problem is a deeply buried internal issue of the RTL handling within the compiler. Description of the internal problem: The expand pass generates strange RTL sequences refering to hard registers for the div and mod operations and uses specific insn RTL for calling the respective functions. This way the compiler does not need to save and restore all of the call-clobbered registers but only those that the functions alter. Unfortunately div and mod could not be optimized this way because the combine and CSE passes do not operate on hard registers :-(. Unfortunately there is no easy solution of this issue :-(. Yours, Bjoern. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Nathan Moore Gesendet: Montag, 10. Dezember 2007 23:02 An: avr-gcc-list@nongnu.org Betreff: [avr-gcc-list] dev and mod may not be optimized I appologize if I'm misunderstanding something about the code that is being produced, but while auditing some code to try to make some code smaller I noticed that __udivmodqi4 is being called twice to generate code for: unsigned char a, b, c; c = some_input_function(); LABEL: a = c/10; b = c%10; ... * LABEL: mov r24,r18 ldi r22,lo8(10) call __udivmodqi4 mov r19,r24 .LM436: mov r24,r18 call __udivmodqi4 If I'm understanding __udivmodqi4 it produces the results of both of these with one call. My compile command is: avr-gcc -S -mmcu=atmega128 -Os -fno-delete-null-pointer-checks -Wall -Wstrict-prototypes -Wa,-ahlms=gekv2c.lst -DETHERNUT2 -D__HARVARD_ARCH__ -gdwarf-2 -IC:/ethernut-4.4.0/nut/include file.c -o file.s And as the -I tells, this is on Windows. The GCC version is 3.4.6 . I do not subscribe to this list, so please CC me on any replies. Nathan Moore ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] dev and mod may not be optimized
Just a correction : div() take 2 parameters : div_t t; t=div(c, 10); a=t.quot; b=t.rem; Eric. - Original Message - From: Albert Andras To: avr-gcc-list@nongnu.org Sent: Tuesday, December 11, 2007 4:16 PM Subject: Re: [avr-gcc-list] dev and mod may not be optimized - Original Message - From: Nathan Moore [EMAIL PROTECTED] unsigned char a, b, c; c = some_input_function(); LABEL: a = c/10; b = c%10; ... * LABEL: mov r24,r18 ldi r22,lo8(10) call __udivmodqi4 mov r19,r24 .LM436: mov r24,r18 call __udivmodqi4 If I'm understanding __udivmodqi4 it produces the results of both of these with one call. Acording to: http://www.nongnu.org/avr-libc/user-manual/structdiv__t.html you could do: div_t t; t=div(c/10); a=t.quot; b=t.rem; Andras -- ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] dev and mod may not be optimized
On Wednesday 12 December 2007 01:16, Albert Andras wrote:
- Original Message -
From: Nathan Moore [EMAIL PROTECTED]
unsigned char a, b, c;
c = some_input_function();
LABEL:
a = c/10;
b = c%10;
...
*
LABEL:
mov r24,r18
ldi r22,lo8(10)
call __udivmodqi4
mov r19,r24
.LM436:
mov r24,r18
call __udivmodqi4
If I'm understanding __udivmodqi4 it produces the results of both of
these with one call.
Acording to:
http://www.nongnu.org/avr-libc/user-manual/structdiv__t.html
you could do:
div_t t;
t=div(c/10);
a=t.quot;
b=t.rem;
Alas, the usage of div() function is more space and more time
expansive. The reason is that div() uses an another function:
__divmodhi4(), i.e. 16-bits.
Compare two programs:
prog1: 150 bytes, 238 clocks
prog2: 212 bytes, 316 clocks
Regards,
Dmitry.
-
volatile unsigned char a, b, v = 123;
int main ()
{
unsigned char c = v;
a = c / 10;
b = c % 10;
return 0;
}
-
#include stdlib.h
volatile unsigned char a, b, v = 123;
int main ()
{
div_t d;
d = div (v, 10);
a = d.quot;
b = d.rem;
return 0;
}
--
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] dev and mod may not be optimized
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Dmitry K.
Sent: Tuesday, December 11, 2007 3:44 PM
To: avr-gcc-list@nongnu.org
Cc: Nathan Moore
Subject: Re: [avr-gcc-list] dev and mod may not be optimized
Alas, the usage of div() function is more space and more time
expansive. The reason is that div() uses an another function:
__divmodhi4(), i.e. 16-bits.
Compare two programs:
prog1: 150 bytes, 238 clocks
prog2: 212 bytes, 316 clocks
Regards,
Dmitry.
-
volatile unsigned char a, b, v = 123;
int main ()
{
unsigned char c = v;
a = c / 10;
b = c % 10;
return 0;
}
-
#include stdlib.h
volatile unsigned char a, b, v = 123;
int main ()
{
div_t d;
d = div (v, 10);
a = d.quot;
b = d.rem;
return 0;
}
--
Should we implement 2 (or 3) div functions then in avr-libc? 8, 16, and
32 bit?
Eric
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] dev and mod may not be optimized
--- Dmitry K. [EMAIL PROTECTED] wrote: Alas, the usage of div() function is more space and more time expansive. The reason is that div() uses an another function: __divmodhi4(), i.e. 16-bits. Compare two programs: prog1: 150 bytes, 238 clocks prog2: 212 bytes, 316 clocks Well if size speed are getting you down, try this: http://pastie.textmate.org/127218 The calculation takes 22 bytes and executes in 40 clocks. As an assembly-language programmer, having that extra MOV in the beginning annoys me, but hey, I try not to break the asm rules. Regardless, you'd be hard-pressed to get it much smaller or faster. HTH, Gre7g __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] dev and mod may not be optimized
On Wednesday 12 December 2007 09:29, Weddington, Eric wrote: Should we implement 2 (or 3) div functions then in avr-libc? 8, 16, and 32 bit? Possible, yes. Today the libgcc labrary contains 6 division functions (8, 16, 32 bits, signed and unsigned), but Avr-libc includes only 2 links (div, ldiv). Dmitry. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] dev and mod may not be optimized
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] org] On Behalf Of Dmitry K. Sent: Tuesday, December 11, 2007 5:37 PM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] dev and mod may not be optimized On Wednesday 12 December 2007 09:29, Weddington, Eric wrote: Should we implement 2 (or 3) div functions then in avr-libc? 8, 16, and 32 bit? Possible, yes. Today the libgcc labrary contains 6 division functions (8, 16, 32 bits, signed and unsigned), but Avr-libc includes only 2 links (div, ldiv). Then, yes, it would be good if we could provide interfaces for all combinations. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
