[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: target-sparc/TODO
From: |
Blue Swirl |
Subject: |
[Qemu-devel] Re: target-sparc/TODO |
Date: |
Sat, 22 Aug 2009 09:51:01 +0300 |
On Sat, Aug 22, 2009 at 12:01 AM, Artyom
Tarasenko<address@hidden> wrote:
> 2009/8/21 Blue Swirl <address@hidden>:
>> On Fri, Aug 21, 2009 at 3:40 PM, Artyom
>> Tarasenko<address@hidden> wrote:
>>> 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 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?
Now, we have found a bug! The following program exits with 2 on real
hardware for -UBA and -DBA versions, but 0 for -UBA (2 for -DBA) on
QEMU!
#ifdef __OpenBSD__
#include <sys/syscall.h>
#endif
.globl _start
_start:
clr %o0
#ifdef BA
ba first
#else
set first, %g1
jmp %g1
#endif
ba second
/* should not be executed: */
or %o0, 1, %o0
second:
#ifdef __OpenBSD__
mov SYS_exit, %g1
ta 0
#else
mov 1, %g1
ta 0x10
#endif
first:
or %o0, 2, %o0
/* should not be executed: */
ba second
or %o0, 4, %o0
qemu.log reveals that in the -UBA case, instead of 'or %o0, 2, %o0',
the first 'clr %o0' is executed:
IN:
0x00010054: mov %g0, %o0
0x00010058: sethi %hi(0x10000), %g1
0x0001005c: or %g1, 0x74, %g1 ! 0x10074
0x00010060: jmp %g1
0x00010064: b 0x1006c
--------------
IN:
0x00010054: mov %g0, %o0
--------------
IN:
0x0001006c: mov 1, %g1
0x00010070: ta 0x10
For -DBA the log is OK:
IN:
0x00010054: mov %g0, %o0
0x00010058: b 0x1006c
0x0001005c: b 0x10064
--------------
IN:
0x0001006c: or %o0, 2, %o0
--------------
IN:
0x00010064: mov 1, %g1
0x00010068: ta 0x10
- [Qemu-devel] Re: target-sparc/TODO, (continued)
- [Qemu-devel] Re: target-sparc/TODO, Artyom Tarasenko, 2009/08/19
- [Qemu-devel] Re: target-sparc/TODO, Blue Swirl, 2009/08/19
- [Qemu-devel] Re: target-sparc/TODO, Artyom Tarasenko, 2009/08/20
- [Qemu-devel] Re: target-sparc/TODO, Blue Swirl, 2009/08/20
- [Qemu-devel] Re: target-sparc/TODO, Artyom Tarasenko, 2009/08/21
- [Qemu-devel] Re: target-sparc/TODO, Artyom Tarasenko, 2009/08/21
- [Qemu-devel] Re: target-sparc/TODO, Blue Swirl, 2009/08/21
- [Qemu-devel] Re: target-sparc/TODO, Artyom Tarasenko, 2009/08/21
- Re: [Qemu-devel] Re: target-sparc/TODO, Igor Kovalenko, 2009/08/21
- Re: [Qemu-devel] Re: target-sparc/TODO, Artyom Tarasenko, 2009/08/21
- [Qemu-devel] Re: target-sparc/TODO,
Blue Swirl <=
- [Qemu-devel] Re: target-sparc/TODO, Artyom Tarasenko, 2009/08/22
- Re: [Qemu-devel] Re: target-sparc/TODO, Robert Reif, 2009/08/22
- Re: [Qemu-devel] Re: target-sparc/TODO, Artyom Tarasenko, 2009/08/22
- Re: [Qemu-devel] Re: target-sparc/TODO, Robert Reif, 2009/08/22