gmane.comp.lang.smalltalk.fonc

jolt3 [was: Porting CodeGenerator vs VPU]

Michael FIG — 2008-07-23T05:33:38

Hi, Ian Piumarta public.gmane.org> writes: I think this is one of the more exciting things happening in jolt3! After staring at function/jolt3, I think I finally am grasping some of the design you are working on. Here are some notes that I've made to help other people understand, as well as to raise some questions I have: * "%" signs introduce end-of-line comments * The first line of a grammar is an object declaration. Since productions become methods on an object, grammars can inherit from other grammars and thereby extend or override the parent's productions. * Grammars that don't inherit from other grammars should inherit from Parser, which provides the infrastructure used by the generated .st file. * The "start" production/method is called by Parser>>parse:, so it's the default production. * "" matches a production against the current token stream, and saves its results back into the front of the input stream for further rules to

build error on windows (idst 501)

Takashi Yamamiya — 2008-07-20T22:14:36

Hi It looks like current source code (revision 501) can not be built on Windows because object/boot/src/libid.c is obsolete. It works good if I copied from object/id/libid.c to object/boot/src/libid.c. The error message was: make[1]: Entering directory `/c/takashi/src/idst.501/object/boot' gcc -Iinclude -DPREFIX='"/usr/local/lib/idc/i686-pc-mingw32/"' -g -Wall -Wreturn-type -Werror -mno-cygwin -DNDEBUG -DSYSARCH=\"i386\" -DSYSOS=\"win32\" -O3 -march=prescott -fomit-frame-pointer -falign-functions=16 -funroll-loops -fno-strict-aliasing -c src/libid.c -o libid.o src/libid.c:83: error: conflicting types for '_argc' c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h:71: error: previous declaration of '_argc' was here src/libid.c:83: error: conflicting types for '_argc' c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h:71: error: previous declaration of '_argc' was here make[1]: *** [libid.o] Error 1 make[1]: Leaving directory `/c/takashi/src/idst.501/object/boot' make: [boo

Re: Porting CodeGenerator vs VPU

Ryan Davis — 2008-07-19T04:07:41

On Jul 17, 2008, at 18:23 , Ian Piumarta wrote: Ian, Have I mentioned lately that I love you? *kisses*, Ryan

non local return

John Leuner — 2008-07-18T13:20:35

While I was implementing the 'loop' construct for my experimental language (see these blog posts http://subvert-the-dominant-paradigm.net/blog/?p=28 http://subvert-the-dominant-paradigm.net/blog/?p=29 ) I realised that I had to implement non local return functionality. At first I thought that I could just grab the frame pointer at runtime and pop off as many stack frames as needed, resuming at the target frame. Unfortunately this is not possible because the calling convention requires that the 'callee saved registers' (ebx, esi and edi on x86) be restored by the callees before they return. So what I did was to modify the code generation process so that after generating code for a function, it generated an extra "cleanup" sequence which restored these callee saved registers and popped the stack frame. The cleanup pseudo-instruction: (:void (:cleanup-and-jump) ,#'(lambda (op cg) (emit-epilogue cg) (jmp-reg cg (edx cg)))

Re: Porting CodeGenerator vs VPU

Ian Piumarta — 2008-07-18T01:23:18

There seems to be some confusion (probably mostly in my head)... On Jul 17, 2008, at 4:48 PM, Ryan Davis wrote: The VPU presented the end user with a stack abstraction that compiles into register-based instructions (as is the CodeGenerator, except that its stack is implicit in the 'imaginary call graph' of the s- expressions you feed to it). Nothing whatsoever remains of the VPU's stack in the final generated code. It did just as much register allocation as the CodeGenerator does. Neither the VPU nor the CodeGenerator presents the client with a register-based model, and both of them target register-register instruction sets. Decent register allocation is one of the trickiest parts of code generation (especially for asymmetrical, irregular architectures like the 386) which is why both the VPU and the CodeGenerator (try their best to :) take care of it for their client programmers. The VPU had a generic 'user-defined instruction' that could be parameterised to generate any desired

Re: Porting CodeGenerator vs VPU

Ryan Davis — 2008-07-17T23:48:45

On Jul 16, 2008, at 14:19 , Igor Stasenko wrote: I'm torn. That sounds lovely, but I'd also like to experiment with going towards a register based machine, rather than stack. But really... the machine code generator side is my weak point, so I should be doing all of them as many times as I can.

Re: Porting CodeGenerator vs VPU

Ryan Davis — 2008-07-17T21:31:46

On Jul 16, 2008, at 13:50 , Ian Piumarta wrote: VPU sounds nice and simple... I'm taking a whack at porting it now and by using more metaprogramming am getting roughly a 2:1 compression ratio out of the code. I think other areas (like not having your {} form vs the regular []) will make that up soon. Actually I find the AST approach ideal. 1) I have a lot of tools to deal with that already and can merge with many of my tools (I wrote ParseTree and SexpProcessor for ruby) and projects (I work on rubinius, which is AST-to-bytecode currently). Yeah... but the AST approach means you can quickly and easily slip another layer in there without having to touch any other code. I think I want to go with a billion thin layers to allow for easier experimentation. I assume that VPU has similar problems in it's generated code?

Re: Porting CodeGenerator vs VPU

Ryan Davis — 2008-07-17T21:26:18

On Jul 16, 2008, at 01:47 , John Leuner wrote: I'm not sure I care at this stage (just experimenting) but... I don't see a libvpu.a... am I missing something? Nowhere in any of the source or makefiles is libvpu or lvpu. Clue me? I'm porting to ruby.

Re: Porting CodeGenerator vs VPU

Igor Stasenko — 2008-07-16T21:19:50

2008/7/16 Ian Piumarta public.gmane.org>: VPU is much better approach for code translation. No dependency from C. Direct access to low-level operations with memory and stack, and even with additional coding - to different hardware features.

Re: Porting CodeGenerator vs VPU

Ian Piumarta — 2008-07-16T20:54:32

Oops... On Jul 16, 2008, at 1:50 PM, Ian Piumarta wrote: [1] http://www.usenix.org/events/vm04/tech/piumarta.html Sorry, Ian

Re: Porting CodeGenerator vs VPU

Ian Piumarta — 2008-07-16T20:50:32

Ryan, The VPU model is nice because it requires a minimum amount of state (just one object) to be maintained in the client. No clumsy data structures to construct and manipulate. You can write, compile and run a VPU-based program that adds 3 to 4 to make 7 in less than a minute. To do the same with the CodeGenerator means, at the very minimul, you can construct ASTs and agree with the CodeGenerator on how they are represented. The reason the VPU was abandoned in the CodeGenerator is that the very first thing the VPU does with the 'program' that you feed it (in the form of function calls, terminating in 'compile()') is to translate that program into something that looks just like an AST (see [1] for details). Rather than have Jolt take an AST, linearise it into a sequence of VPU function calls, then reconstruct an almost identical AST in the VPU, I figured I'd cut out the step in the middle and just translate Jolt s-expressions down into (effectively) the AST the the VPU wou

Re: Porting CodeGenerator vs VPU

John Leuner — 2008-07-16T08:47:59

The libvpu.a used by the VPU target is not open source. The BURG target does register allocation and should produce more efficient code. What language are you porting to? I have done a port to Common Lisp. John On Mon, 2008-07-14 at 13:45 -0700, Ryan Davis wrote:

Porting CodeGenerator vs VPU

Ryan Davis — 2008-07-14T20:45:52

Are there any notable pro's / con's to porting CodeGenerator vs VPU to a different language? I'm just looking to experiment at this stage, so I don't need the most advanced thing in the world, but if there is a compelling reason, I'll do the bigger porting job.

Re: Compiling on Solaris

Roel Messiant — 2008-07-01T17:14:36

Re: Compiling on Solaris

2008-07-01T15:54:28

Quoting Roel Messiant public.gmane.org>: Seems like the "cc" command of your system is not gcc. What is the value (if any) of the environment variable $CC before you configure and compile? Maybe you should clear it and then try again. My 0.2 euros. Cedric.

Compiling on Solaris

Roel Messiant — 2008-07-01T15:38:54

Re: FONC on Ubuntu

Rob Grainger — 2008-06-29T03:01:15

Re: FONC on Ubuntu

Takashi Yamamiya — 2008-06-29T01:44:05

Sometimes this kind of error happens when I update my local copy. I would be good to try checking out on a new directory. - Takashi On Sat, Jun 28, 2008 at 5:55 PM, Craig Overend public.gmane.org> wrote:

Re: FONC on Ubuntu

Craig Overend — 2008-06-29T00:55:44

Re: FONC on Ubuntu

Takashi Yamamiya — 2008-06-28T17:01:51

I use rlwrap often with Rhino. It works O.K. I think using rlwrap is better than bothering you unessential issue. Cheers, - Takashi Ian Piumarta wrote:

Re: FONC on Ubuntu

Ian Piumarta — 2008-06-28T05:28:47

Sorry, my mistake. I thought I'd seen it in Linux man pages. I don't see how that one would be any better, since getline() is specific to GNU libc. There is already a replacement fgetln for win32 that only assumes fgetc, so I just renamed it and enabled its use everywhere to remove dependencies on fgetln. HTH. This whole thing would be moot if built-in command-line editing wasn't so useful. Yoshiki recently pointed me to rlwrap which would certainly simplify the situation, at least for systems that support it. Does anyone have experience with and/or strong opinions about rlwrap? Cheers, Ian