At 12:43 PM 10/4/2001 -0400, Bryan C. Warnock wrote:
>Within t/, I count 42 instances of an integer constant being used as
>something other than a jump or branch offset.
Fair enough, but they're not going to be representative of the ultimate
usage patterns, so I don't know that it's a good idea to draw too many
conclusions from them.
>So let's just work this out, shall we?
>
>* A parrot bytecode entity. (Each distinct item of an optree - the opcodes
>and its arguments).
>
>Constant size throughout the bytecode.
Yes.
>Is it a fixed size across all platforms? We've been saying 32 bits. What
>about platforms that don't have a native 32 bit entity (both larger and
>smaller - Crays and embedded)
No.
>Is there a minimum size? Absolute or relative. (Absolute, like 16 bit, or
>relative, like size of the opcode)
Minimum 32 bits. Things in the bytecode stream will always fit in a 32-bit
integer. The bytecode type may be larger than 32 bits if that's more
efficient on the platform.
>Is there a maximum size? Absolute or relative.
No and N/A.
>Byte-order and bit-order. Native or standardized.
Native.
>* A parrot opcode.
>
>Most of the same questions as above. We'll talk about the actual opcode
>numbers separately.
>
>* Opcode interval constants (how far between opcodes, for jumping and
>branching)
>
>Fixed to size of a bytecode entity.
Yes.
>Signed.
Yes.
>A minimum size would affect the sizes above.
Yup. Minimum 32-bit signed.
>What happens if a jump interval is larger than the type that contains it?
That's a relative jump in excess of 2G. In that case the compiler would
need to insert intermediate branch instructions every 2G, more or less.
>* Integer constants
>
>Signed.
Yup.
>Minimum size? (Size of bytecode or opcode, most likely. But again, what
>about platforms where that may not be a native type.)
32 bits.
>Maximum size?
32 bits.
>What do we do if an integer constant fits inside a bytecode entity?
We put it there.
>What do we do if an integer constant doesn't fit inside a bytecody entity,
>but fits inside an integer entity?
We put it in the constant table and access it via a PMC.
>What do we do if an integer constant doesn't fit inside an integer entity?
Pitch a fatal error on loading the bytecode.
>* Numeric constants
>
>Signed.
Yup.
>What do we do if a numerical constant fits inside a bytecode entity? (a 32
>bit floating point type).
Put it in the constant table anyway.
>What do we do if a numerical constant doesn't fit inside a bytecody entity,
>but fits inside a numerical entity?
Put it in the constant table.
>What do we do if a numerical constant doesn't fit inside a numerical entity?
Pitch a fatal error.
>Native or standardized?
Native.
>* Constant table offsets
>
>Unsigned.
Yup.
>What happens if (shudder) we have have an offset greater than the type that
>can represent it?
We have more than 4 billion constants. I fall over unconcious in utter
surprise. Then we probably need to break the bytecode section into pieces
such that each piece has only 4G or fewer constants.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
