From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MepuC-00017E-CT for qemu-devel@nongnu.org; Sat, 22 Aug 2009 08:41:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mepu8-00016a-Q5 for qemu-devel@nongnu.org; Sat, 22 Aug 2009 08:41:12 -0400 Received: from [199.232.76.173] (port=51852 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mepu8-00016X-Nq for qemu-devel@nongnu.org; Sat, 22 Aug 2009 08:41:08 -0400 Received: from mail-yw0-f195.google.com ([209.85.211.195]:55693) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mepu8-0008S7-AB for qemu-devel@nongnu.org; Sat, 22 Aug 2009 08:41:08 -0400 Received: by ywh33 with SMTP id 33so1646303ywh.18 for ; Sat, 22 Aug 2009 05:41:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Sat, 22 Aug 2009 14:40:47 +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/22 Blue Swirl : > On Sat, Aug 22, 2009 at 12:01 AM, Artyom > Tarasenko wrote: >> 2009/8/21 Blue Swirl : >>> 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 =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! = 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 =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 may= be >>>>>>> you have a suggestion how to check where the jump jumps to on the r= eal >>>>>>> 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. >>>> =A0Is 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