Also, the TR specifies that the names of address spaces are in the
type namespace. My question is, does that mean there also needs
to be an AddressSpaceType class?
I haven't read the TR closely, but if it says this, it is very
strange :). I think this means that _SpaceA can't be either a
macro or a typedef. The issue is that it being a type means that
this should be legal (assuming _SpaceA is a valid space for the
current target:
_SpaceA int * foo;
void bar() {
typedef int _SpaceA;
_SpaceA y; // int y.
}
Is this really intended?
Here's the specific language. I misread it.
5.1.2 Address-space type qualifiers
Each address space other than the generic one has a unique name in
the form of an identifier.
Address space names are ordinary identifiers, sharing the same name
space as variables and
typedef names. Any such names follow the same rules for scope as
other ordinary identifiers (such
as typedef names). An implementation may provide an implementation-
defined set of intrinsic
address spaces that are, in effect, predefined at the start of every
translation unit. The names of
intrinsic address spaces must be reserved identifiers (beginning
with an underscore and an
uppercase letter or with two underscores). An implementation may
also optionally support a means
for new address space names to be defined within a translation unit.
Okay, this is goodness. This means the builtin ones can just be
macros that expand out to an attribute, or anything else convenient.
I don't recall off-hand. Steve is the guru of attributes, though
Nate may also know. It would certainly be nice to have these be
typedefs or #defines for __attribute__ syntax, just to avoid having
to tweak the parser for each device that needs address spaces.
I wholeheartedly agree. My first implementation used attributes, but
fails the test below. I looked at what it would take to get the
parser to understand otherwise and it seemed very non-trivial.
Especially because the number and name of keywords is target
specific it'd need something akin to attribute parsing, but just for
namespaces. Doesn't seem worth it.
Yep.
_SpaceA int * foo;
is not
int * _SpaceA foo;
If attributes don't support this mechanism right now, I think we
should extend them to work with it. A specific attribute (e.g.
"address_space" in __attribute__((address_space(1)))) should be
markable as applying to the type instead of the decl.
Named address spaces were implemented using attributes successfully
by Codeplay in the VectorC compiler that I have experience with, so
I agree that it would be good to have this functionality.
Ok, so it sounds like the right approach is to extend our current
attribute support to allow them to be applied in-place to the types as
they are parsed.
-Chris
_______________________________________________
cfe-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
