Melvin Smith <[EMAIL PROTECTED]> wrote:

> 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.

1) opcode_t is the size of opcodes, but has to hold pointers too, for
   prederef and such. I'd name it the natural wordsize.

2) INTVAL is a VM register category holding some integers, which the VM
   can work with -- as is FLOATVAL.
   Your conlusion above is just reverse. The whole machinery relies on
   the fact that we can say sizeof(opcode_t) == sizeof(void *).
   sizeof(INTVAL) is AFAIK not related to that in any way.

3) If there is such a configure option, and it doesn't work its a
   mistake.

> 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.

The concept of having INTVAL constants inside the opcodes is
wrong from a general POV. Please have a look at e.g jit/arm/ what
immediate constants are requiring as work arounds.

> 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.

which is, Parrot core types, their usage and the concept needs some
rework, when it comes to make 64bit INTVALs work on 32-bit CPUs.

IIRC: "Make mine SuperSized" by the well known and ever forgotten
Bryan C. Warnock and the discussion following!!!1 was quite informative.

> lt I0, <MAXINT CONSTANT>, LOOP

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

Yep, thats the summary of the problem. INTVAL constants are not portable
as FLOTAVAL constants aren't --if the are inline

> 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.

How do you communicate the long-long-long intval constants to the PMC?

> -Melvin

leo

Reply via email to