From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HVGcX-0006Ez-Ge for qemu-devel@nongnu.org; Sat, 24 Mar 2007 20:30:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HVGcU-0006En-Vq for qemu-devel@nongnu.org; Sat, 24 Mar 2007 20:30:04 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVGcU-0006Ek-R4 for qemu-devel@nongnu.org; Sat, 24 Mar 2007 19:30:02 -0500 Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HVGaP-0007R0-SQ for qemu-devel@nongnu.org; Sat, 24 Mar 2007 20:27:54 -0400 Date: Sun, 25 Mar 2007 00:22:34 +0000 From: Thiemo Seufer Subject: Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction Message-ID: <20070325002234.GA14411@networkno.de> References: <45FB245C.2010900@mail.berlios.de> <20070317143106.GF25863@networkno.de> <45FC3A07.3070302@weilnetz.de> <200703172032.52010.paul@codesourcery.com> <45FEFAC0.4060901@mail.berlios.de> <20070319213445.GJ28895@networkno.de> <20070319223449.GK28895@networkno.de> <4600277F.6070804@mail.berlios.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4600277F.6070804@mail.berlios.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: QEMU Developers Stefan Weil wrote: > Hi, > > here is the patch which adds a "4KEcR1" CPU (a 4KEc, processor revision 2.2, > with MIPS32 Release 1 (!) instruction set is the heart of the AR7 SoC). > > See also include/asm-mips/cpu.h in the Linux kernel sources: > ./include/asm-mips/cpu.h:#define PRID_IMP_4KEC 0x8400 > ./include/asm-mips/cpu.h:#define PRID_IMP_4KECR2 0x9000 This was the bit which prompted to to ask The People Who Know[TM]. Indeed the early 4KEc were MIPS32R1 only. About the branch-in-delay-slot I got the following information: Very simple pipelines with branch delay slots tend to behave like this (when both branches are taken): - Execute the first branch, that is, calculate the target of the branch. This has no effect until it ran far enough through the pipeline. Increment PC. - Execute the second branch. This changes the branch target value again. Increment PC. - Execute the second branch's delay slot instruction. Increment PC. - Now the PC is overridden by the first branch's target. A single instruction from that place is executed. - The PC is overridden again by the second branch's target. Normal execution resumes from there. Apparently the SPARC architecture _requires_ this behaviour for all CPUs. Can you check if this is the behaviour you see on an AR7? Thiemo