At 12:13 PM 11/22/2003 +0000, you wrote:

Leo, I know this is a first cut at freeze/thaw, and I'm happy you've
done it. Let me make some comments to you and Dan.

I'm pretty sure Dan and I discussed this when I was reworking bytecode
to be portable last year, but I think at the time we decided there were other
things (like freezing PMCs) that needed to be done. Now that it is in, its
time to re-light this discussion until we get a document out of it. :)

A) I didn't look at your commit to see the reason for storing the INTVAL size
into the bytecode header, so I won't question it yet, but since p6i has argued
this for a couple of years, I want to restate some things.

Parrot currently assumes INTVAL size == OPCODE size because
both get configured as the same integral type, although you can choose
to override it, it is not supported to choose INTVAL > OPCODE, though
the inverse is. So storing it in the header is probably redundant, unless
we change the rules.

While we may have platforms that have void */size_t > than INT,
we should not have any where void */size_t < INT.

An int should always pack into 1 opcode_t, if it doesn't we have configured
wrong for INTVAL (someone chose a 64-bit type on a 32-bit platform),
and the fact that by configure, it is even possible, says we have the
typedef hierarchy wrong. I still feel that Parrot_Int should be dependant
on Parrot_Opcode.

B) For bytecodes to be portable we have to have some rules about
standard sizes. Yes, we can unpack a 64-bit bytecode on a 32-bit
CPU, but INTVAL constants (non-PMC) get truncated.

Since it is NEVER portable for someone to write code using the Ix
registers with values > than 32-bit, we have to make a rule. Any use
of integers > than 32-bit should use a PMC type, not an integral type.

The fact that:

set I0, 0
LOOP:
inc I0
lt I0, <MAXINT CONSTANT>, LOOP

Runs differently between platforms is enough reason to make
a least common denominator MAXINT the Parrot standard.

The summary of this:

Parrot must use a PMC Int type to store portable data, so the INTVAL
should be stored as part of the PMC stream, not the bytecode
header, as we may support multiple sizes.

-Melvin