At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote:
>First off, here's an inconsistancy I found: In test.pasm
>
>REDO: eq_i_ic I2, I4, DONE, NEXT
>
>appears. Shouldn't this be comparing to a constant, not a register?
Nope, though if I let you in on the actual secret it's help.
That should really be eq_i_ic_ic. (Well, actually there should be only one
label, and we fall through otherwise. It's a bug in implementation and
assembly, not opcode name... :) The intention is the last _x covers the
last arg, the next to last covers the next to last arg, and so on. When we
run out, we repeat the innermost type.
The ultimate intention is that you'd write that as a plain:
eq I2, I4, DONE, NEXT
or probably
eq I2, I4, DONE
and either way the assembler would know DONE was a constant and we needed i
registers since that was specified, and emit the eq_i_ic opcode.
>It
>became a little obvious when I made a few changes to the
>assembler/disassembler to give more details about the data (and to allow
>shortcuts like "add I1,I2,I3" to go to "add_i I1,I2,I3", etc)
>The opcode_table patch changes the argument encoding to use these terms:
># i Integer constant
># I Integer register
># n Numeric constant
># N Numeric register
># s String constant?
># S String register
># D Destination
I was using a trailing c to note a constant since we're using the opcode
name as a C function name, and we're not counting on case-sensitivity in
symbols.
Other than that (well, and Simon has a patch in to the repository to yank
out the opcode numbers entirely from opcode_table) it looks keen.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
