<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 8, 2009, at 11:30 AM, John Thompson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div> <div>Thanks, Chris.</div> <div> </div> <blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"> <div>I don't know how much magic is inherent in this language extension. Would it be bad to to make __vector *always* be on when AltiVec is enabled (whether or not it is followed by a 'numeric type keyword')? We could then make 'vector' be fuzzier. I'm still vaguely uncomfortable with 'vector' changing semantics depending on its lexical context, but understand that you probably don't have a choice here :)</div> </blockquote></div> <div><br>I think I see. Treat "__vector" as a normal keyword token, and if "vector" is encountered, I still do the context check and effectively treat it as "__vector"?</div> </blockquote><div><br></div>Right.</div><div><br><blockquote type="cite"><div> </div> <div> <blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"> <div>Sure, if that works! I don't know what __vector does. </div></blockquote></div> <div> </div> <div>My understanding is that "__vector" (or "vector") in this context is always followed by a numeric type, i.e. "_vector unsigned int". My guess was that this would be effecticvely equivalent to "__attribute__((vector_size(16))) unsigned int", so the plan would then be to have the resulting type for these two be the same after the semantic action.<br></div></blockquote><div><br></div><div>so 'vector' doesn't work as a type qualifier? For others type qualifiers, you can arrange them, e.g. "const int" == "int const" etc.</div><div><br></div><blockquote type="cite"><div><blockquote style="border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; " class="gmail_quote"><div>I think so, though we also need an 'altivec.h' for clang to use, in a similar spirit to 'xmmintrin.h' for sse.</div></blockquote> <div> </div> <div>Yes, probably, if nothing else just to be compatible with gcc. (It's mentioned in the Altivec standard in section 2.6 of <a href="http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf">http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf</a>). I was told it was orginally deprecated, but then left in to help with early implementation. Looking at the one we have for the PS3 gcc compiler, it seems to be the PowerPC version, and mostly just maps Altivec names to the "__builtin_*" functions.</div></div></blockquote><div><br></div><div>Right. Be aware that you can't just use the GCC version of the header (afaik). The terms of the license I've seen are something to the effect of "this header is GPL unless it is compiled with GCC". In any case, you wouldn't want to reuse it directly anyway, because you'd want to implement the 'simple' operations in terms of generic vector operations instead of builtins.</div></div><br><div>-Chris</div></body></html>