Thanks guys.  Those were some very interesting discussions to read through.  I'm convinced that C is not such a great target, and the Haskell implementers I think concluded the same (producing C-- along the way).<br><br>
But I'm not clear on how the discussion of C being a bad target for lisp is applicable to LLVM.  LLVM is meant to support dynamic language; their intro Kaleidoscope tutorial shows how to construct and compile a lisp-like one.<br>
<br>Granted LLVM does have a C and C++ compiler (and these are the most production quality), but it also has (in various states of maturitiy) Ruby, Python, C#, Pure (term re-writing language), Haskell, Java, D, and Lua implementations, most of which try to take advantage of the lovely Just-in-time compilation features (for x86/64 and PPC/64). There are hooks for precise GC, and the biggest win of all is that there are so many backends (although the C backend for LLVM is reported decaying for lack of use).  If you don't need JIT, then you get x86, x86_64, PPC, PPC64, ARM, Thumb, Sparc, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore, all for free if you target LLVM.<br>

<br>This is fairly academic, but I would note that GPGPU (General Purpose GPUs) such as the latest nVIDIA cards sport, have come a long way; each of the 384 cores in my $250 PCIe graphics card is a fully capable processor; the only limitations are really memory bandwidth for getting data onto the card.  But again, there's no need to think about this directly, because several projects are working on producing LLVM targets (OpenCL, PTX), which means if one can produce LLVM IR, then you get GPGPU support for free.<br>

<br>Massively parallel development isn't easy, and I suspect that a Lisp REPL based development environment (there is a PyCUDA now), could be a big win.  But then again, since I'm looking at doing this work myself, I was just trying to get a sense of how abstracted the IR-> backend stage is to begin with. If there's a clean separation, maybe it's straightforward?  I know, probably wishful thinking ;-)  But I'd love to be wrong.<br>
<br>Thanks guys.  <br><br>Jason<br><br><div class="gmail_quote">On Mon, Mar 28, 2011 at 2:56 PM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


<div><br>
On Mar 28, 2011, at 12:45 PM, Gary Byers wrote:<br>
<br>
> Porting a lisp to a GPU makes only slightly more sense to me than porting<br>
> a lisp to an FPU.  (Yes there are differences and a GPU may be a lot closer<br>
> to it, buy neither is exactly a general-purpose computer.  You can download<br>
> GPU code into the unit and execute it - so the FPU analogy breaks down -<br>
> but you'd probably find that that code can do some things incredibly quickly<br>
> and that other things are incredibly awkward.)  You might be able to do<br>
> something that allows you to express certain kinds of algorithms in Lisp,<br>
> compile that code into machine code for a GPU, download that code, execute<br>
> it, and find that the GPU was fast enough to make that all worthwhile; that's<br>
> probably easier than it would be to figure out how to implement CONS reasonably<br>
> or how to implement OPEN at all.<br>
<br>
</div>This is not quite as outlandish as Gary is making it sound.  See:<br>
<br>
<a href="http://vorlon.case.edu/%7Ebeer/Software/FPC-PPC/FPC-PPC-DOC-0.21.txt" target="_blank">http://vorlon.case.edu/~beer/Software/FPC-PPC/FPC-PPC-DOC-0.21.txt</a><br>
<br>
for inspiration.<br>
<font color="#888888"><br>
rg<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Jason E. Aten, Ph.D.<br><br><br>