There might well be further changes, in particular to __at, ad where it
can be. Currently, __at is handled both as a specifier and as an aspect
of pointers. IMO, the __at would make more sense as an attribute on the
identifier in a direct declarator.
This would be similar to GCC: In GCC, to place an object at a fixed
address, an attribute is used to place the object into a specific linker
section, then the linker is used to put it at the address. IMO that is a
bit too complicated as the only way to put the object at a fixed
address, since it requires working with the linker, but using an
attribute IMO makes sense.
As an attribute, it should be after the identifier. However, that would
mean changing the place where the __at can be:
int __at(3) x; // Current style - should be possible to keep for now
vs.
int x __at(3); // Attribute location, but still keyword. Might not be
worth supporting.
int x [[sdcc::at(3)]]; // C2X attribute. The future.
I think it will be possible to keep the old form for compability here,
but what won't work any more is having the __at in front or within the type:
__at (3) int x; // I think we should drop support for this
short __at (3) int w; // I think we should drop support for this
I'll see what I can come up with in the parser branch.
Note that there is no such problem with __interrupt, __using, __naked:
Those are already in the right place for an attribute.
Philipp
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
