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]
