There seems to be some confusion (probably mostly in my head)...
On Jul 17, 2008, at 4:48 PM, Ryan Davis wrote:
On Jul 16, 2008, at 14:19 , Igor Stasenko wrote:
2008/7/16 Ian Piumarta <[EMAIL PROTECTED]>:
the very first thing the VPU does with the 'program' that you
feed it is
to translate that program into something that looks just like an
AST (see
[1] for details).
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.
I'm torn. That sounds lovely, but I'd also like to experiment with
going towards a register based machine
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 sequence of concrete
instructions while taking part in register allocation, etc.; part of
the rationale for this approach was that C++ isn't particularly
conducive to extending class hierarchies with virtual functions in
arbitrary ways at runtime. The CodeGenerator is a little easier to
extend (in large part because it isn't written in C++) since new
types can be added under Instruction dynamically at run time and then
embedded into the AST entirely in end-user land, via (syntax ...),
and the internal workings are (IMHO) somewhat more transparent and
sometimes almost verging on 'table driven' in spirit (at least for
the instruction selection and instruction-specific register
allocation rules).
the machine code generator side is my weak point, so I should be
doing all of them as many times as I can.
It's also the part of a compiler that is traditionally ignored, or at
best treated superficially and rapidly, in compiler textbooks.
Cheers,
Ian
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
