From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mea41-000160-C5 for qemu-devel@nongnu.org; Fri, 21 Aug 2009 15:46:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mea3z-00015f-PW for qemu-devel@nongnu.org; Fri, 21 Aug 2009 15:46:17 -0400 Received: from [199.232.76.173] (port=42331 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mea3z-00015a-KK for qemu-devel@nongnu.org; Fri, 21 Aug 2009 15:46:15 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:5213) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mea3z-0006vh-1E for qemu-devel@nongnu.org; Fri, 21 Aug 2009 15:46:15 -0400 Received: by fg-out-1718.google.com with SMTP id l27so283623fgb.8 for ; Fri, 21 Aug 2009 12:46:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Fri, 21 Aug 2009 22:45:52 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: target-sparc/TODO List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel On Fri, Aug 21, 2009 at 3:40 PM, Artyom Tarasenko wrote: > 2009/8/21 Artyom Tarasenko : >> 2009/8/20 Blue Swirl : >>> On Thu, Aug 20, 2009 at 12:44 PM, Artyom >>> Tarasenko wrote: >>>>>> Particularly I'm interested if >>>>>> >>>>>> jmp =C2=A0 =C2=A0 %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 =C2=A0spacel! = 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 =C2=A0 =C2=A0 ld =C2=A0 =C2=A0 =C2=A0[%g7], %l2 >>>> ffd26e10 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %g7, 4, %g7 >>>> ffd26e14 =C2=A0 =C2=A0 ld =C2=A0 =C2=A0 =C2=A0[%g7], %l0 >>>> ffd26e18 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %g7, 4, %g7 >>>> ffd26e1c =C2=A0 =C2=A0 sll =C2=A0 =C2=A0 %g4, 2, %g4 >>>> ffd26e20 =C2=A0 =C2=A0 call =C2=A0 =C2=A0ffd26e24 >>>> ffd26e24 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %g0, 14, %l1 >>>> >>>> ok ffd26e24 dis >>>> ffd26e24 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %g0, 14, %l1 >>>> ffd26e28 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %o7, %l1, %l1 >>>> ffd26e2c =C2=A0 =C2=A0 jmp =C2=A0 =C2=A0 %l1, %g4, %g0 >>>> ffd26e30 =C2=A0 =C2=A0 ba =C2=A0 =C2=A0 =C2=A0ffd26f68 >>>> ok >>>> >>>> ok see spacel@ >>>> code spacel@ >>>> ffd26830 =C2=A0 =C2=A0 ld =C2=A0 =C2=A0 =C2=A0[%g7], %l0 >>>> ffd26834 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %g7, 4, %g7 >>>> ffd26838 =C2=A0 =C2=A0 sll =C2=A0 =C2=A0 %g4, 2, %g4 >>>> ffd2683c =C2=A0 =C2=A0 call =C2=A0 =C2=A0ffd26840 >>>> ffd26840 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %g0, 14, %l1 >>>> >>>> ok ffd26840 dis >>>> ffd26840 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %g0, 14, %l1 >>>> ffd26844 =C2=A0 =C2=A0 add =C2=A0 =C2=A0 %o7, %l1, %l1 >>>> ffd26848 =C2=A0 =C2=A0 jmp =C2=A0 =C2=A0 %l1, %g4, %g0 >>>> ffd2684c =C2=A0 =C2=A0 ba =C2=A0 =C2=A0 =C2=A0ffd26984 >>>> >>>> >>>> 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. > =C2=A0Is it what qemu currently does? I may be blind, I don't see the description of this case in that page. However, I made a small Linux test program to test it: .global _start .type _start, function _start: mov 1, %o0 call 1f #ifdef NOP nop #endif 1: inc %o0 mov 1, %g1 ta 0x10 (and a BSD version: #include .globl _start _start: mov 1, %o0 call 1f #ifdef NOP nop #endif 1: inc %o0 mov SYS_exit, %g1 ta 0 ) 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.