> 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
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
> 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
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
>
> 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
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
> 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
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
