Which may not be litterally a bug, but would like to restrict the functions parameter in this way. Is this possible? (as given the below code example, wan't to be able to identify data stored in program read-only program ROM as being "static const", which they are, and corespondingly identify parameters to functions similarly restricted to "static const" data which actually needs to be accessed via a different load instruction on the avr, do to it's harvard memory architecture. simple example desired code: int foo (static const char * s, char v) /* where s is desired to be restricted to a (static const *) */ { return s[v]; } int main (void) { volatile char v; static const char s[] = "some string"; /* as s[] is stored in program memory */ return foo (s, v); } Where idealy then if GCC can preserve the (static const *) attributes then even such references within functions should be able to be idententifed during rtl/template matching for code generation hopefully enabling (static const *) to be dereferenced with differnt load instructions than (const *)?
No static is wrong here, period, what you need is an attribute which tells the back-end that these are are pointers to ROM and such.
Subject: Re: error generated for storage class specified for function parameter > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-01 > No static is wrong here, period, what you need is an attribute which tells > the back-end that these are pointers to ROM and such. Yes I understand. However it seems somewhat ironic that "static const" already does just that, as it specifies the storage class and access restrictions used to determine exactly the data stored in ROM; as such it seems less invasive to consider allowing it to be optionally accepted as a more restrictive parameter type specifier, rather than alternatively requiring the introduction of a nearly redundant non-standard storage type specifier in it's place, seemingly requiring modifications to much of GCC's internals, from the parser down through to the code generator to be made aware of this new attribute; unless I misunderstand the extent of the surgery likely required? (might the optional acceptance of a static storage class attribute for parameters be worth considering, given the apparent lack of less invasive alternatives?)
Subject: Re: error generated for storage class specified for function parameter schlie at comcast dot net wrote:- > Yes I understand. However it seems somewhat ironic that "static const" > already does just that, as it specifies the storage class and access What if it were the pointer that was like this? You need a type qualifier, not a storage class. Neil.
Subject: Re: error generated for storage class specified for function parameter > - Additional Comments From neil at daikokuya dot co dot uk 2005-03-01 >> Yes I understand. However it seems somewhat ironic that "static const" >> already does just that, as it specifies the storage class and access > > What if it were the pointer that was like this? You need a type > qualifier, not a storage class. - unless I misunderstand the question, the only way a pointer itself would be stored in ROM were if it were itself a static const value, and in turn would itself need to be referenced by a (static const *), where once referenced, (i.e. the pointer's value is now in a non-static variable) so it itself never be further qualified (I think)?
Subject: Re: error generated for storage class specified for function parameter On Tue, 1 Mar 2005, schlie at comcast dot net wrote: > - unless I misunderstand the question, the only way a pointer itself would > be stored in ROM were if it were itself a static const value, and in turn > would itself need to be referenced by a (static const *), where once > referenced, (i.e. the pointer's value is now in a non-static variable) so > it itself never be further qualified (I think)? Just as you can have "char *" and "char *const" and "const char *" and "const char *const", you can have "ROM pointer to ROM" and "ROM pointer to RAM" and "RAM pointer to ROM" and "RAM pointer to RAM", and similarly with more levels of indirection. If you want to handle address spaces properly, look at DTR 18037 (or the final TR once the subclause numbering has been agreed with ISO). There is no bug here, although making GCC handle multiple address spaces properly in the manner described in DTR 18037 might be useful for some targets.
Subject: Re: error generated for storage class specified for function parameter > --- Additional Comments From joseph at codesourcery dot com 2005-03-01 > Subject: error generated for storage class specified for function parameter > >> On Tue, 1 Mar 2005, schlie at comcast dot net wrote: >> - unless I misunderstand the question, the only way a pointer itself would >> be stored in ROM were if it were itself a static const value, and in turn >> would itself need to be referenced by a (static const *), where once >> referenced, (i.e. the pointer's value is now in a non-static variable) so >> it itself never be further qualified (I think)? > > Just as you can have "char *" and "char *const" and "const char *" and > "const char *const", you can have "ROM pointer to ROM" and "ROM pointer to > RAM" and "RAM pointer to ROM" and "RAM pointer to RAM", and similarly with > more levels of indirection. > > If you want to handle address spaces properly, look at DTR 18037 (or the > final TR once the subclause numbering has been agreed with ISO). There is > no bug here, although making GCC handle multiple address spaces properly > in the manner described in DTR 18037 might be useful for some targets. Thank you for the reference, and do also agree there's no "bug" in the present implementation. However do observe that although the present use of of a storage-class specifier in the context of a parameter type-qualifier is not supported by the present standard; it may be worthy of consideration as a sensible optionally enabled extension; as the use of the combination "static const" in this context seems fully consistent with the specification of an otherwise explicit ROM address-space-qualifier, as it is just this combination which is typically used to identify values which may be stored as ROM'ed data. Therefore seems reasonable to consider compatibly optionally extending the use of "static const" as an implied read-only address-space qualifier, as it would not introduce any ambiguities because it's present use in this context is not supported (and seems easier to initially enable, than DTR18037 is). Might you be willing to consider a patch enabling this option use? --- As an aside, with respect to the various permutations of static const *, etc. It seems that by simply designating the combination "static const" as an optional legal type qualifier within contexts not otherwise supporting the designation of a storage-class specifier, GCC can be relatively easily enabled to support an implied primitive ROM address-space which is distinct from the remaining default address space (being implied by everything not "static const"). For example, with respect to the optional extension of "static const" as a function parameter's qualifier, since parameters are passed in RAM, ROM (i.e. "static const") values may only be passed by reference by definition, which eliminates I believe much of it's potential complexity. For example: int foo (int * static const x); Is physically impossible, as parameters are implied to be variable, therefore must be passed in RAM, therefore must not in ROM. However as you note, with the exception of this restriction, any subsequent hierarchy of qualifiers would be valid, although some of likely limited practical use.
Subject: Re: error generated for storage class specified for function parameter On Tue, 1 Mar 2005, schlie at comcast dot net wrote: > not supported by the present standard; it may be worthy of consideration as > a sensible optionally enabled extension; as the use of the combination > "static const" in this context seems fully consistent with the specification It seems like an extension that would not be sensible at all. Type 2 TRs are for experimental features and should be considered as "if you want to do this, it would be a good idea to do it this way; you might find issues through implementation experience which lead to the TR being improved and the subject matter eventually becoming less experimental". So given there's a DTR on this subject, if you want to implement address spaces you should follow the TR and so assist future standardisation rather than implementing some random other extension to do the same thing. We shouldn't go implementing our own new extension to do something there's a standard way to do.
Subject: Re: error generated for storage class specified for function parameter > -- Additional Comments From joseph at codesourcery dot com 2005-03-01 > Subject: error generated for storage class specified for function parameter > >> On Tue, 1 Mar 2005, schlie at comcast dot net wrote: >> not supported by the present standard; it may be worthy of consideration as >> a sensible optionally enabled extension; as the use of the combination >> "static const" in this context seems fully consistent with the specification > > It seems like an extension that would not be sensible at all. Type 2 TRs > are for experimental features and should be considered as "if you want to > do this, it would be a good idea to do it this way; you might find issues > through implementation experience which lead to the TR being improved and > the subject matter eventually becoming less experimental". So given > there's a DTR on this subject, if you want to implement address spaces you > should follow the TR and so assist future standardisation rather than > implementing some random other extension to do the same thing. We > shouldn't go implementing our own new extension to do something there's a > standard way to do. Understood. Are you aware of any existing efforts to extend GCC in this way; or likely need to start from scratch? (any warnings/recommendations?)
Subject: Re: error generated for storage class specified for function parameter On Tue, 1 Mar 2005, schlie at comcast dot net wrote: > Understood. Are you aware of any existing efforts to extend GCC in this way; > or likely need to start from scratch? (any warnings/recommendations?) I am not aware of any existing effort to implement any part of DTR 18037.