On Thu, Sep 10, 2009 at 3:57 PM, Malcolm Wallace
Hi Fernan,
Aside from below code. I am also having problems compiling hc files with #define CT_v249 ((void*)startLabel+464)
By way of explanation, the idea of these symbols is that the bytecode sometimes needs to refer to an indexed position elsewhere in the bytecode. If the indexed position needs to be visible externally (to this module), it is declared like
unsigned F0_Prelude_46primLeave[] = {
but in the cases where it need only be visible internal to the module (e.g. a constant table (CT) associated with a function), we use an address calculation instead:
#define CT_v249 ((void*)startLabel+464)
In both cases, it is important that the bytecode be continuous, that is, in a sequence like
, bytes2word('u','p','l','e') }; unsigned PC_Prelude_4618[] = { bytes2word('P','r','e','l')
it is necessary that the bytes are really in the sequence
'u','p','l','e','P','r','e','l'
The symbol PC-Prelude_4618 refers to the middle of this sequence - it should not start a new section of memory, separated from the previous section.
It appears that it is trying to pointer addition with a void*. This is ok with gcc as a "non-standard extension", but it will not work with plan9.
So far I did this to make those section compile
1. changed userLabel define --#define userLabel(fun) ((unsigned)fun) ++#define userLabel(fun) ((unsigned*)fun)
2. removed void* pointer addition by writing a script from #define CT_v249 ((void*)startLabel+464) to #define CT_v249 ((unsigned char*)startLabel+464)
OK, that seems like a reasonable change - it should preserve the invariants I described above.
If you manage to get nhc98 bootstrapped on plan9, do please send your changes to me, so that I can incorporate them into the main nhc98 tree - then everyone else can benefit too.
Hi Malcolm Thank you for your explanation of the bytecode. I really havn't understand the nhc98comp operation yet. I am basically just running the c files through the plan9 compiler and fix what ever issues come up. I am still doing a lot of guessing here, but I a few more questions. 1. The hc files are generated by nhc98comp? I will still need to modify nhc98comp to always produce the unsigned char*? 2. I am also bypassing nhc98 script during the prelude build. I am created a separate script to compile prelude under plan9. The script just loads the hc files into the C compiler. 3. I am still guessing here, but If item 2 is an ok approach is it possible to simply compile src/runtime/Runtime.a and use the .o files from a unix build? thanks fernan -- http://www.fernski.com
1. The hc files are generated by nhc98comp? I will still need to modify nhc98comp to always produce the unsigned char*?
Yes, and yes. The latter will be easy - it should be a single line change in src/compiler98/EmitState.hs
2. I am also bypassing nhc98 script during the prelude build. I am created a separate script to compile prelude under plan9. The script just loads the hc files into the C compiler.
Might be reasonable. The main reason for using the nhc98 script is just to ensure that the right header files etc are visible.
3. I am still guessing here, but If item 2 is an ok approach is it possible to simply compile src/runtime/Runtime.a and use the .o files from a unix build?
Yes, that might well work, if the .o files are ABI-compatible across unix and plan9. Regards, Malcolm
On Thu, Sep 10, 2009 at 5:41 PM, Malcolm Wallace
1. The hc files are generated by nhc98comp? I will still need to modify nhc98comp to always produce the unsigned char*?
Yes, and yes. The latter will be easy - it should be a single line change in src/compiler98/EmitState.hs
2. I am also bypassing nhc98 script during the prelude build. I am created a separate script to compile prelude under plan9. The script just loads the hc files into the C compiler.
Might be reasonable. The main reason for using the nhc98 script is just to ensure that the right header files etc are visible.
3. I am still guessing here, but If item 2 is an ok approach is it possible to simply compile src/runtime/Runtime.a and use the .o files from a unix build?
Yes, that might well work, if the .o files are ABI-compatible across unix and plan9.
Hi Thanks for the help. I can now compile most of the hc files. As a test I also compiled cpphs. It compiles fine, but as I expected it crashes very early into the intialization. It seems segfaults somewhere in run(toplevel) Case(HEAP_CADR_P1): *hp++ = (Node)&constptr[ HEAPOFFSET(ip[0])]; ip+=1; Break; The ip appears to be bieng initialized by a wrong value, but I dont have any way of proving this yet. Is there some additional documentation in the boot steps of the G-machine? fernan -- http://www.fernski.com
participants (2)
-
Fernan Bolando -
Malcolm Wallace