From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeTQH-0005FU-2u for qemu-devel@nongnu.org; Fri, 21 Aug 2009 08:40:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeTQ8-00057h-FL for qemu-devel@nongnu.org; Fri, 21 Aug 2009 08:40:45 -0400 Received: from [199.232.76.173] (port=46198 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeTQ7-00056W-2C for qemu-devel@nongnu.org; Fri, 21 Aug 2009 08:40:40 -0400 Received: from an-out-0708.google.com ([209.85.132.250]:19050) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MeTQ6-0001Io-HY for qemu-devel@nongnu.org; Fri, 21 Aug 2009 08:40:38 -0400 Received: by an-out-0708.google.com with SMTP id c38so244273ana.37 for ; Fri, 21 Aug 2009 05:40:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Fri, 21 Aug 2009 14:40:16 +0200 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 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: Blue Swirl Cc: qemu-devel 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 =A0 =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 =A0spacel! seem= s >>> 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 =A0 =A0 ld =A0 =A0 =A0[%g7], %l2 >>> ffd26e10 =A0 =A0 add =A0 =A0 %g7, 4, %g7 >>> ffd26e14 =A0 =A0 ld =A0 =A0 =A0[%g7], %l0 >>> ffd26e18 =A0 =A0 add =A0 =A0 %g7, 4, %g7 >>> ffd26e1c =A0 =A0 sll =A0 =A0 %g4, 2, %g4 >>> ffd26e20 =A0 =A0 call =A0 =A0ffd26e24 >>> ffd26e24 =A0 =A0 add =A0 =A0 %g0, 14, %l1 >>> >>> ok ffd26e24 dis >>> ffd26e24 =A0 =A0 add =A0 =A0 %g0, 14, %l1 >>> ffd26e28 =A0 =A0 add =A0 =A0 %o7, %l1, %l1 >>> ffd26e2c =A0 =A0 jmp =A0 =A0 %l1, %g4, %g0 >>> ffd26e30 =A0 =A0 ba =A0 =A0 =A0ffd26f68 >>> ok >>> >>> ok see spacel@ >>> code spacel@ >>> ffd26830 =A0 =A0 ld =A0 =A0 =A0[%g7], %l0 >>> ffd26834 =A0 =A0 add =A0 =A0 %g7, 4, %g7 >>> ffd26838 =A0 =A0 sll =A0 =A0 %g4, 2, %g4 >>> ffd2683c =A0 =A0 call =A0 =A0ffd26840 >>> ffd26840 =A0 =A0 add =A0 =A0 %g0, 14, %l1 >>> >>> ok ffd26840 dis >>> ffd26840 =A0 =A0 add =A0 =A0 %g0, 14, %l1 >>> ffd26844 =A0 =A0 add =A0 =A0 %o7, %l1, %l1 >>> ffd26848 =A0 =A0 jmp =A0 =A0 %l1, %g4, %g0 >>> ffd2684c =A0 =A0 ba =A0 =A0 =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. 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.