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

[Artyom Tarasenko]

2009/8/21 Artyom Tarasenko <address@hidden>:
> 2009/8/20 Blue Swirl <address@hidden>:
>> On Thu, Aug 20, 2009 at 12:44 PM, Artyom
>> Tarasenko<address@hidden> 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 guess gcc doesn't generate such constructs, so linux & Co wouldn't
notice if this behavior is not implemented as specified.