Hello All, As I understand it, nhc98 generates byte-code out of a program that is interpreted by mutator. I've developed a native code generator (for i386) that takes as input G-code which is described in SPJ's book. Now I would like to do the same for G-code produced by nhc98. I would like to know. 1) Has any one tried this (nhc G-code to native code generation) ? If yes then it would be great if we can share some of the ideas. 2) Is it possible to generate native code fully *just* by looking at G-code and symbol table generated by nhc98 ? Any pointers / suggestions would be really helpful. Regards, -- Arunkumar S Jadhav, Masters Student, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk
Arunkumar S Jadhav
As I understand it, nhc98 generates byte-code out of a program that is interpreted by mutator.
Yes.
I've developed a native code generator (for i386) that takes as input G-code which is described in SPJ's book. Now I would like to do the same for G-code produced by nhc98. I would like to know.
1) Has any one tried this (nhc G-code to native code generation) ? If yes then it would be great if we can share some of the ideas.
About 8-9 years ago, David Wakeling wrote a native code-generator for nhc13. The performance of the resulting code was not a big improvement on byte-code interpretation - about a 2x speedup. He speculated that the basic G-code was not a good starting place, and that an STG machine intermediate language would probably lead to better code generation, with more room for further optimisations.
2) Is it possible to generate native code fully *just* by looking at G-code and symbol table generated by nhc98 ?
Almost. In addition, the generated code must co-operate with the runtime system (e.g. GC). The code generator needs to know such things as: the layout patterns of values in memory; where the constant-table for a function is stored; and so on. If you do develop an i386 code-generator for nhc98, do please make it available, either as a separate distribution, or by feeding patches back to us to incorporate into the main CVS repository. Regards, Malcolm
Thanks a lot for your inputs. I've a problem with recent nhc98 release. (1.16). When run on a .hs file, in the last stage of compilation I get a linker error stating that __ctype_b is not defined. I found out that this was problem with glibc version of RH9 (may be previous releases too) in that __ctype_b has been deprecated in the latest glibc. Is there any patch or workaround for that ?. Right now I'm just interested in Gcode produced by nhc98 so the problem is not that severe but it's good to have complete working system. -Regards, -- Arunkumar S Jadhav, Masters Student, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk
I've a problem with recent nhc98 release. (1.16). When run on a .hs file, in the last stage of compilation I get a linker error stating that __ctype_b is not defined.
nhc98 does not appear to use __ctype_b directly - I could not find it any name like it anywhere in the sources. Are you using a binary distribution of nhc98? If so, you can probably solve the problem by re-building the whole compiler from sources. Regards, Malcolm
On Monday 22 November 2004 21:28, Malcolm Wallace wrote:
nhc98 does not appear to use __ctype_b directly - I could not find it any name like it anywhere in the sources
Yes, it's not used directly. But I see many references to it in object files that are either inside archive [ e.g haskellInit.o that is in Runtime.a has reference to __ctype_b, to be precise the function numArg(...) seems to use it indirectly via C builtin function isdigit(...) ] or binaries. You can run "nm *" in /lib/nhc/$YOURARCHITECTURE/ directory to see many references to __ctype_b. I infact built nhc from source distribution, and tried rebuilding it, but this link error persists. I'm almost certain that very few files need to be modified ('coz not many references) to make it compatible with current glibc, but don't know the over all design of compiler so can't hack into it. Regards, -- Arunkumar S Jadhav, Masters Student, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk
nhc98 does not appear to use __ctype_b directly - I could not find it any name like it anywhere in the sources
Yes, it's not used directly. But I see many references to it in object files
OK, this looks like an incompatibility between the C compiler and
glibc shipped with RedHat 9. There is more about the issue here:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86465
including some suggested fixes. For instance, the following short C
file can be compiled and added to the Runtime.a archive, to resolve
the deprecated __ctype_b symbol to the new __ctype_b_loc version.
Regards,
Malcolm
----
/*
* ctype_b.c
*
* This file has been added to compensate for a bug in
* version 2.3.2 of the glibc library for RH8.
*/
#define attribute_hidden
#define CTYPE_EXTERN_INLINE /* Define real functions for accessors. */
#include
On Monday 22 November 2004 19:55, you wrote:
About 8-9 years ago, David Wakeling wrote a native code-generator for nhc13
Is it publically available somewhere ? 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. 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. Regards, -- Arunkumar S Jadhav, Masters Student, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk
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
On Wednesday 24 November 2004 16:00, Malcolm Wallace wrote:
PUSH_CVAL_P1 i PUSH_CVAL_P2 i j PUSH_CVAL_N1 i PUSH_CVAL_N2 i j
Along the similar lines, if someone who has already worked and knows the semantics of other G-codes can explain it, it'll save really lot of time and effort and will speed up the native code generation process. Some are self explanatory, but others will take looking into most of the runtime system sources (mainly mutator and related) to figure out their purpose (like TABLESWITCH, LOOKUPSWITCH etc..). It will help other implementors who would want to hook some of their contributions to nhc. Regards, -- Arunkumar S Jadhav, Masters Student, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk
Arunkumar S Jadhav
Along the similar lines, if someone who has already worked and knows the semantics of other G-codes can explain it, it'll save really lot of time and effort and will speed up the native code generation process. Some are self explanatory, but others will take looking into most of the runtime system sources (mainly mutator and related) to figure out their purpose
Yes. I assume you have already looked at http://haskell.org/nhc98/implementation-notes/index.html especially the introduction to the byte coding scheme.
(like TABLESWITCH, LOOKUPSWITCH etc..).
I think you should be able to work out most of the bytecodes just by inspecting the mutator (src/runtime/Kernel/mutator.c). Here is a basic summary of the two you specifically asked about: TABLESWITCH is followed by an aligned table of 16-bit relative jumps. The constructor from the value on the top of stack is used to index into the table. For instance, to distinguish Nothing and (Just a), you might have TABLESWITCH (04) (08), and if the TOS value is a Nothing, you jump 4 forward, but for a Just constructor, jump 8 forward. LOOKUPSWITCH i is similar to TABLESWITCH, except that the TOS is interpreted as a 16-bit Int, and each jump address is paired with a 16-bit Int key. The argument i says how big the table is, and the mutator searches linearly through the table comparing with keys until a match is found, then it selects that jump. Regards, Malcolm
On Wednesday 24 November 2004 22:10, Malcolm Wallace wrote: [.....] Thanks a lot for patiently explaining the details. I'll keep posting my progress and ofcourse any related queries :). Regards, -- Arunkumar S Jadhav, Masters Student, KReSIT, IIT-Bombay, India Ph: +91-22-25764967 http://www.it.iitb.ac.in/~arunk
participants (2)
-
Arunkumar S Jadhav -
Malcolm Wallace