Philipp Klaus Krause schreef op 2022-06-21 13:00:
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

I'm ok with dropping the ones you propose to be dropped. But I think we
really should try to keep the current style for compatibility. I'm also
ok with adding the attribute location variant, though I'm not sure of
its worth.

On a related note: is something specified for non-initialized variables?
Currently SDCC creates no implicit initializer to zero when __at is used
and no explicit initializer is provided.
int __at(10) x; // not initilized to zero
int __at(12) y = 0x1234; // is initialized

Maarten


_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Reply via email to