Nicholas Clark <[EMAIL PROTECTED]> writes:
[...]
> > struct Chunk {
> > opcode_t type;
> > opcode_t version;
> > opcode_t size;
> > void data[];
> > };
will this ever compile?
void data[] is not allowed, and even char data[] is an incomplete
type, so its not allowed in a structure definition. A void * data
pointer seems more appropriate. This way its possible to have one
TableOfContent for the whole bytecode file and every chunk of the file
can be accessed in constant time (no need to scan over the complete
file to reach the last chunk)
> I agree with the "roughly" bit, but I'd suggest ensuring that you put
> in enough bits to get data[] 64 bit aligned. Mainly because at least 1
> architecture exists that has no 32 bit types (Crays I know about; others
> may exist. I can't remember if perl 5.8 passes 100% of tests on Crays.
> We certainly tried)
opcode_t will be 64 bit on this architectures.
[...]
> I'm thinking that register usage information from imcc could be of use
> to the JIT, as that would save it having to work out things again. So that
> probably needs a segment.
>
> Also some way of storing a cryptographic signature in the file, so that you
> could compile a parrot that automatically refuses to load code that isn't
> signed by you.
These ideas show clearly one thing:
The typecode must be extendible.
[...]
> > >It might be even possible to dump the jitted code. This would increase
> > >the startup. Then strip the bytecode to reduce the size of the file
> > >and TADA: Yet another new binary format.
> > When you then are able to to get the same memory layout for a newly
> > created interpreter, it might even run ;-)
>
> So the JITted code contains lots of hard references to address in running
> interpreter? It's not just dependent on that particular binary's
> layout?
And if there are two interpreters in the same process (isn't that the
supposed way of multiple threads) each one has to compile the same
code again?
> I guess in future once the normal JIT works, and we've got the pigs flying
> nicely then it would be possible to write a Not Just In Time compiler that
> saves out assembly code and relocation instructions.
>
> Bah. That's "parrot -o foo.o foo.pmc" isn't it?
And if we make C a parrot supported language we can even build parrot
with parrot?
bye
boe
--
Juergen Boemmels [EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
