On Jul 16, 2008, at 13:50 , Ian Piumarta wrote:
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.
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.
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 would have constructed. The internal processes
that convert the low-level AST into binary code in the VPU and the
CodeGenerator are actually very similar in spirit, but somewhat more
elegant in the CodeGenerator.
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).
If you look at
'(RETI4 (ADDI4 (CNSTI4 3) (CNSTI 4)))
and
vpu->LdI4(3)
->LdI4(4)
->AddI4()
->RetI4();
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'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.
The CodeGenerator is weak in a number of places and is due for a
total rewrite. The handling of automatic variables is poor, and the
code generated for control structures is abysmal. I've been
experimenting with a kind of 'lightweight continuation-passing'
style of code generation that I think I might adopt in Jolt3 (this
approach is particularly good at generating optimal control
structures with very little effort/complexity). Jolt3 will also use
a single framework for top-down parsing of source, intermeditate AST-
to-AST analysis/transformation/optimisation, and bottom-up tree
rewriting for concrete instruction selection.
I assume that VPU has similar problems in it's generated code?
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
