5 ms·

Yes; at present, adding code generation for new architectures is kind of a nightmare (google "haskell Evil Mangler"). LLVM will make this much simpler (or, at

by kwantam 17y ago

Yes; at present, adding code generation for new architectures is kind of a nightmare (google "haskell Evil Mangler"). LLVM will make this much simpler (or, at least, foist it on the LLVM guys :) )

hga 17y ago
What about GC? When I last looked at LLVM (the current stable release, in fact), it looks like it didn't have a very good story there. Plenty planned out, but little implemented and less solidly.
- jrockway 17y ago
  LLVM is the low-level virtual machine. (Basically portable assembly; except much smarter.) GC is orthogonal. There is some work to add auto-gc to anything on LLVM, but while that's brewing, you can also do it in your runtime. GHC's runtime already does GC, so this is not a big deal.
  - hga 17y ago
    Errr ... OK. So the GHC runtime that supports (supported) GCC (and that now will support LLVM) doesn't depend on any special cooperation by that level below it, and does the GC on top? Hmmm, Gambit-C shows you can do this with good results, but ... uck. Still, I could well see how this new arrangement would be much better than using GCC as a back end.
    - jerf 17y ago
      Remember, this isn't the only backend. Native code generation continues on some architectures. LLVM just has its own benefits.
    - jrockway 17y ago
      You eventually have to have code to run on the CPU. LLVM lets your compiler output LLVM instructions instead of assembly, and then LLVM converts those instructions to assembly. The level of expressiveness is about the same. Your CPU doesn't do GC, so LLVM is not necessarily the best place to do it, either. (LLVM does do other things your CPU doesn't do, which is why C compiled to LLVM runs faster than C compiled to native code in many cases. I imagine this will work well for GHC, as well, although GHC's native codegen can outperform gcc too.) It's also worth noting that Apple (and others) have poured hundreds of thousands of dollars into LLVM. Taking advantage of that is always good, and the whole point of "free software", in fact.
      - hga 17y ago
        Yes, I've looked hard at using LLVM for the backend of a project, so I'm familiar with the above. However LLVM does at least one thing that assembly doesn't, which is implement a stack. It also obviously handles CPU registers (and opaquely). To do accurate garbage collection (http://llvm.org/docs/GarbageCollection.html http://llvm.org/docs/GarbageCollection.html; note, the whole site LLVM site is not loading for me right now) you have to work with it to find roots in the stack(s) and registers. And the state of the implementation of that is what I was talking about. Does this GHC backend use a conservative collector such as the Boehm collector? As I recall VMKit does.
- beza1e1 17y ago
  LLVM is mainly developed by Apple and Objective-C (via clang) requires garbage collection, therefore garbage collection shouldn't be a problem.

by kwantam 17y ago

Yes; at present, adding code generation for new architectures is kind of a nightmare (google "haskell Evil Mangler"). LLVM will make this much simpler (or, at least, foist it on the LLVM guys :) )

hga 17y ago

What about GC? When I last looked at LLVM (the current stable release, in fact), it looks like it didn't have a very good story there. Plenty planned out, but little implemented and less solidly.

jrockway 17y ago
LLVM is the low-level virtual machine. (Basically portable assembly; except much smarter.) GC is orthogonal. There is some work to add auto-gc to anything on LLVM, but while that's brewing, you can also do it in your runtime. GHC's runtime already does GC, so this is not a big deal.
- hga 17y ago
  Errr ... OK. So the GHC runtime that supports (supported) GCC (and that now will support LLVM) doesn't depend on any special cooperation by that level below it, and does the GC on top? Hmmm, Gambit-C shows you can do this with good results, but ... uck. Still, I could well see how this new arrangement would be much better than using GCC as a back end.
  - jerf 17y ago
    Remember, this isn't the only backend. Native code generation continues on some architectures. LLVM just has its own benefits.
  - jrockway 17y ago
    You eventually have to have code to run on the CPU. LLVM lets your compiler output LLVM instructions instead of assembly, and then LLVM converts those instructions to assembly. The level of expressiveness is about the same. Your CPU doesn't do GC, so LLVM is not necessarily the best place to do it, either. (LLVM does do other things your CPU doesn't do, which is why C compiled to LLVM runs faster than C compiled to native code in many cases. I imagine this will work well for GHC, as well, although GHC's native codegen can outperform gcc too.) It's also worth noting that Apple (and others) have poured hundreds of thousands of dollars into LLVM. Taking advantage of that is always good, and the whole point of "free software", in fact.
    - hga 17y ago
      Yes, I've looked hard at using LLVM for the backend of a project, so I'm familiar with the above. However LLVM does at least one thing that assembly doesn't, which is implement a stack. It also obviously handles CPU registers (and opaquely). To do accurate garbage collection (http://llvm.org/docs/GarbageCollection.html http://llvm.org/docs/GarbageCollection.html; note, the whole site LLVM site is not loading for me right now) you have to work with it to find roots in the stack(s) and registers. And the state of the implementation of that is what I was talking about. Does this GHC backend use a conservative collector such as the Boehm collector? As I recall VMKit does.
beza1e1 17y ago
LLVM is mainly developed by Apple and Objective-C (via clang) requires garbage collection, therefore garbage collection shouldn't be a problem.