Dan --
> >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.
>
> We guarantee integer constants that are no bigger than 32 bits can be
> embedded in the opcode stream. Since opcode_t is at least 32 bits this is OK.
So, do we use opcode_t as the extraction type from the stream and then
cast to an IV? Also, if someone wants an IV constant bigger than 32 bits
and their IVs are bigger than 32 bits, then we will find ourselves in
need of two set_i_ic variants: immediate and indirect. The IV constants
needing no more than 32 bits use the immediate mode, and the others
use the indirect (to const_table) mode.
I suppose instead of thinking of it like an addressing mode, we could
think of it this way:
set_i_ic (get it from const_table)
set_i_oc (get it from the bytecode stream, o = operand)
And then the assembler has to decide which variant to to use when
presented with
set I[0-9]+, [0-9]+
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
\_____________________________________________________________________/
