From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrxfJ-0003B2-4j for qemu-devel@nongnu.org; Mon, 20 Oct 2008 12:31:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrxfG-0003Ak-Jl for qemu-devel@nongnu.org; Mon, 20 Oct 2008 12:31:31 -0400 Received: from [199.232.76.173] (port=56531 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrxfG-0003Ah-Aj for qemu-devel@nongnu.org; Mon, 20 Oct 2008 12:31:30 -0400 Received: from mail.codesourcery.com ([65.74.133.4]:37717) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KrxfF-0006lC-W8 for qemu-devel@nongnu.org; Mon, 20 Oct 2008 12:31:30 -0400 From: Vladimir Prus Subject: Re: [Qemu-devel] [PATCH] SH: Add prefi, icbi, synco Date: Mon, 20 Oct 2008 20:31:19 +0400 References: <200810171652.46611.vladimir@codesourcery.com> <20081020130021.GB20548@linux-sh.org> <200810201727.01042.paul@codesourcery.com> In-Reply-To: <200810201727.01042.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810202031.19287.vladimir@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: Paul Brook Cc: qemu-devel@nongnu.org On Monday 20 October 2008 20:27:00 Paul Brook wrote: > > > 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. > > > > When we do it does not matter, but it is completely unrelated from this > > patch, in that there are already plenty of instructions that are specific > > to a certain CPU family that we don't perform an illegal instruction > > exception for. Trying to force the prefi/icbi/synco cases to rework all > > of the existing instructions that aren't universal doesn't make a lot of > > sense, as it is a clear incremental change of existing behaviour, rather > > than a situation caused purely by the addition of these new instructions. > > The only cpu we currently claim to support is SH4. When adding support for > other cores these should be properly conditionalized. Unconditionally > implementing additional instructions is a regression. I don't consider "we'll > fix this at some undefined point in the future" to be a good enough answer. Can you outline what changes should I make to implement proper conditionalization? Thanks, Volodya