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

[BGB]

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




  On Oct 21, 2007, at 5:27 PM, BGB wrote:


    well, sadly, I am not sure how people are on this list...


  I'd suggest browsing through the llvmdev mailing list archive.

   
yes, may make sense.
just, I encounter a lot of places where people start flaming as soon as the topic drifts at all OT (as per their personal definitions).



    now, what I do with it is this:
    I use C as a scripting language...




  Sounds like a fun project.  Note that the clang C front-end also supports use in a JIT environment: this will allow you to JIT the full generality of C code (when clang is complete).  Today while clang is not complete, it is far enough along to be very useful for a wide variety of numeric environments, as its scalar, vector, and array support are quite advanced.

yes.
clang is interesting, so I will continue to watch and hope it does something cool.

sorry for not having done much research here (if it so happens all this exists already), but I will assume that it likely implements the same basic kind of vector handling as gcc (rather than geometric vectors). they need not be confused (per-element multiplication is an almost useless operation in geometry, but dot-product is almost mandatory...).

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, ...).

I suspect the people behind gcc for whatever reason did not know of or couldn't really see much need for geometric vector support...


I also use quaternions (as yet another tweaky compiler extension, basically, they look like 4 element float vectors but have a few different operations from those of 4-element geometric vectors).

quaternions are also a complex space, and can thus also be used as part of the normal numeric tower (much as good old complexes...). though a little arbitrary, I also allow operations between complexes and quaterions (the complex automatically gets promoted to a quat in the process), but it is arbitrary in that the complexes are arbitrarily mapped to the WI plane (much as how 2D vectors automatically map to the XY plane in 3D situations, or converting a 3D-vector to a 2D vector often involves simply discarding Z, even though the XY in a 2D vector could concievably map to any possible plane within a 3D space...).

it is arbitrary, but it works...


but, I guess I will have to investigate all this (to see more what LLVM does and does not support...).

dunno if, or if there would be any intention to implement features like these (I would not mind that much though if they were only builtin functions or similar, as that is how my gcc-fallback support works, but in the case of my compiler, many of these operations also exist via overloaded operators).

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, ...).

or something...




  -Chris

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