From fernanbolando at mailc.net Tue Sep 8 20:00:56 2009 From: fernanbolando at mailc.net (Fernan Bolando) Date: Tue Sep 8 19:39:57 2009 Subject: [nhc-users] porting nhc98 to plan9 Message-ID: <1d5d51400909081700l1239348bi57e060ce4d6c9a64@mail.gmail.com> Hi all I am trying to look into porting nhc98 to plan9. Plan9 has only two C compiler and it doesnt support all the C capability available in Unix due to the difficulty in emulating some areas of unix into plan9. So far getting some section of nhc98-1.20/src/runtime compiled works ok, but I had to a do some minor changes on the section of code below. The C preprocessor coudn't determine the value of the initializer for F0_Prelude_46primLeave[], giving the error "initializer is not a constant for F0_Prelude_46primLeave". I tried to hard code the value, but was not sure if my number is correct, so I wanted to get first hand information. --snippet from newmacros.h --- #define VAP_TAG 1 #define WORDSHIFT 5 #define WORDSIZE (1<>3) #define ZAP_BIT (1L<<(WORDSIZE-1)) #define CAPTAG(fun,need) useLabel(fun) - (NS + 2 + (2 * need)) + VAP_TAG #define useLabel(name) ((unsigned)name) ---- -- snippet from newbuiltin.c ---- unsigned F0_Prelude_46primLeave[] = { CAPTAG(FN_Prelude_46primLeave,1) #ifdef PROFILE , useLabel(PROF_primLeave) , 0 , 0 , 0 #endif -- regards fernan -- http://www.fernski.com From fernanbolando at mailc.net Thu Sep 10 04:38:23 2009 From: fernanbolando at mailc.net (Fernan Bolando) Date: Thu Sep 10 04:17:21 2009 Subject: [nhc-users] Re: porting nhc98 to plan9 In-Reply-To: <1CE48002-D9AD-415F-8DFE-692111F689F9@cs.york.ac.uk> References: <1d5d51400909081700l1239348bi57e060ce4d6c9a64@mail.gmail.com> <1d5d51400909091552j5851d353h6a8fda4205933cb9@mail.gmail.com> <1CE48002-D9AD-415F-8DFE-692111F689F9@cs.york.ac.uk> Message-ID: <1d5d51400909100138n731ab565q982b5aae23cf007f@mail.gmail.com> On Thu, Sep 10, 2009 at 3:57 PM, Malcolm Wallace wrote: > 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 From malcolm.wallace at cs.york.ac.uk Thu Sep 10 05:41:37 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Sep 10 05:20:35 2009 Subject: [nhc-users] Re: porting nhc98 to plan9 In-Reply-To: <1d5d51400909100138n731ab565q982b5aae23cf007f@mail.gmail.com> References: <1d5d51400909081700l1239348bi57e060ce4d6c9a64@mail.gmail.com> <1d5d51400909091552j5851d353h6a8fda4205933cb9@mail.gmail.com> <1CE48002-D9AD-415F-8DFE-692111F689F9@cs.york.ac.uk> <1d5d51400909100138n731ab565q982b5aae23cf007f@mail.gmail.com> Message-ID: <816CE830-D79B-4F95-BA29-2B9867E4F7E7@cs.york.ac.uk> > 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 From fernanbolando at mailc.net Sat Sep 12 06:19:34 2009 From: fernanbolando at mailc.net (Fernan Bolando) Date: Sat Sep 12 05:58:24 2009 Subject: [nhc-users] Re: porting nhc98 to plan9 In-Reply-To: <816CE830-D79B-4F95-BA29-2B9867E4F7E7@cs.york.ac.uk> References: <1d5d51400909081700l1239348bi57e060ce4d6c9a64@mail.gmail.com> <1d5d51400909091552j5851d353h6a8fda4205933cb9@mail.gmail.com> <1CE48002-D9AD-415F-8DFE-692111F689F9@cs.york.ac.uk> <1d5d51400909100138n731ab565q982b5aae23cf007f@mail.gmail.com> <816CE830-D79B-4F95-BA29-2B9867E4F7E7@cs.york.ac.uk> Message-ID: <1d5d51400909120319s14ebe420rdfce9d88b032dd23@mail.gmail.com> On Thu, Sep 10, 2009 at 5:41 PM, Malcolm Wallace wrote: >> 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