From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrsPS-0002xi-Hw for qemu-devel@nongnu.org; Mon, 20 Oct 2008 06:54:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrsPQ-0002up-Aa for qemu-devel@nongnu.org; Mon, 20 Oct 2008 06:54:49 -0400 Received: from [199.232.76.173] (port=38136 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrsPQ-0002uY-3N for qemu-devel@nongnu.org; Mon, 20 Oct 2008 06:54:48 -0400 Received: from mail.codesourcery.com ([65.74.133.4]:44136) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KrsPP-0002KD-KA for qemu-devel@nongnu.org; Mon, 20 Oct 2008 06:54:47 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] SH: Add prefi, icbi, synco Date: Mon, 20 Oct 2008 11:54:20 +0100 References: <200810171652.46611.vladimir@codesourcery.com> <200810172056.53076.paul@codesourcery.com> <20081020040124.GA19601@linux-sh.org> In-Reply-To: <20081020040124.GA19601@linux-sh.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810201154.21179.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Vladimir Prus On Monday 20 October 2008, Paul Mundt wrote: > On Fri, Oct 17, 2008 at 08:56:52PM +0100, Paul Brook wrote: > > On Friday 17 October 2008, Vladimir Prus wrote: > > > This patch makes qemu recognize (and ignore), three instructions from > > > SH4A. > > > > Shouldn't these generate an illegal instruction exception on SH4 cpus? > > Note that all of these are SH-5 instructions, which gradually found their > way in to the SH-4A ISA. There are also other SH-5 instructions that have > found their way in to the SH-2A ISA which are not as of yet reflected in > SH-4A. The dependency tracking gets to be pretty ugly, as is evident in > binutils. In order to get this right, it would be necessary to throw ISA > versioning in to the CPU definition and test to figure out what to > support, as per the table in binutils. While this would be a good idea in > general, it is something that should be done as a larger follow-up to > these patches. I disagree. This is something that should be done right from the start. Trying to fix it up later is a real pain. Doing fine grained features isn't that hard. MIPS, sparc, arm, ppc, m68k and sparc already do this. IIRC binutils is only complicated because it tried to create a strict hieracy of features, rather than using feature bits. Paul