On 04 July 2005 12:44, Peter A Jonsson wrote:
dons@cse.unsw.edu.au (Donald Bruce Stewart) writes:
pj:
I would like to use nativeCodeGen outside of GHC to generate code from an IR. The IR would be produced by a third party program, not the GHC frontend.
Looking at CVS HEAD I can see that GHC.hs exports plenty of things (for the GHC API I presume), but I can't find anything that lets me input some sort of IR and have ASM in return. Am I missing it somewhere or is there no way to input IR and get ASM in return? If there isn't, is such a feature planned/wanted?
If such a feature isn't planned, I would appreciate any ideas on how to to accomplish the same thing. I have no problems with having a build tree of GHC laying around if that makes things easier. It would be a nice bonus if it made my maintenance burden low.
You could use External Core with GHC, couldn't you?
Thanks for the quick answer!
Maybe it's my lack of understanding of the inner workings of GHC but reading "An External Representation for the GHC Core Language" I get the impression that the dumping of Core Language is basically targeted at researchers writing their own optimization passes or backends for Haskell/GHC so they can use the existing infrastructure of GHC. My request is the other way around - I want to throw out the frontend but use* ("low-level") parts of the backend of GHC.
The Core Language seems to be translated into STG-machine code, which according to my understanding is an abstract machine desinged to support non-strict higher-order functional languages. I was hoping that the laziness was in the STG-syntax, not in Cmm. Looking at output of -ddump-cmm it resembles C-- quite closely (also implied by comments in PprCmm.hs), which makes me believe that is the "correct" level of abstraction for me.
*) The reasons are two-fold, one is that it is written in Haskell, the other is that it generates code for more than one architecture today.
If the language you want to generate code for is at the level of C--, then you could indeed use GHC's native code generator. There isn't an interface to it exposed by the GHC API, but you can use the interfaces directly: the AsmCodeGen module is the top-level of the native code generator, and basically takes Cmm (defined in module Cmm) and produces assembly code. However, if you want to do this, I wonder whether you would be better off just using the real C-- compiler. Cheers, Simon
If the language you want to generate code for is at the level of C--, then you could indeed use GHC's native code generator. There isn't an interface to it exposed by the GHC API, but you can use the interfaces directly: the AsmCodeGen module is the top-level of the native code generator, and basically takes Cmm (defined in module Cmm) and produces assembly code.
However, if you want to do this, I wonder whether you would be better off just using the real C-- compiler.
Ok, I gave it a spin, that was "interesting". Things I wrote down while looking at it that might be of interest to others: I tried to build with gcc 3.4.1 and it didn't work very well. Found a mail from November 2004 (<Message-Id: 419B599C.2020204@tzi.de>) which had the same problem. In a reply you said that it was the JMP_-macro in TailCall.h and changing the cast would make the warning go away. It did, however I think I messed up with something else since it made other problems appear. I reverted my changes and switched gcc instead. I had perl 5.005_03 first in my path, that made the splitter not work. Changing to a newer version made it work. Maybe a test could be added to configure to avoid too old versions of perl? All those "Bad eta expand" looks slightly scary when building for the first time. Found a mail from Simon Peyton Jones which made me less worried. Maybe it could be documented that those are expected in the building guide? The GHC commentary was written for pre-CMM NCG. I tried patching that while going through the code but I just ended up butchering the document to basically contain no information whatsoever. I'm not sure it's helpful at all in its current shape though, unfortunately. Needed a patch to build NCG. I tried to preserve as much of the previous structure in order to avoid introducing bugs, but I wasn't entirely successfull. I've attached the patch and would appreciate if someone could glance over it looking for obvious errors. With this patch a bunch of array tests with WAY=normal fails, all in the same way: Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. Didn't find any obvious reason for the failure. If anyone wants to look into it arr005.hs might be a good place to start. Did not check much of the other regression tests since the above failure seems pretty vital to the functioning of the compiler. / Peter
participants (2)
-
Peter A Jonsson -
Simon Marlow