Re: [RFA] sh-sim: thislock/prevlock tweak

[Joern Rennecke <joern.rennecke@superh.com>]

> Joern,
> 
> I don't fully understand this code, but it looks to me as if this
> minor change is needed.  Most other instructions appear to call
> the macro "L()" for the register that was explicitly the target
> of the instruction.

Looks sensible as far as I can see it; it would be helpful to have
enough context to see the full insn.
Note that L is part of the mechanism that approximates SH[123]
timing; SH4 timing is entirely different.  This makes a number of
the MA calls rather bizarre, where we simulate the timings of a
processor that doesn't implement the instructions in the first place.

In October I made a patch to implement SH4 timings (controlled by
an #ifdef SH4_TIMINGS), but it ended up a few percent slower than
the simulator before, so I thought we should really use a simulator
built with ACE_FAST for the c-torture simulator tests - even better if we can
make it processor specific, i.e. no DSP insns for non-dsp processors
and no FPU insns for non-fpu processors.  The mere presence of the
code seems to skew the memory layout and/or register allocation of the
'hot' code to make the simulator slower.  So that would require to
build separate binaries and a wrapper that invokes the right one,
or make dejagnu pick up a specifically tuned variant.
Then we had a lot of changes to the simulator for other functionality,
and I didn't have the time to make this into a current patch.
I'll forward a copy of my letter with the patch in case you or someone
else on the list want to pick it up.