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

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

Re: [avr-gcc-list] Structs in program memory.


From: Graham Davies
Subject: Re: [avr-gcc-list] Structs in program memory.
Date: Tue, 27 Apr 2004 11:03:09 -0400

----- Original Message ----- 
From: "Christian Ludlam" <address@hidden>
To: <address@hidden>
Sent: Monday, April 26, 2004 7:56 PM
Subject: Re: [avr-gcc-list] Structs in program memory.


> ... if the compiler is aware of the different address spaces it can change
the
> generated code to access it correctly. Then it would just be a case of
changing
> the declaration of a variable - the C code to read it would be the same
...

New member and first post here.  I hope it's helpful or at least
interesting.

ZiLOG's toolset (ZDS II) for the Z8 Encore!, which is also modified Harvard
architecture, attempts to address the problem under discussion with the
storage qualifier "rom".  You use this where you might use "const".  In
theory, what you're declaring then gets put in flash memory (rather than
RAM) and code is generated to access it there.  This would be fairly
seamless if it worked properly.  Unfortunately, the implementation is
screwed up and you run into compiler defects when you try to use this.  The
tools also have a setting to make "const" have the same effect as "rom",
which means ZiLOG had to take all the consts out of the ANSI library
functions.  This means that, for example, format strings in printf() have to
be in RAM, which kind of defeats the whole purpose.  Anyway, the point is it
appears to be possible to put constant data in program memory in a modified
Harvard machine and make it mostly seamless.  I say "mostly" because C is
rather lenient when it comes to casting pointers and of course when you cast
a pointer to program memory into a pointer to data memory or vice versa it's
not going to work.  This is unavoidable with modified Harvard machines.
Coming from the Z8 Encore! to the AVR, I was hoping to see something better
than ZDS II and finding that things are actually in worse shape with GCC is
a bit of a setback.

Graham.



reply via email to

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