Re: internal compiler error at dwarf2out.c:8362

[Björn Haase <bjoern dot m dot haase at web dot de>]

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