Bryan --
> > 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?
You are probably right. My mental model of bytecode == stream of IVs is
probably just out of date. So, here's the followup question:
Given that typeof(IV) != typeof(opcode_t), does typeof(opcode_t) ==
typeof(operand_t) or not?
Even if opcodes aren't IVs, I still think we are supposed to have the
bytecode be a stream of uniform-sized chunks, which implies that the
type of operands is the same as the type of opcodes.
> 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.
Yeah, and the assembler is going to have to barf if you target a config
with fewer constant slots or opcodes than you need. And, such a small
config could not be expected to run real-world programs from a larger
config. So, I don't how small we want to let the configs get. Perhaps
we need to set a lower bound? Perhaps that is already set at 32 bits for
opcodes and operands, and should be left alone...
Regards,
-- Gregor
_____________________________________________________________________
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_____________________________________________________________________/
