This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] sh-sim: thislock/prevlock tweak
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: msnyder at redhat dot com (Michael Snyder)
- Cc: amylaar at fairadsl dot co dot uk (Joern Rennecke), joern dot rennecke at superh dot com, gdb-patches at sources dot redhat dot com
- Date: Fri, 6 Feb 2004 12:38:32 +0000 (GMT)
- Subject: Re: [RFA] sh-sim: thislock/prevlock tweak
> 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.