Arunkumar S Jadhav
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: D.Wakeling@exeter.ac.uk
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