Look at IEC/ISO 18037 documentation. It contains information about named address space and user defined named address space. It lays out a a standardized approach to dealing with multiple address spaces.

Walter Banks

"SourceForge.net" wrote:

Feature Requests item #1839339, was opened at 2007-11-27 11:24
Message generated for change (Comment added) made by patryks
You can respond by visiting:

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Laszlo BORTEL (bortel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for EEPROM storage class?

Initial Comment:
It would be really nice to have built in support for eeprom storage class and eeprom pointers, besides the existing ones. I would like to do things like this:

eeprom int i; //i is stored in eeprom, allocation managed by the compiler
eeprom int* eeptr; //eeptr is a pointer in eeprom address space
void main(void) {
  i=123; //compiler would automatically generate eeprom write for assignment
  i+=3; //compiler would automatically generate eeprom reads and writes for expression evaluation and assignment

Are there plans for such feature? I think it would be a great and useful feature and knock-out any competing compiler.


Comment By: Patryk (patryks)
Date: 2007-11-28 07:42

Logged In: YES
Originator: NO

"I propose that EEPROM should form a new address space that can be
allocated via new 'eeprom' or 'eedata' storage qualifier."
AVR GCC supports it this way.
Speaking about new address space - maybe it's also a solution to future
request #1714870 __no_init attribute for static variables:


Comment By: Laszlo BORTEL (bortel)
Date: 2007-11-27 18:46

Logged In: YES
Originator: YES

Yes, I strictly ment INTERNAL EEPROM only (external serial/parallel,
SPI/I2C are definitely excluded). Internal EEPROM is available on some 8051
variants like on Atmel AT89C51Rx2 for example. Probably it is not
considered part of the classic 8051 core architecture therefore there is no
standardised EEPROM access - which can cause big headache. But maybe at
least read access to EEPROM is (more or less) uniform via registers (like
EEDATA, EEADR, EECTRL) - I do not know that much detail about currently
available 8051 variants.
I propose that EEPROM should form a new address space that can be
allocated via new 'eeprom' or 'eedata' storage qualifier. It should not be
mixed with code memory. Actually it is not my idea - it is the way
Microchip's C30 handles it.
I see that my feature request is not a simple one at all but its
advantages are also significant in my opinion.


Comment By: Maarten Brock (maartenbrock)
Date: 2007-11-27 17:58

Logged In: YES
Originator: NO

If I understand you correctly you're only talking about internal eeprom.
And in which memory space should the allocation take place? Code memory?

The problem is not even that SDCC is retargetable, but that eeprom is not
part of the 8051 architecture. Where should we expect it to be? What
interface should be used to access it?


Comment By: Laszlo BORTEL (bortel)
Date: 2007-11-27 17:01

Logged In: YES
Originator: YES

While I fully understand all your concerns I still think a disciplined
programmer could make good use of even the limited EEPROM variable
allocation, exression evaluation and assignment functionality that I
proposed. I was not thinking about fancy things like CRC, transactions,
checkpointing and keeping of variable allocation between version (new
version would just completely reinitialise overwrite the old EEPROM
content) etc. Such additional functionality should be implemented according
to the needs of the given project. I just imagined an easy way in my
project to keep permanent track in EEPROM of counter statistics such as
usage count, usage time, number of button presses, low battery and other
relatively rare events. All of these produce low EEPROM wear. Of course it
is the responsibility of the programmer not to put a loop variable into
One more argument: Microchip's C30 compiler has already got similar
functionality via the 'eedata' storage qualifier. This functionality is
limited mainly to the EEPROM allocation, reads are done via special
microcontroller features like PSV and TBLRD, writes are done by
subroutines, but it is a good start to make EEPROM usage easier and more
comfortable. I also understand that Microchip's compiler is not
retargettable so they had an easier task.
I expect that sooner or later EEPROM will be just another address space
for the compiler and target specific read/write macros will hide the dirty
complexity from the programmer.
As first step I would very welcome the EEPROM variable allocation
possibility combined with read only EEPROM access. The read-only limitation
would negate some of your concerns and also ease the initial depth of the
So I would like to ask you to keep this feature request open for a while
and wait for other comments. And maybe implement it when the time comes in
the (hopefully not too far) future if it gets support from others.


Comment By: Maarten Brock (maartenbrock)
Date: 2007-11-27 13:52

Logged In: YES
Originator: NO

I agree with Frieder. To hide the complexity of writing eeprom in a simple
assignment will probably only lead to sloppy programming and premature
device failure.

Furthermore you would still need to implement the actual read and write
algorithm in some special functions, because there is no universal standard
way. Some mcu's have internal eeprom, others have it externally with SPI,
IIC or parallel interface. And the actual protocol data to perform a read
or write action will probably differ too.

So if you have to write these functions anyway, you might as well use them
in your code making eeprom access explicit.


Comment By: Frieder Ferlemann (frief)
Date: 2007-11-27 12:38

Logged In: YES
Originator: NO

> Are there plans for such feature?


While it might look convenient on first sight
there might be a can of worms standing nearby:

- int or long (or data structures >8bit) only being
  partially written due to unexpected reset
- no CRC functionality (or only with severe overhead)
- possible premature eeprom wear-out. 1 million writes can
  easily be reached within a few hours. I would not
  trust the hardware any more!
- encourages unstructured/difficult to maintain code
- no option for eeprom block reads/writes
- difficult to implement on flash (instead of EEPROM)
- no nice point to set brake-points at
- difficult to maintain the same addresses in eeprom
  between different source revisions (for eeprom it
  would make sense that the compiler initializes
  variables from eeprom, ...)

... so I'd rather not have this feature:^)


You can respond by visiting:

SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
sdcc-devel mailing list