LLVM and C99 and classic Mac OS (Re: LLVM and HLVM)
On Aug 22, 2006, at 5:52 PM, John Siracusa wrote: Has anyone looked at LLVM lately? http://llvm.org/ I discovered it a few years ago. My personal interest is in the portable C back end, so I can use the g++ compiler front end and send the output through CodeWarrior or MPW compilers, whose language support is frozen due to non-development (and therefore may have issues with C99 or modern C++ constructs) but handle C89 just fine. This will require a fairly large Round Tuit, of course. This pattern may also be applicable to MSVC. Josh P.S. Hi, John! I loved your article on the Spatial Finder.
Re: LLVM and HLVM
On 8/22/06, John Siracusa [EMAIL PROTECTED] wrote: Has anyone looked at LLVM lately? Yes, actually, I was looking at it just the other day. I couldn't get it to build on x86-64, but I talked to some of the developers over in their IRC channel, and they told me that this would be forthcoming (in two weeks or so), so I'm going to hold off for a while and then try it then. On the other hand, Parrot built quite nicely on x86-64, although I think I like the 32-bit build (which also built just fine, albeit without ICU) better due to the excellent JIT support. http://llvm.org/ It seems to be making a lot of progress lately with the support of Apple (which is using LLVM for its own purposes in Mac OS X). Is there anything there Parrot can steal? Would it make sense for Parrot to target LLVM bytecode and let LLVM do further optimization and native code generation? I don't know that there'd be much benefit in directly targeting LLVM, but I do know that it'd be a lot easier to just try using one of their gcc front-ends to compile parrot. Maybe I'll try that out in a few weeks, provided that the x86-64 support is there. There's also the predictably named HLVM: http://hlvm.org/ Now that looks interesting, if totally pre-alpha; thanks for mentioning it! which looks vaguely Parrot-ish. Check out the comparison chart: http://hlvm.org/docs/FAQ.html Anyway, I'm just thinking out loud, here. Sorry if it's all old news to the Parrot dev gurus. It probably is, and I'm no guru, but as projects change and develop, I don't think it hurts to compare and re-evaluate now and then. :) -John -- Peter
Re: LLVM and HLVM
On 8/23/06, Aaron Sherman [EMAIL PROTECTED] wrote: On 8/23/06, peter baylies [EMAIL PROTECTED] wrote: On 8/22/06, John Siracusa [EMAIL PROTECTED] wrote: Has anyone looked at LLVM lately? [...] On the other hand, Parrot built quite nicely on x86-64, although I think I like the 32-bit build (which also built just fine, albeit without ICU) better due to the excellent JIT support. Not sure if the list will let this through, since I'm subscribed under another account, but here's the problem with that: llvm is a very light layer, but it's yet another layer. To put it between parrot and hardware would mean that parrot is JITing to LLVM byte-code, which is JITing to machine code. Not really ideal. That's a good point--at least on platforms where JIT is already supported for Parrot, it'd probably be desirable to bypass or not use LLVM for that. However, it shouldn't matter to me at all when I do try building Parrot on top of LLVM on x86-64. :) -- Aaron Sherman Senior Systems Engineer and Toolsmith [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: LLVM and HLVM
On 8/23/06, peter baylies [EMAIL PROTECTED] wrote: On 8/22/06, John Siracusa [EMAIL PROTECTED] wrote: Has anyone looked at LLVM lately? [...] On the other hand, Parrot built quite nicely on x86-64, although I think I like the 32-bit build (which also built just fine, albeit without ICU) better due to the excellent JIT support. Not sure if the list will let this through, since I'm subscribed under another account, but here's the problem with that: llvm is a very light layer, but it's yet another layer. To put it between parrot and hardware would mean that parrot is JITing to LLVM byte-code, which is JITing to machine code. Not really ideal. -- Aaron Sherman Senior Systems Engineer and Toolsmith [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: LLVM and HLVM
On 8/23/06 4:09 PM, Aaron Sherman wrote: here's the problem with that: llvm is a very light layer, but it's yet another layer. To put it between parrot and hardware would mean that parrot is JITing to LLVM byte-code, which is JITing to machine code. Not really ideal. ...unless LLVM does a much better job of native code generation than the existing Parrot code, that is. Optimization seems to be LLVM's thing. -John
Re: LLVM and HLVM
John Siracusa wrote: On 8/23/06 4:09 PM, Aaron Sherman wrote: here's the problem with that: llvm is a very light layer, but it's yet another layer. To put it between parrot and hardware would mean that parrot is JITing to LLVM byte-code, which is JITing to machine code. Not really ideal. ...unless LLVM does a much better job of native code generation than the existing Parrot code, that is. Optimization seems to be LLVM's thing. Keep in mind that you're not talking about some HLL generating LLVM bytecode. You're talking about Parrot reading in Parrot byte code, JITing to LLVM and then going through that dance again. The amount of lossage in those layers of translation simply cannot be worth whatever the difference is between LLVM optimization and Parrot's JIT, since Parrot will already have generated code that makes it MORE difficult to optimize. I'll buy it if I see numbers, but I'm highly skeptical.
LLVM and HLVM
Has anyone looked at LLVM lately? http://llvm.org/ It seems to be making a lot of progress lately with the support of Apple (which is using LLVM for its own purposes in Mac OS X). Is there anything there Parrot can steal? Would it make sense for Parrot to target LLVM bytecode and let LLVM do further optimization and native code generation? There's also the predictably named HLVM: http://hlvm.org/ which looks vaguely Parrot-ish. Check out the comparison chart: http://hlvm.org/docs/FAQ.html Anyway, I'm just thinking out loud, here. Sorry if it's all old news to the Parrot dev gurus. -John
