Re: Proposal: GCC core changes for different address spaces

[Paul Schlie <schlie at comcast dot net>]

> From: Paul Schlie <schlie@comcast.net>
>> 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 parameter and result value references would need
>  to be similarly qualify-able in order to enable the proper attributes to
>  be associated and enforced when references to such attributed objects are
>  passed-to/returned-from function calls; as otherwise the object's storage
>  reference attribute will be lost; which could in theory could be enabled
>  by allowing the qualification an arbitrary variable, parameter, result
>  storage type reference as a natural extension; thereby allowing the
>  specification of a pointer parameter to a static const value be specified
>  as "(static const)*", as opposed to being parsed as "static (const *) by
>  default which specifies a static pointer parameter which is prohibited,
>  therefore wouldn't introduce an ambiguity if the optionally enabled.)

To be somewhat clearer, a storage class could potentially qualify the type
of an referenced object, just as the target specific type qualifiers may
(i.e. rom, eeprom, progmem, etc.) when used within the context of a function
parameter or result type specification, i.e. (rom const)* or (static const)*
as a possibility to enable the more generic, and somewhat less target
specific qualification of static-const/literal and label/function() mem
references in addition to the use of more target specific named ones?