Ryan,
Are there any notable pro's / con's to porting CodeGenerator vs VPU
to a different language?
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 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.
If you look at
'(RETI4 (ADDI4 (CNSTI4 3) (CNSTI 4)))
and
vpu->LdI4(3)
->LdI4(4)
->AddI4()
->RetI4();
you can see pretty quickly how one representation can be translated
trivially into the other. I think whichever you decide to
investigate further, you'll rapidly end up solving identical problems.
It has always been my intention to (eventually) create a standalone
CodeGenerator back-end library that provides a VPU-like interface.
This would be a very thin wrapper, just enough to reconstruct the AST
from the sequence of VPU function calls.
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.
Cheers,
Ian
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
