Hi Nicolas, Ok, I see... I guess then, should I opt to use NekoML to create a compiler, my first task would be to create something that could be executed by the NekoVM... On succeding with this, I could invariably modify my output bytecode language and build my own VM.
I guess, really, I don't want to fall into the trap of having a slightly modified version of Neko as 1. It won't be my own work and so will fall under Neko licensing and 2. I will have missed numerous lessons on the way. Still, I guess beginning with a modified version of the NekoML compiler will at least teach me something, though I will need to restart once I understand the basic concepts. I've started my journey so far by learning as much as possible about Backus-Naur Form and parser trees, as well as complete mini grammers and the like, though the actual construction of such grammers from scratch is still a little hazy at this point. Still, I now feel ready to tackle the actual parser / scanner construction. AntLR or Cocol/r had seemed the logical step, but again, I can't help feeling I may miss something along the way should I follow these routes. At least if I use Neko I can follow the compiler construction from beginning to end, then when the VM / execution cycle project begins, I'll at least have more skills to bring to the table. Thanks again for your advice, Lee -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolas Cannasse Sent: 07 March 2006 11:13 To: Neko intermediate language mailing list Subject: Re: [Neko] Compiler used for neko > Hi Nicolas, > > I must admit, I was impressed when I traversed the code for the NekoVm > and compiler, but numerous keywords stood out that made me feel you had > certainly used a parser generator before. If you had to use a parser > for compiler development, which one would be your preference? The NekoML one. It's inspired by CamlP4 stream parsers, which are an syntactical extension of OCaml. LL(1) parser don't need "generators" since you can directly express your grammar in terms of patterns. For exemple if you have a BNF : parent := '(' expr ')' you can encode it this way : function parent(s) { match s { | [< ParentOpen; e = expr s; ParentClose >] -> .... } } Where 's' is your token stream and 'ParentOpen' and 'ParentClose' are two tokens. Neko and NekoML lexer tokens are pairs of (token,position) so this make the parser a bit more verbose, such as : function parent(s) { match s { | [< (ParentOpen,p1); e = expr s; (ParentClose,p2) >] -> .... } } Then in '...' you can build the expression EParenthesis(e) with position delimiters p1 and p2, hence punion(p1,p2) > Also, I > can quite clearly see the path to building a compiler that executed the > code as it went along, but how did you go about planning the bytecode > structure for Neko? Did you use the same conventions when planning your > parsers from script -> bytecode and from bytecode -> execution? Neko comes from a previous VM called "MotionScript". Usually you first develop a small lexer+parser, then an toy interpreter that will just execute the AST (very slow !). When it comes to writing a VM, the goal is to have a linear representation of the AST with fewest opcodes possible, then add some opcodes for optimizing the things that you do often. I'm not sure I understand your question about "using the same conventions". Surely, the bytecode generator (written in NekoML) and the bytecode loader (written in C) must share the same format. As for bootstrapping, the compiler was first written in OCaml then rewritten in NekoML, since you can't self-boostrap a language. Nicolas -- Neko : One VM to run them all (http://nekovm.org) -- Neko : One VM to run them all (http://nekovm.org)
