Front page | perl.perl6.internals |
Postings from September 2001
RE: Sizes, again.
From: Gibbs Tanton - tgibbs
September 30, 2001 10:07
RE: Sizes, again.
Message ID: ABEE81BE08ADD311B6A1009027DE908D09E958A6@conmsx03.conway.acxiom.com
I would assume that you would want to embed IV constants if at all possible
because of a locality of reference cache bonus. Even if the opcode_t is 32
bit and IV is 64 bit, it should still be possible to embed the constants
into the stream. As for having smaller opcode_t values, I think the argument
was that most systems can handle 32 bit values faster than they can handle
smaller sized values. I have to agree with this point. Although we do lose
some space in the cache because we are using larger values, the penalty is
more than offset by the fact that most processors are optimized to handle 32
or 64 bit integers.
From: Bryan C. Warnock
To: Gregor N. Purdy
Sent: 9/30/2001 10:28 AM
Subject: Re: Sizes, again.
On Sunday 30 September 2001 11:14 am, Gregor N. Purdy wrote:
> The stuff I'm about to check in that allows NVs to move to the
> table is set up to also allow IVs to live there, too. I haven't made
> the assembler and the ops do that yet, but it is possible. I thought
> were going to have sizeof(IV) == sizeof(OP), and handle larger
> via PMCs. But if we are going to have the possiblity that sizeof(IV)
> sizeof(OP), then we probably do need to move IV constants out of the
> bytecode stream.
Well, we recently went to all the trouble to decouple opcodes from IVs -
assume for a reason. Do we want to undo that, or move them into the
If you re-couple the sizes, then you're pretty much committing to 64-bit
opcodes, since you'll invariably want 64-bit IVs on platforms that
But I'm also seeing problems stemming from difference in size with IVs
pointers. (Although nothing critical, yet. Just need to watch what
> Heck, for really compact stuff, we could use a type so that sizeof(OP)
> == 2 instead of 4. That still gives us 16 bit opcodes, 16 bits worth
> of constant indexes, and 11 more bits than we need for register
> If we knew we were going to have no more than 256 active ops in a
> program, and no more than 256 constants, we could even use an 8-bit
> type for opcode_t. At least then we'd only be wasting three bits per
> register operand...
As long as we're going to allow the builder to specify the opcode size,
we're going to need to test this. However, if sizeof(opcode) ==
sizeof(opcode arg), that only allows you an 8 bit argument, which isn't
very big offset into a constant table.
Bryan C. Warnock