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

[Artyom Tarasenko <atar4qemu@googlemail.com>]

2009/8/21 Blue Swirl <blauwirbel@gmail.com>:
> On Fri, Aug 21, 2009 at 3:40 PM, Artyom
> Tarasenko<atar4qemu@googlemail.com> wrote:
>> 2009/8/21 Artyom Tarasenko <atar4qemu@googlemail.com>:
>>> 2009/8/20 Blue Swirl <blauwirbel@gmail.com>:
>>>> On Thu, Aug 20, 2009 at 12:44 PM, Artyom
>>>> Tarasenko<atar4qemu@googlemail.com> wrote:
>>>>>>> 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).
>>>>>
>>>>> The reason I asked is the two following pieces of code work
>>>>> differently on a real and emulated SS-5. On a real one spacel! does an
>>>>> asi write, and spacel@ does an asi read, and under qemu  spacel! seems
>>>>> to do nothing, and spacel@ returns its second parameter multiplied by
>>>>> 4. Both of them don't even try to call an [unimplemented] asi
>>>>> operation, I've runned the tests with mmu and asi debug turned on.
>>>>>
>>>>> Real SS-5:
>>>>>
>>>>> ok 0 0 spacel@ .
>>>>> Data Access Error
>>>>> ok 0 20 spacel@ .
>>>>> 0
>>>>> ok 12345678 0 20 spacel!
>>>>> ok 0 20 spacel@ .
>>>>> 12345678
>>>>> ok
>>>>>
>>>>>
>>>>> qemu SS-5:
>>>>>
>>>>> ok 0 0 spacel@ .
>>>>> 0
>>>>> ok 0 20 spacel@ .
>>>>> 80
>>>>> ok 12345678 0 20 spacel!
>>>>> ok 0 20 spacel@ .
>>>>> 80
>>>>> ok
>>>>>
>>>>> I don't know sparc asm good enogh, but qemu behavior seems to be
>>>>> logical: in the first case I see no store op, and there are shifts
>>>>> which would multiply by 4:
>>>>>
>>>>> ok see spacel!
>>>>> code spacel!
>>>>> ffd26e0c     ld      [%g7], %l2
>>>>> ffd26e10     add     %g7, 4, %g7
>>>>> ffd26e14     ld      [%g7], %l0
>>>>> ffd26e18     add     %g7, 4, %g7
>>>>> ffd26e1c     sll     %g4, 2, %g4
>>>>> ffd26e20     call    ffd26e24
>>>>> ffd26e24     add     %g0, 14, %l1
>>>>>
>>>>> ok ffd26e24 dis
>>>>> ffd26e24     add     %g0, 14, %l1
>>>>> ffd26e28     add     %o7, %l1, %l1
>>>>> ffd26e2c     jmp     %l1, %g4, %g0
>>>>> ffd26e30     ba      ffd26f68
>>>>> ok
>>>>>
>>>>> ok see spacel@
>>>>> code spacel@
>>>>> ffd26830     ld      [%g7], %l0
>>>>> ffd26834     add     %g7, 4, %g7
>>>>> ffd26838     sll     %g4, 2, %g4
>>>>> ffd2683c     call    ffd26840
>>>>> ffd26840     add     %g0, 14, %l1
>>>>>
>>>>> ok ffd26840 dis
>>>>> ffd26840     add     %g0, 14, %l1
>>>>> ffd26844     add     %o7, %l1, %l1
>>>>> ffd26848     jmp     %l1, %g4, %g0
>>>>> ffd2684c     ba      ffd26984
>>>>>
>>>>>
>>>>> The code is identical on a real and emulated SS.
>>>>>
>>>>> It must be the jump, which jumps differently on a real hw and under
>>>>> qemu. Do you see from the code where the jump would jump to, or maybe
>>>>> you have a suggestion how to check where the jump jumps to on the real
>>>>> hw?
>>>>
>>>> The target of the call instruction is also a delay slot instruction
>>>> for the call itself. Maybe this case is not handled correctly?
>>>
>>> Good idea! Don't know how to test it though.
>>>
>>> And what about "ba" in the delay slot of "jmp"? Is the correct
>>> behavior described somewhere? Would jump just be ignored? Whould it
>>> execute one instruction on jump destination and then branch? Would
>>> branch be ignored?
>>
>> Page 55 of The SPARC v8 Architecture Manual
>> (http://www.sparc.org/standards/V8.pdf) describes this case
>> explicitly:
>> cpu should execute one instruction on the jump target and then branch.
>>  Is it what qemu currently does?
>
> I may be blind, I don't see the description of this case in that page.

I wasn't referring the call case, but jmp+ba case (two last ops in the
listing above). This DCTI is described on pages marked 55-56 (pages
54-54 in a pdf reader). That's the first case in the table 5-12.

> Both QEMU and real (Sparc64) hardware exit with return value of 3, so
> the inc is re-executed. If I add a nop in the call delay slot, the
> return value is 2.

Can you make a similar test, but with ba in the jmp's delay slot?