On Sat, 2002-05-04 at 01:52, Melvin Smith wrote:
> Reposted to the list so people can comment.
>
> As per the IRC discussion with Dan.....
>
> I've made some progress, not all there, but getting there.
> I have the loader handling arbitrary byteordering, now I'm
> working on wordsize transforms.
Since I missed the discussion, I count three size situations.
- n bit reading n bit bytecode. A straight read.
- 32 bit reading 64 bit bytecode. But 64 bit bytecode is simply 32 bits
padded out, so simply read every n+1 words.
- 64 bit reading 32 bit bytecode. Read and extend.
Is that along the lines of what you were thinking of?
>
> The good thing here is I'm documenting the code as I go, so
> hopefully afterward, everyone will easily be able to understand
> the bytecode format.
>
> I decided to store the byteorder as a 8byte matrix separate
> from the PARROT_MAGIC value. The reason is, its way easier
> to store the byteorder as a 0based transform matrix and just
> read it in, verify the elements, and use it, rather than ugly
> code to detect the byteorder based on the MAGIC. Also, MAGIC
> is 32bits, and I don't want to make a design decision that says
> we predict 64bit byteorder based on a 32bit value (the 64bit
> platforms I know either do big or little endian, but there is no
> reason to limit it).
>
> So what I do is read in the byteorder matrix, transform it with
> the native matrix, and use that to transform bytecodes
> in the rest of the file. The routine works 80% as fast a hardcoded
> routines with #ifdefs, however the advantage is we can support
> any byteorder/wordsize that an assembler can write.
Is native optimized away, or do you suffer a penatly doing a null
transform?
>
> Here is the format so far, I'm going to work on the segment
> headers and symbol table next.
>
>
> struct PackFile_Header {
I'd suggest adding:
char prefix[4] = { 0xCC, 0x0D, 0x0A, 0x1A };
>
> PS:
> Dan brought up an interesting idea of the opcode_type, where we store
> the flavor of the opcode, whether it is Perl, or transformed opcodes from
> another VM (Java, Python, .NET). Might make for some interesting discussion,
> especially given Leon Brocard's JVM experimentation.
The PBC metadata should indicate the source language and compiler, for
sure.
--
Bryan C. Warnock
bwarnock@(gtemail.net|capita.com)
