qemu-devel
[Top][All Lists]
Advanced

[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: Thu, 20 Aug 2009 11:44:48 +0200

>> 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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]