Re: Native code generation
Malcolm Wallace <[email protected]> Wed, 24 Nov 2004 10:30:19 +0000
| Newsgroups | gmane.comp.lang.haskell.nhc.user |
|---|---|
| Organization | Dept of Computer Science, University of York |
| Message-ID | <[email protected]> |
Arunkumar S Jadhav <[email protected]> writes: > > About 8-9 years ago, David Wakeling wrote a native code-generator > > for nhc13 > > Is it publically available somewhere ? Not as far as I am aware. You could ask him: [email protected] > I've built a native code generator that takes G-code straight out of SPJ's > book. The way I'm doing it is to represent each g-instruction as a sequence > of subject trees each typically performing a memory operation (like > overwrite root of the redex etc) and then use burg tree pattern matcher to > generate i386 code. How feasible it would be to do something along similar > lines for Gcode generated by nhc. I'm sure that is a reasonable approach. nhc98's G-code is not very complex. Many of the bytecodes are just variations of a single instruction, designed to use the minimum amount of storage where possible. For instance, PUSH_CVAL_P1 i PUSH_CVAL_P2 i j PUSH_CVAL_N1 i PUSH_CVAL_N2 i j ... these all push a value read from the constant table (there is one constant table per function) onto the stack; the only difference is the calculation of the offset from the beginning of the table - is it positive or negative (P or N), and is the offset represented as one byte or two? You may prefer to eliminate the constant tables altogether, and instead do the table-lookup at compile-time. The main reason why there are constant tables in nhc98 is to reduce the size of the generated bytecode by sharing the constants. For a native-code backend, reducing code-size is less important, and you will gain speed by removing the extra indirect step. > And BTW, the __ctype_b still persists :(....I tried all the ways (well > most); linked using the code I got from bugzilla (which Malcolm had also > sent), tried adding that object to Runtime.a with no luck. Will see it > later; I'm surprized that no one reported this problem till now. Perhaps not many people use RedHat 9. Here, I have Slackware 10, RedHat 7.2, and Knoppix. Regards, Malcolm