Am Dienstag, 19. April 2005 00:30 schrieb James E Wilson: > Björn Haase wrote: > > In case that one should not use machine specific atttributes, *is* there > > a standard way for GCC how to implement different address spaces? > > Use section attributes to force functions/variables into different > sections, and then use linker scripts to place different sections into > different address spaces. You can define machine dependent attributes > as short-hand for a section attribute, and presumably the eeprom > attribute is an example of that. > > The only thing wrong with the eeprom attribute is that it is trying to > create its own types. It is not necessary to create new types in order > to get variables placed into special sections. There is nothing wrong > with the concept of having an eeprom attribute. Hi,
I am aware of the possibility to use section attributes for giving the linker information on where to place which kind of object. The difficulty is, that for a couple of targets like AVR (and I think that this EEPROM issue for the HC05 it is very much the same problem) you will be required to use a completely different set of assembler instructions for accessing different regions of memory. So it is not sufficient to simply give the linker the information where to place which object. To give you an example: In case that you are trying to access read-only program memory on avr, you could only access it by use of a single pointer register (Z reg.) and the only addressing modes that are available are register direct and register direct with pre decrement and post increment. In case that you are accessing r/w data memory, you could make use of 3 different pointer registers (X,Y,Z) and there are also instruction with immediate memory addresses and register direct addressing with offset as well as a couple of instructions that could directly reference memory (bit tests, e.g.) . The problem therefore is that the compiler itself would need to know which type of memory reference he presently is working on in order to know which kind of instruction set will be functional. So, I think what would be needed is something that is reflected in the type system. IIUC, this is the background of the change in the type system that the previous message in the thread is about. What would be best is some kind of "sticky flag" that is carried around with every tree node or RTL expression that stems from a memory reference that once has been marked by a particular attribute. Yours, Björn
