>
> 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.
BUT, I'm more confused now :)
If eq_i_ic is really treated as /eq(_i)+_ic/ then this code still
doesn't work:
eq_i_ic I1,I2,NEXT,DONE
because that'd be like eq_i_i_ic_ic, right?
I assume that opcodes aren't going to have variable arguments at this level,
so there should be a one-to-one mapping between function and opcode, right?
A thought (though gross): if we restrict mneumonics to not use the underscore,
then anything after _ can be the op signature.
The opcode_table could use these characters for different data types:
integer i
integer constant j
numeric n
numeric constant o
address a
string s
string constant t
The file could be reorganized as:
set 2 i j
set 2 i i
set 2 n o
set 2 s t
The perl scripts which create the interfaces (process_opfunc.pl, etc) could
use this information to create 4 opcodes:
set_ij
set_ii
set_no
set_st
When the assembler comes across 'set I1,I2', It knows the set_ii form is
the one to use. The disassembler can dump it as 'set_ii I1,I2' or
(I suppose) as 'set I1,I2'
Also, doing it this way takes out the special cases for the comparison and
jump ops: the fixups are known to be done with things that have type 'a'
>
> >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.
>
fair enough...
> 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.
>
I'll take a peek and see what all depends on the opcode_table file...
Brian
> Dan
>
> --------------------------------------"it's like this"-------------------
> Dan Sugalski even samurai
> [EMAIL PROTECTED] have teddy bears and even
> teddy bears get drunk
>
