If memory serves me right, Paolo Molaro wrote:
> > You're insane. :)
Why does this sentence keep popping up whenever anyone discusses modding
gcc :)
> > registers, and register starvation's one of the more annoying things
> > a compiler has to deal with.
imcc !
But this is what Dan had to say about compiling C to Parrot
(conversation dated: 2002-10-19)
[11:31] <rhysw> Dan: to go off on a different tangent now - C support
[11:31] <rhysw> Dan: compiling C to Parrot, that is
[11:31] <Dan> Ah, that. Yeah, definitely doable. It'll be rather slow, though
[11:31] <Dan> Our function call overhead's rather large compared to what C needs
[11:32] <Dan> Still, I find the thought of C with native continuations
rather interesting. Scary, but interesting
[11:32] <rhysw> Dan: I was more thinking of the memory layout issues.
C code is very particular about struct layout, array
representation, etc. I didn't see any opcodes that
would allow one to do "pull an int32 out of offset N
from this pointer".
[11:33] <Dan> C's not at all particular about struct layout, unless they
changed the standard.
[11:33] <Dan> Still, you can do them either with struct PMCs, whcih'd be
slowish, or with the pack/unpack opcodes, which I bet are
insufficiently documetned
[11:35] <Dan> Still, the packed structures need more thoght. Hrm.
[11:35] <rhysw> Dan: I suppose a better question would be "is supporting
C a goal, or would it just be a cool hack but
otherwise uninteresting?"
[11:36] <rhysw> because, as you say, it wouldn't be terribly efficient ...
[11:36] <Dan> Neither, really. It's interesting in the sense that it'd let
people use code that they otherwise couldn't, if they don't
have a C compiler for.
[11:36] <Dan> But it's definitely not a primary goal
[11:36] <Dan> Consider it both mildly interesting and mildly bemusing :)
So ... the verdict then was "mildly interesting" ... and the partly done
pm_codegen.tc is still commented out ... is there any change now ?
> There is already a (limited) gcc backend that targets the CLR that
> sets up an area of memory for that use, but, as you can guess, it's not
> vey nice.
Currently I can dump stack opcodes (like the CLR) using a triple var
(or rather temporaries) code generator off AST .. and directly translate
stack opcodes to Parrot without any of the "stack++" crap .. almost
making half the JIT-time operations during compile time .
I've used that idea to build a small mathematical expression compiler
which dumps IL or Parrot (and acme did the perl5 codegen)...
> I think a gcc port would require parrot to provide at least a stack
> memory area and a register (sp) that points to it.
No, actually I think the gcc backend could lighten up on the register
allocation and just add new temporaries as needed ... also there are
no special registers for parrot which makes it a bit easier too ..
All I can say is that PMCs might be underutilized in this model.
> There may be other issues with the parrot instruction set, but since
> you have already hundreds (or thousands?) of opcodes, I guess it
> wouldn't be an issue to add a few more if needed:-)
I object ... no special registers or stack areas please ..
Gopal
--
The difference between insanity and genius is measured by success
