[LLVMdev] OT: new here, dynamic/runtime compilation (in general)

[BGB]

  ----- Original Message ----- 
  From: Chris Lattner 
  To: BGB 
  Cc: LLVM Developers Mailing List 
  Sent: Monday, October 22, 2007 12:28 PM
  Subject: Re: [LLVMdev] OT: new here, dynamic/runtime compilation (in general)




  On Oct 21, 2007, at 6:23 PM, BGB wrote:


    ok, just in my case, I guess I am a little fussy/weird, wanting efficient dot and cross products  (if at all possible, though these operations at present don't exist natively within SSE...), among many other operations (length, lerp, renormalization, ..).

    then again, probably a fairly smart compiler could still get plenty good results out of inline functions and intrinsics or something (as it so happens, my compiler is not so smart here, so I made these features builtin, and fell back to functions for more involved operations, such as quaternion slerp, ...).




  llvm-gcc and clang both fully support GCC style generic vectors and altivec/sse intrinsics.  In addition, clang supports "glsl" style vector permutations, direct vector element access, etc.  The LLVM optimizer and code generator supports many vector operations independent of the front-end syntax, as well as highly optimized code generation for Altivec and SSE.

yes, cool.

in any case, people can probably build whatever they need using what is provided...
(and, if all this is already built in, all the better...).


but, yes, it may not matter much, I simply have some stuff that is non-standard and tweaky is all...

sorry if it seems I am obsessing, or if this topic seems inappropriate here...


looking, trying to determine if GLSL has these operations (ok, it has a few, implemented as functions at least, like 'dot' and 'cross'). note that my interface is a little different than GLSL, but I may change it to more closely resemble that of GLSL.

now, of course, what I was not sure of (what I keep going on about) was not about specific general vector features (aka: much of anything what SSE itself, or most compilers, provide), but the specifics of geometric vectors (like in 3D or physics).

(one has special fun trying to implement these well within the context of SSE...).

I have some funky operator overloading as well: 'vec^vec' gives a dot product ('vec*vec' gives a per-component product, as in gcc); and 'vec%vec' gives a cross product. for quaternions, 'quat*quat' is overloaded for a quaternion product (grassman).

per-component access:
I treat vectors like some kind of implicit struct.
components are: x,y,z,w. i, j, and k are analogous to x, y, and z.
looks like GLSL also has r, g, b, and a as synonyms as well (don't have these in my case, then again, I don't usually do color calculations either...).

so, for a vector v: v.x, v.y, v.z, or v.w; or a quat q: q.i, q.j, q.k, or q.w.
I also do this for complexes, where complexes are viewed as having 2 components: i and w (matching them with quaternions as such).

so, it is valid to type: "(float _Complex)QUAT(3,1,0,0);", which comes out as the complex
"3+1i" (j and k are simply discarded). note that, at present, it is not possible to type out quaternions like complexes, say "(3+1i+0j+0k)*(0+5i+1j-2k)", though this could be a sane feature, it would also give pressure to allow similar for vectors, such as ("3x+4y-5z", which may look odd and misleading), and simply allowing it for complexes may be enough...

hmm: as for vectors, the funky syntax could be very useful for translation and accelaration ("vel-=gravity*1z;", as opposed to "gavity-=VEC3(0,0,gravity);").

who knows though...


misc, quaternions (general concept):
http://en.wikipedia.org/wiki/Quaternion




  -Chris



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071022/fe2849b2/attachment.html>