From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Me4Co-0001dc-UD for qemu-devel@nongnu.org; Thu, 20 Aug 2009 05:45:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Me4Cj-0001c1-Ek for qemu-devel@nongnu.org; Thu, 20 Aug 2009 05:45:13 -0400 Received: from [199.232.76.173] (port=48274 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Me4Cj-0001bs-2M for qemu-devel@nongnu.org; Thu, 20 Aug 2009 05:45:09 -0400 Received: from mail-gx0-f211.google.com ([209.85.217.211]:45115) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Me4Ci-0002nn-MY for qemu-devel@nongnu.org; Thu, 20 Aug 2009 05:45:08 -0400 Received: by gxk7 with SMTP id 7so6520852gxk.8 for ; Thu, 20 Aug 2009 02:45:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Thu, 20 Aug 2009 11:44:48 +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 >> 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 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?