avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: Re: [avr-gcc-list] Urgent Queries about AVR-GCC


From: eric
Subject: Fwd: Re: [avr-gcc-list] Urgent Queries about AVR-GCC
Date: Tue, 3 Jun 2003 20:55:12 GMT

[Sorry, I meant for this to go on the list but forgot to 
CC - Eric]

Forwarded Message:
> To: address@hidden
> From: Neil Johnson <address@hidden>
> Subject: Re: [avr-gcc-list] Urgent Queries about AVR-GCC
> Date: Tue, 3 Jun 2003 21:41:13 +0100 (BST)
> -----
> Hi,
> 
> > Reasonable argument. If that's the case, then perhaps
> > typecasting all the constants for the cases as unsigned
> > char (or equivalently uint8_t) would cause the compiler 
to
> > emit the desired code (theory untested).
> 
> Hmmm, tried the following code in the current version of 
avr-gcc:
> 
> int foo(char select)
> {
>       int retval = 0;
> 
>       switch(select)
>       {
>               case ((char)1): retval = 1; break;
>               case ((char)2): retval = 4; break;
>               case ((char)3): retval = 9; break;
>               case ((char)4): retval = 16;break;
>       }
> 
>       return retval;
> }
> 
> Produces code that looks like:
> 
>  243 006c 282F                mov r18,r24
>  244 006e 3327                clr r19
>  245 0070 2230                cpi r18,2
>  246 0072 3105                cpc r19,__zero_reg__
>  247 0074 81F0                breq .L14
>  248 0076 2330                cpi r18,3
>  249 0078 3105                cpc r19,__zero_reg__
>  250 007a 24F4                brge .L19
>  251 007c 2130                cpi r18,1
>  252 007e 3105                cpc r19,__zero_reg__
>  253 0080 41F0                breq .L13
>  254 0082 11C0                rjmp .L12
>  255                  .L19:
>  256 0084 2330                cpi r18,3
>  257 0086 3105                cpc r19,__zero_reg__
>  258 0088 49F0                breq .L15
>  259 008a 2430                cpi r18,4
>  260 008c 3105                cpc r19,__zero_reg__
>  261 008e 49F0                breq .L16
>  262 0090 0AC0                rjmp .L12
> 
> Which looks suspiciously like it is still promoting the 
case expressions
> and the controlling expression into ints.  Also, it isn't 
using a jump
> table, which would have saved quite a few machine 
instructions.  Does GCC
> not do jump tables, or just not in gcc-avr?
> 
> > > What would be nice to do is for the compiler to do 
range analysis on
> > > the set of case values, and determine that they fit 
into the range of
> > > char, and thus avoid promoting the controlling 
expression from a char
> > > to an int.
> >
> > One could make that suggestion to the GCC list...
> 
> *sigh*  Sadly got enough to keep me busy writing up my 
thesis as it is!!
> Maybe after September when I'll have more time.
> 
> Cheers,
> Neil
> 
> --
> Neil Johnson :: Computer Laboratory :: University of 
Cambridge ::
> http://www.njohnson.co.uk          
http://www.cl.cam.ac.uk/~nej22
> ----  IEE Cambridge Branch: http://www.iee-
cambridge.org.uk  ----
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]