> 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
