At 07:45 PM 9/10/2001 -0500, Brian Wheeler wrote:
>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?
Right. But don't forget, I screwed up the eq op--it ought to have a single
destination. :)
>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?
Each opcode number has a single function, yes. The same "high-level"
opcode, for example eq or add, might map to two or more different 'real'
opcodes based on the types of the args. There won't be any runtime
morphing--it's more "The assembler sees the first arg of foo as a numberic
register and the second as a constant, so it must be foo_n_nc".
>A thought (though gross): if we restrict mneumonics to not use the
>underscore,
>then anything after _ can be the op signature.
Too gross. We don't need to go there. :)
>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'
The jump ops will be easy to figure--either they'll take a register, a
constant number, or a label. We don't allow labels that could be confused
with registers. (No I0: anywhere...)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
