<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><div><div style="text-align: left;margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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?</div></blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_SpaceA int * foo;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">void bar() {</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "> typedef int _SpaceA;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "> _SpaceA y; // int y.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">}</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Is this really intended?</div></blockquote><div><br class="khtml-block-placeholder"></div><div>Here's the specific language. I misread it.</div><div><br class="khtml-block-placeholder"></div><div>5.1.2 Address-space type qualifiers</div><div><br class="khtml-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">Each address space other than the generic one has a unique name in the form of an identifier. </span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">Address space names are ordinary identifiers, sharing the same name space as variables and</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">typedef names.</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">Any such names follow the same rules for scope as other ordinary identifiers (such</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">as typedef names).</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">An implementation may provide an implementation-defined set of </span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "><i>intrinsic</i></span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">address spaces that are, in effect, predefined at the start of every translation unit.</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">The names of</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">intrinsic address spaces must be reserved identifiers (beginning with an underscore and an</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">uppercase letter or with two underscores).</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">An implementation may also optionally support a means</span></font><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; "> </span></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 11px; ">for new address space names to be defined within a translation unit.</span></font></div></blockquote><br></div><div style="text-align: left;margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Okay, this is goodness. This means the builtin ones can just be macros that expand out to an attribute, or anything else convenient.</div><div style="text-align: left;margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div></div></div><blockquote type="cite"><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</div></blockquote><div><br class="khtml-block-placeholder"></div><div>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.</div></div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>Yep.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><div><blockquote type="cite"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_SpaceA int * foo;</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is not</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">int * _SpaceA foo;</div></blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br style=""></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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.</div></blockquote><div><br class="khtml-block-placeholder"></div><div>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.</div></div></div></blockquote><br></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div>-Chris</div></body></html>