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