[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: target-sparc/TODO
From: |
Artyom Tarasenko |
Subject: |
[Qemu-devel] Re: target-sparc/TODO |
Date: |
Sat, 22 Aug 2009 14:40:47 +0200 |
2009/8/22 Blue Swirl <address@hidden>:
> 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!
Looks better now!
Probing Memory Bank #0 64 Megabytes of DRAM
Probing Memory Bank #1 64 Megabytes of DRAM
Probing Memory Bank #2 64 Megabytes of DRAM
Probing Memory Bank #3 64 Megabytes of DRAM
Probing Memory Bank #4 Data Access Error
ok
Used to be "Nothing there". What is a bit surprising, is that only 256
Mib found when started with -m 512. May be a next bug, this time in
ASI.
With -m 128 :
Probing Memory Bank #0 64 Megabytes of DRAM
Probing Memory Bank #1 64 Megabytes of DRAM
Probing Memory Bank #2 Nothing there
Probing Memory Bank #3 Nothing there
Probing Memory Bank #4 Data Access Error
ok
- [Qemu-devel] Re: target-sparc/TODO, (continued)
- [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, 2009/08/22
- [Qemu-devel] Re: target-sparc/TODO,
Artyom Tarasenko <=
- 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