On 06/05/11 08:33, Nathan Whitehorn wrote:
On 06/05/11 04:00, Alexander Graf wrote:
On 04.06.2011, at 21:28, Nathan Whitehorn wrote:
On 05/31/11 12:40, Richard Henderson wrote:
On 05/31/2011 07:56 AM, Nathan Whitehorn wrote:
#if defined(TARGET_PPC64)
- if (!ctx->sf_mode) {
TCGv t0 = tcg_temp_new();
TCGv t1 = tcg_temp_new();
You're removing a scope in which these variables were defined.
That seems wrong, at minimum.
I'll fix that (and resend the patch), thanks. A note on this: it
looks like a lot of code here incorrectly changes behavior depending
on the setting of MSR[SF]. While most of them aren't checking the
condition the wrong way, like here, MSR[SF] actually changes very
few aspects of the processor's operation. Turning MSR[SF] on or off
on a 64-bit CPU basically only affects whether it pays attention to
the high 32-bits of addresses when doing loads, stores, and branches
-- 64-bit arithmetic, comparisons, registers, etc. are all available
whatever the setting of MSR[SF].
Not sure I understand what you mean. You can't access the upper 32
bits since the instructions are not available when !SF. Also, some
subtile behavior changes.
If you for example run "lis x,-1" in !SF on a 64-bit machine, the
full register value becomes 0xffffffffffffffff while in SF mode it
becomes 0xffffffff. Maybe there are some parts in the code that are
not correct, but !SF on 64-bit is very subtile :).
Is that actually true, though? The architecture manual says nothing
about it, and on both Cell and 970 systems (the hardware I had handy),
as well as IBM Systemsim, lis x,-1 gives 0xffffffffffffff00
irrespective of the value of MSR[SF].
-Nathan
Also, those instructions *are* available. That's the only way to turn
64-bit mode on, for instance: you need to grab the MSR, set one of the
high bits, then mtmsrd (which is a 64-bit instruction).
-Nathan
