Re: [RFA] SH4A contribution for sim

[Joern Rennecke <renneckej at superh dot com>]

> 
> Michael Snyder wrote:
> > Here are my changes to support simulation of the sh4a.
> 
> J"oern?  Any comment?

> >   	  {
> >   	    int m, mv;
> >   
> > + 	    /* J"orn Rennecke: "Allow variable length n / m fields".
> > + 	       I'm not sure if I understand these two lines.  MVS */
> >   	    if (s[1] - '0' > 1U || !s[2] || ! s[3])
> >   	      expand_opcode (shift - 1, val + s[0] - '0', i, s + 1);
> > + 

The code above handles a single binary digit if it appears as
one of the last three characters, or in front of a non-binary character
(e.g. the 'i' in 'i8*1....').  This is because handling the three 'n's in
'nnn0' leaves one extra binary digit.  E.g. for fsca, after 'nnn', the
nibbles 0111 and 1110 are processed, leaving '1'.

I didn't want to process single bits all the time because that requires
some changes in patterns that recognize binary/letter combinations.

On the other hand, you seem to be doing that right now anyway.  And
expanding these combinations is making this code ever harder to maintain.
I think the only sane way forward is to handle variable-length binary fields
- i.e. make a loop to see how much we got and build up the number as we go.
The position dependent template fragments where the 'xx' and 'yy' for
movx/movy, which you changed to 'xy' and 'yx'.
We can use this chage to xy/yx to make the detection position-independent,
or check the shift parameter.  rather, that should be a count
of bits that remain to be processed - subtracting 4 at the start doesn't
make much sense if you don't process nibbles all the time.

> > + 	    /* 01xy -- 4 way fork across xy.  */
> > + 	    else if (s[2] == 'x' && s[3] == 'y')
> > + 	      for (j = 0; j < 4; j++)
> > + 		expand_opcode (shift - 4, val | m | (j << shift), i, s + 4);
> > + 	    /* 01xx -- 2x32 fork across x0 and nopy.  */

This does not just go across nopy (that would be pointless), but across
nopy and movy.
By replacing all the 'xx' in movx templates with 'xy' and doing a vanilla
expansion for 'xy' above, you disable generation of case labels for
movx/movy combinations.  Then you made tons of other changes to compensate
for this.  I see not point in these changes.

> > + 	case 'd':
> > + 	  /* Double register dr0-dr14 (even numbers only).  */
> > + 	  /* ddd0 -- 8 way fork.  */
> > + 	  val |= bton (s) << shift;
> > + 	  for (j = 0; j < 15; j += 2)
> > + 	    expand_opcode (shift - 4, val | (j << shift), i, s + 4);
> > + 	  break;

What is that for?  I don't see why we should have a separate ddd0 pattern,
where nnn0 works just fine and also makes it much clearer where the number
ends up.  It's also more efficient when the simulator doesn't do any
unnecessary runtime checks on the opcodes.  The even-numbered registers
generate legal instruction encodings.  The odd-numbered ones are left
over for the default case.  If you want to make sure that they raise a
SIGILL exception, you can do this by initializing table accordingly.