[RFA] SH4A contribution for sim

[Michael Snyder]

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.