From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FzCHi-000886-Oy for qemu-devel@nongnu.org; Sat, 08 Jul 2006 08:51:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FzCHh-00086D-38 for qemu-devel@nongnu.org; Sat, 08 Jul 2006 08:51:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FzCHg-00086A-Ui for qemu-devel@nongnu.org; Sat, 08 Jul 2006 08:51:44 -0400 Received: from [193.7.176.20] (helo=bender.bawue.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1FzCIK-0002hD-AC for qemu-devel@nongnu.org; Sat, 08 Jul 2006 08:52:24 -0400 Date: Sat, 8 Jul 2006 13:47:53 +0100 From: Thiemo Seufer Subject: Re: [Qemu-devel] [PATCH] MIPS instruction set configuration Message-ID: <20060708124753.GH4274@networkno.de> References: <449FFEB2.1070305@gmail.com> <44A040DA.2050108@bellard.org> <44A1529D.1070306@gmail.com> <44A19BC3.1030607@bellard.org> <44A7F3F1.5020909@gmail.com> <20060702231636.GB18996@networkno.de> <44A927BD.4010206@gmail.com> <20060703170235.GB6625@networkno.de> <44AF4E6F.5090208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44AF4E6F.5090208@gmail.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dirk Behme Cc: qemu-devel@nongnu.org Dirk Behme wrote: > Thiemo Seufer wrote: > ... > >I recommend to go for a sufficiently flexible interface first, and then > >introduce it gradually in all appropriate places. A macro like: > > > >MIPS_OPC(ISA, ASE, CPU) > > > >which compares the arguments with the currently selected CPU emulation > >and throws an RI exception if the feature doesn't exist: > > > > ... > > case OPC_LD: > > MIPS_OPC(MIPS-III, 0, 0); > > ... > > break; > > ... > > > ... > >My point is those MIPS_USES_*/MIPS_FEATURE_* should be abstracted > >better, that is, they should move in the implementation of the > >MIPS_OPC macro. > > I really like your proposals of MIPS_OPC() and better > abstraction of MIPS_USES_*/MIPS_FEATURE_*! > > Do you think you can post a patch which introduces the basic > parts of this functionality in the short term? Then we can > use it as a starter for more improvements. I'm busy this weekend. [snip] > >Well, there is no CPU named "R4Kc". What qemu emulates today resembles > >mostly a 4kc, that is a MIPS32R1 CPU which has no FPU support. > > Yes, I understand this. But two things: > > First, in the current MIPS configuration FPU is enabled for > "R4Kc". I think we shouldn't disable anything what is there > at the moment, without giving an alternative for people > using this (e.g. introducing an additional machine). And > this only because there is no real world equivalent for this. I agree we should have a generic "emulate everything" configuration with MIPS64R2 + FPU + all ASEs + all non-conflicting CPU extensions. > Second, while I agree that there is no real world equivalent > for this, I think this is one of the biggest advantages of a > simulator like qemu: Your are able to configure and test > machine and feature combinations which will never exist in > real world really quickly. Probably, but the generic configuration will cover most of that already. Thiemo