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.
-----Original Message----- From: Bryan C. Warnock To: Gregor N. Purdy Cc: [EMAIL PROTECTED] 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 constant > 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 we > were going to have sizeof(IV) == sizeof(OP), and handle larger integers > 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 - I assume for a reason. Do we want to undo that, or move them into the constant table? 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 support it. But I'm also seeing problems stemming from difference in size with IVs and pointers. (Although nothing critical, yet. Just need to watch what we're doing.) > > 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 numbers. > > 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, then 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 a very big offset into a constant table. -- Bryan C. Warnock [EMAIL PROTECTED]
