different address spaces

I have redone the implementation of the eeprom attribute in my prototype. It is now a cleaner solution, but requires larger changes in the core, but the changes in the core should not affect any backend/frontend, if it does not uses them (except a missing case in tree_copy_mem_area, which will caus

Re: different address spaces

James E Wilson <[EMAIL PROTECTED]> writes: >> unnecessary, and error prone (as evidenced by string literal memory >> references not being properly identified as READONLY, although their >> equivalent array representations are treated properly for example?) > > If true, that sounds like a bug

Re: different address spaces

> From: Zack Weinberg <[EMAIL PROTECTED]> >> James E Wilson <[EMAIL PROTECTED]> writes: >> >>> unnecessary, and error prone (as evidenced by string literal memory >>> references not being properly identified as READONLY, although their >>> equivalent array representations are treated properly

Re: different address spaces

> From: Paul Schlie <[EMAIL PROTECTED]> > ... > (with respect to: -Wwrite-strings, I would have thought that the option, > although presently depreciated and disabled by default, would only have > enabled writes to string literal references be specified at the language > front-end level, but not

Re: different address spaces

On Apr 27, 2005, at 1:04 PM, Martin Koegler wrote: @@ -2070,6 +2078,7 @@ result = build3 (CALL_EXPR, TREE_TYPE (fntype), function, coerced_params, NULL_TREE); + EXPR_MEM_AREA (result) = DEFAULT_MEM_AREA; TREE_SIDE_EFFECTS (result) = 1; In the future, please use -p to diff.

Re: different address spaces

> Martin Koegler wrote: > I have redone the implementation of the eeprom attribute in my prototype. > It is now a cleaner solution, but requires larger changes in the core, > but the changes in the core should not affect any backend/frontend, if > it does not uses them (except a missing case in tre

Re: different address spaces

On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote: > > Martin Koegler wrote: > > I have redone the implementation of the eeprom attribute in my prototype. > > It is now a cleaner solution, but requires larger changes in the core, > > but the changes in the core should not affect any backe

Re: different address spaces

> From: Martin Koegler <[EMAIL PROTECTED]> >> On Thu, Apr 28, 2005 at 12:37:48PM -0400, Paul Schlie wrote: >>> Martin Koegler wrote: >>> I have redone the implementation of the eeprom attribute in my prototype. >>> It is now a cleaner solution, but requires larger changes in the core, >>> but the c

Re: different address spaces

ference would work. Can an optimizer theoretically not change fundamentally the structure of a memory reference, so that the attributes will not be valid any more? For adress spaces, the biggest problem can be, if access operations to different address spaces are joined: eg: if(???) { R

Re: different address spaces

;, the fundamental attributes associated with the declared object must be maintained. Thereby in effect all effective address optimizations logically occur within the attributed scope of the original memory references context, i.e.: (mem (some-arbitrary-effective-address-expression)) ->

Proposal: GCC core changes for different address spaces

After some discussion, how to create transparent access to different memory transparently, I propose the following solution: We change the GCC core to store the type of each memory expression in the MEM rtx. Backends can use this type information to create a diffent RTL or output a different assem

Proposal: GCC core changes for different address spaces

> Martin Koegler wrote: > ... > Before I start experimenting with this, I want other people opinions, > how acceptable this proposal will before GCC mainline or if it can be > improved. - sound's good, and a natural generalization of current mem ref attributes. (However ideally, function paramete

Re: Proposal: GCC core changes for different address spaces

On Sat, Apr 23, 2005 at 07:18:22PM +0200, Martin Koegler wrote: > For implementing the type attributes, I propose: > Add the field "tree type;" to "struct mem_attrs". This field holds the type, > if present, > or 0, if no type information is available. > > To access it, I propose: > #define MEM_T

Re: Proposal: GCC core changes for different address spaces

> From: Paul Schlie <[EMAIL PROTECTED]> >> Martin Koegler wrote: >> ... >> Before I start experimenting with this, I want other people opinions, >> how acceptable this proposal will before GCC mainline or if it can be >> improved. > > - sound's good, and a natural generalization of current mem ref

Re: Proposal: GCC core changes for different address spaces

On Sat, Apr 23, 2005 at 02:26:54PM -0400, Paul Schlie wrote: > - sound's good, and a natural generalization of current mem ref attributes. > > (However ideally, function parameter and result value references would need > to be similarly qualify-able in order to enable the proper attributes to >

Re: Proposal: GCC core changes for different address spaces

> From: Martin Koegler <[EMAIL PROTECTED]> >> On Sat, Apr 23, 2005 at 02:26:54PM -0400, Paul Schlie wrote: >> - sound's good, and a natural generalization of current mem ref attributes. >> >> (However ideally, function parameter and result value references would need >> to be similarly qualify-ab

Re: Proposal: GCC core changes for different address spaces

Paul Schlie wrote: > My impression is that there are 3 fundamental types of memory references: > > - literal-code (call/goto code-label/ptr) > - literal-data (mem static-const-symbol/ptr) > - runtime-data (mem non-static-const-symbol/ptr) > > As such it seems likely sufficient to simply enable the

Re: Proposal: GCC core changes for different address spaces

> Etienne Lorrain <[EMAIL PROTECTED]> wrote: > I see a lot more address space than that in generic processors, not only > embedded systems with EEPROM. - Almost, but they aren't "memory spaces" in the sense that programming languages expect them to be, as they impose implied restrictive semantic

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

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

> James E Wilson wrote: > ... > It relies on MEM_EXPR always being set, which may not be true. But if > there are places creating MEMs from decls without setting MEM_EXPR, then > they probably should be fixed. MEMs created for things like spills to stack > slots may not have MEM_EXPR set, but then

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

Paul Schlie wrote: - Might it be possible to introduce and use by convention a new macro which will always wrap a new pointer in a mem expression with attributes copied from the previous mem/symbol's reference enforced? This is already an easy function call. I don't see how adding a macro mak

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

> From: James E Wilson <[EMAIL PROTECTED]> >> - One of the things that's been eluding me, is that I can't seem to find >> where literal string constant mem references aren't being properly >> declared and/or preserved as READONLY/unchanging references, resulting >> in MEM_READONLY_P failing t

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

On Fri, 2005-04-22 at 15:56, Paul Schlie wrote: > - Why are string literal character arrays not constructed and expanded as > character array literals are? They are constructed and expanded differently, because, obviously, they are different things. I don't understand the point of this question

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

On Fri, 2005-04-22 at 04:58, Paul Schlie wrote: > Thanks. After going through the code, it's even further not clear why > STRING_CST string literal data references treated differently than > static const char array literal data references to begin with? > Why is this necessary? Why is what necessa

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

> From: James E Wilson <[EMAIL PROTECTED]> >> On Fri, 2005-04-22 at 04:58, Paul Schlie wrote: >> Thanks. After going through the code, it's even further not clear why >> STRING_CST string literal data references treated differently than >> static const char array literal data references to begin wi

Propagating attributes for to structure elements (needed for different address spaces)

My current aproach, checking for the eeprom attribute in the GCC calculated types, is not sufficient in some situations: struct y1 { int x; }; struct x { struct y1 y; }; typedef struct x ax __attribute__ ((eeprom)); void test1(ax* x) { x->y.x=1; } In this case, while expanding x->y.x=1, the type o

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

Martin Koegler wrote: > Placing variables in a specfic section is only a part of the problem. I am aware of that. There are already many targets that have special handling for section attributes, that result in different code being generated when a section attribute is present. Mostly these hav

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

On Wed, Apr 20, 2005 at 06:42:08PM -0700, James E Wilson wrote: > Martin Koegler wrote: > > Placing variables in a specfic section is only a part of the problem. > > I am aware of that. There are already many targets that have special > handling for section attributes, that result in different co

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

Martin, I think that the AVR people would very much appreciate if you would report occasionally on your progresses concerning your realization of the different address space issue on your personal HC05 port. (In my opionion, the lack for support of different memory spaces is the key weakness of

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

Martin Koegler wrote: arg 1 >> So, how to change this function? As a MEM_EXPR may only be a DECL or a COMPONENT_REF, storing a indriect_ref of a plus_expr is also not valid. This is, why I had to change the other functions. There is a var_decl here inside the indirect_ref. Will using

Re: Propagating attributes for to structure elements (needed for different address spaces)

On Mon, 25 Apr 2005, Martin Koegler wrote: > The solution would be to add also for the base type of an array the > eeprom attribute. Additonally all elements of structures and unions must > also have the eeprom attribute added. The solution is to implement DTR18037 named address spaces. Natura

Re: Propagating attributes for to structure elements (needed for different address spaces)

oogle finds nothing useable about it), I cannot say something about it. I intend to create different address spaces in GCC using attributes, with only small changes in the core. As I test my ideas on my m68hc05 port, I describe my intended semantics using it, which is (apart for the problem

Re: Propagating attributes for to structure elements (needed for different address spaces)

On Mon, 25 Apr 2005, Martin Koegler wrote: > As I don't know DTR18037 and have no access to it (even Google finds nothing > useable about it), I > cannot say something about it. The current version is WG14 N1095 . It's the standard wa

Re: Propagating attributes for to structure elements (needed for different address spaces)

Martin Koegler wrote: typedef struct x ax __attribute__ ((eeprom)); void test1(ax* x) One possible solution is to change your syntax. eeprom is supposed to be an attribute that applies to a decl. You are using a trick here to apply it to a type via a typedef, which takes advantage of the fact t