This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

different address spaces (was Re: internal compiler error at dwarf2out.c:8362)

James E Wilson wrote:
>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.

Placing variables in a specfic section is only a part of the problem.
With eg. the AVR progmem attribute, the data is only placed in the Flash memory.
If you want to access it, you need to pass the address to function, which
does the read or write operation (The last version, I used was 3.x based, so
this may have change).

I want to accomplish with the eeprom attribute, a transparent access to such memory
regions, where for variables, whose type has this attribute, or pointers, which point to
a type, which has this attribute, different RTL is generated, which calls these functions

This approach is not perfect (assign a pointer having not this attribute to a
pointer having this attribute using a type cast).

For placing variables, I use the section attribute, so I can support multiple
eeprom regions. This is a specific requirement for my project, as some eeprom data
must be put in the region 0x100-0x1ff, whereas other data can be but at any eeprom

For the AVR port, two such attributes would be needed (eeprom and progmem).

My prototype for the m68hc05 does currently the following (based on GCC 4.1):
* A predicate was created, which checks for MEM expression, if the type, either
in the memory attributes or in the register attributes for (mem:XX (reg:XX ..)),  
contains the eeprom attribute
*The move expander check, if a operand matches the eeprom predicate. If this is true,
a different RTL is generated (in my case a call the the library function).
*All other insns reject such an operand, so I had not to change them
*In set_mem_attributes_minus_bitpos, I always store the expression.
 This has caused for my port no regression. As now a register/memory attribute
 may contain an expression, that is not a DECL, I also had to comment out
 one assertion and add that case to the debug print function:

Index: emit-rtl.c
RCS file: /cvs/gcc/gcc/gcc/emit-rtl.c,v
retrieving revision 1.436
diff -u -r1.436 emit-rtl.c
--- emit-rtl.c  25 Mar 2005 02:23:57 -0000      1.436
+++ emit-rtl.c  13 Apr 2005 10:41:34 -0000
@@ -1420,7 +1420,7 @@

   /* ARRAY_REFs, ARRAY_RANGE_REFs and BIT_FIELD_REFs should already
              have been resolved here.  */
-  gcc_assert (DECL_P (expr1));
+  /* gcc_assert (DECL_P (expr1)); */

   /* Decls with different pointers can't be equal.  */
   return 0;
@@ -1449,6 +1449,9 @@
   if (t == NULL_TREE)

+  if (expr == NULL_TREE)
+    expr = t;
   type = TYPE_P (t) ? t : TREE_TYPE (t);
   if (type == error_mark_node)
Index: print-rtl.c
RCS file: /cvs/gcc/gcc/gcc/print-rtl.c,v
retrieving revision 1.121
diff -u -r1.121 print-rtl.c
--- print-rtl.c 3 Apr 2005 10:27:44 -0000       1.121
+++ print-rtl.c 13 Apr 2005 10:41:34 -0000
@@ -116,6 +116,10 @@
   else if (TREE_CODE (expr) == RESULT_DECL)
     fputs (" <result>", outfile);
+  else if (!DECL_P(expr))
+    {
+      print_node_brief(outfile,"",expr,0);
+    }
       fputc (' ', outfile);

For my test cases, this is working.

mfg Martin Kögler
PS: Please CC me on replies

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]