RE: [avr-gcc-list] [discussion] lpm support in avr-gcc

[Ralph Stickley]

It seems this would require additional overhead.  If the 'C' functions are
oblivous to the data space, then the processor, at run-time, must make the
distinction.

I.E. If function "puts(char *s)" gets a string that may be located in Code
or Flash or EEPROM or RAM data space, then that function must determine how
to read the data from each data space....

puts...
if ( s is in CODE ) ...
if ( s is in FLASH) ...
if ( s is in EEPROM)...
if ( s is in RAM ) ...

The overhead is thus:
1.  Additional byte with every pointer - to identify where the data is from
2.  Code executing at runtime to determine where the data is, and how to
read it.

Doesn't sound good to me.  If you attempt to Hide the fact that the data is
spread amounst various data spaces, then the decision (and overhead) is in
the code.  I saw this done with a 'C' compiler for the 8051 back in '88
(IIRC - Franklin or Archimedes?)....it didn't work out very well, it
generated huge code and was slow, but it did support "bank" switching :)

Just another $0.02 worth...

Ralph Stickley
Datalux, Corp.


> ----------
> From:         Bruce D. Lightner[SMTP:address@hidden
> Sent:         Tuesday, August 27, 2002 1:36 PM
> To:   Joerg Wunsch
> Cc:   address@hidden
> Subject:      Re: [avr-gcc-list] [discussion] lpm support in avr-gcc
> 
> Joerg Wunsch wrote:
> > 
> > Harald Kipp <address@hidden> wrote:
> > 
> > > I don't know much about the compiler's internal structure,
> > > but I guess, that both suggestions
> > >
> > >    1. Automatic recognition of PMEM pointers in assingments
> > >    2. Using P modifier for string literals
> > >
> > > would require substantial changes, while the current way,
> > > using the special attribute progmem, changes the runtime
> > > lib only.
> > 
> > Using __attribute__ is IMHO fine.  But it would be ideal if
> > this could automatically make gcc emit lpm instructions
> > when accessing these variables.
> > 
> > --
> > J"org Wunsch                                           Unix support
> engineer
> > address@hidden
> http://www.interface-systems.de/~j/
> > avr-gcc-list at http://avr1.org
> 
> If we are taking a vote, IMNSHO I agree!  It is a small step with a
> positive
> result.
> 
> I suspect that tighter AVR code will result because of this, based on my
> experience using LPM macro(s).  The compiler can automatically "do the
> right
> thing" with respect to the type of the object stored in program memory.  
> 
> I get tired of either having multiple "LPM macros" (i.e., for
> char/uchar/short/ushort/long/ulong, etc.) or having to remember to cast
> the
> result of the LPM() macro and/or explicitly assembling LPM() bytes into
> bigger objects (e.g., ints).  If you are not careful, you either get
> unneeded instructions (e.g., because of char vs. uchar -> int), or the
> wrong
> answer!
> 
> So...how do we make it happen?  (I've got free beer if you've got the
> expertise! :-)
> 
> Best regards,
> 
> Bruce
> 
> -- 
>  Bruce D. Lightner
>  Lightner Engineering
>  La Jolla, California
>  Email: address@hidden
>  URL: http://www.lightner.net/lightner/bruce/
> avr-gcc-list at http://avr1.org
> 
avr-gcc-list at http://avr1.org