[RFA] SH4A contribution for sim
Wed Dec 17 21:49:00 GMT 2003
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 - '0' > 1U || !s || ! s)
>>> expand_opcode (shift - 1, val + s - '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....
> 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 == 'x' && s == '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);
> 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
More information about the Gdb-patches