[Qemu-devel] Re: target-sparc/TODO

[Blue Swirl]

On Wed, Aug 19, 2009 at 1:17 PM, Artyom
Tarasenko<address@hidden> wrote:
> 2009/8/17 Blue Swirl <address@hidden>:
>> On Mon, Aug 17, 2009 at 1:52 PM, Artyom
>> Tarasenko<address@hidden> wrote:
>>>> - Global register for regwptr, so that windowed registers can be
>>>> accessed directly
>>>
>>> looks like it's already implemented?
>>
>> No, this means that a global register (TCG_AREG1) would be designated
>> as regwptr, so that the window registers (%o, %l, %i) would be defined
>> with:
>>
>> cpu_wregs[i] = tcg_global_mem_new(TCG_AREG1, offsetof(...), name).
>>
>> This would need some changes to cwp handling to support TCG_AREG1,
>> maybe also to TCG prologue.
>>
>> Before TCG, this was difficult because the registers were taken by
>> cpu_T0, cpu_T1 and cpu_T2.
>>
>> But it's not clear if this gives any performance gain, because
>> although window registers accesses may get faster (this is also not
>> certain because CPUstate should reside in cache), there is one host
>> register less available and that may mean more host memory accesses.
>
> So, it's only about performance, otherwise the current implementation
> is complete?

Yes. Sparc64/V9 side is less complete.

>>>> - Synthetic instructions
>>> Is it still open?
>>
>> We already handle 'clr' and 'mov'. Code generation is not optimal, for
>> example arithmetic ops with constants/%g0 or things like wrpsr which
>> always does a XOR of the parameters even if they are constants or %g0.
>
> Would the synthetic ops with %g0 produce wrong results?
> Particularly I'm interested if
>
> jmp     %l1, %g4, %g0
>
> may behave other than on a real hw.

No, if rd is %g0, the current PC will not be written anywhere (not by
real HW either). This is handled by translate.c:4041 call to
gen_movl_TN_reg(), which suppresses the move if rd is zero. Likewise
for other rd writeback.

This class of instructions ("op %x, %y, %g0") should be close to
optimal except for degenerate cases like "and %g1, 1, %g0" which
should not generate any code at all. "andcc %g1, 1, %g0" should and it
does.

I meant that "wrpsr %g1, 0" (or %g0) should suppress the useless XOR
of %g1 and 0.

>>>> - Hardware breakpoint/watchpoint support
>>> Is it still open?
>>
>> I think support for these was only found in a few CPU models, so they
>> are not used much. Nobody has also shown any interest or provided a
>> test case.
>
>
> On OBP start-up I see some "write breakpoint reg" messages in the
> debug log. Do they have to do with hardware breakpoint support?
>

Yes, or they could also be MMU breakpoint registers.