Re: [RFA] SH4A contribution for sim

[Michael Snyder <msnyder at redhat dot com>]

Joern Rennecke wrote:
> > 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'.

Ah, thanks, I see.  So you're basically solving the same problem here
that I did by introducing the "ddd0" pattern.

Wouldn't it be safer to handle the extra '0' immediately?
What if you had a pattern that was like "nnn0GGGG", (for instance)?
You'd wind up parsing it as "nnn" plus "0GGG" plus "G".


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

Yeah, that could be ugly.

> On the other hand, you seem to be doing that right now anyway. 

Processing single bits?  Not that I'm aware....

> 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'.

As a less extreme measure, what if we break some combinations
into two-byte fields instead of four?  I'm still thinking it
through, but I'm thinking that, for instance, "01NN" could be
handled in two passes: take the "01" first, then recurse and
let the "NN" be handled in the outer switch statement.  This
might also apply to 01xy and XY01.

> 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.

Please say more.  I found this part of the work difficult,
and I'm by no means sure that my solution was optimal.
Unfortunately I did the work several months ago, and my
memory is not fresh (appologies for not getting around to
submitting it sooner).


> > > + 	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.

OK, but there's precident -- MMMM, ssss, and GGGG all stand for
specific subsets of register numbers.  I'm willing to go with your
way, but consider that if we do use ddd0, then the problem of
handling a single nybble goes away.  The nnnn / mmmm code becomes
simpler again.