On Sat, Jan 11, 2003 at 10:12:42AM +0530, Gopal V wrote: > If memory serves me right, Chris Dutton wrote: > > Actually, if you really want Eiffel to compile to Parrot, it might be > > interesting to work on getting ANSI C to compile to Parrot first, since > > most Eiffel compilers use compilation to C as an intermediate step.
> [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 Probably this has all been worked out by now, but Rhys and Dan are coming at it from different angles. C isn't fussy, but the ABI for a platform is very fussy. I presume Rhys is thinking about compiling C code to parrot, and then linking through to native C code (such as the native standard C library) via parrot. Dan's assuming that C code we compile never wants to call out to the platform. If I remember the terms correctly, Dan's thinking about free standing C implementations. Effectively that would give Inline::C without needing a C compiler, but you'd not be able to call out from your C code. What Rhys is thinking about is potentially far more interesting, as it would allow the perl6 version of Inline::C to wrap external libraries supplied only as objects and headers, without needing a C compiler on the machine. It's also harder, partly because such a system would need to know the ABI for each platform you wanted to do this on. But if anyone has tuits, could we have a z-code interpreter first please? Or better still, a unified, fast, assembler? (with a pony?) Nicholas Clark
