From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fz69n-0003yo-Rt for qemu-devel@nongnu.org; Sat, 08 Jul 2006 02:19:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fz69l-0003yT-Fu for qemu-devel@nongnu.org; Sat, 08 Jul 2006 02:19:10 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fz69l-0003yQ-C2 for qemu-devel@nongnu.org; Sat, 08 Jul 2006 02:19:09 -0400 Received: from [64.233.182.186] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fz6AL-00040z-5n for qemu-devel@nongnu.org; Sat, 08 Jul 2006 02:19:45 -0400 Received: by nf-out-0910.google.com with SMTP id b2so145096nfe for ; Fri, 07 Jul 2006 23:19:08 -0700 (PDT) Message-ID: <44AF4E6F.5090208@gmail.com> Date: Sat, 08 Jul 2006 08:19:27 +0200 MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] MIPS instruction set configuration References: <449EB5FA.6070405@gmail.com> <449EBC39.3050701@bellard.org> <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> In-Reply-To: <20060703170235.GB6625@networkno.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Dirk Behme Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thiemo Seufer , qemu-devel@nongnu.org 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. > This is not meant as an objection, I'm just drawing from experience > with binutils, where it took some iterations (and wasted effort) to > get it sufficiently right. You are right with your wasted effort argument above as well. However, my patch does not only introduce MIPS_USES_*/MIPS_FEATURE_*. It additionally introduces cpu_mips_set_model() (yes, I know, this can be improved as well, as Fabrice mentioned). So it shouldn't be to much wasted effort to keep the cpu_mips_set_model() and convert the three or four places of my MIPS_USES_*/MIPS_FEATURE_* to your MIPS_OPC abstraction (in case my patch is accepted ;) ). Btw, while talking about cpu_mips_set_model(): While thinking about it I found that we should try to keep the generic parts of cpu and model selection logic in sync with other architectures, I think at least with ARM (where possible). There will be differences in details like in instruction set splitting with your MIPS_OPC logic. But would be nice if we make generic improvements to e.g. cpu_mips_set_model() at MIPS, we make the same at ARM as well. ... > 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. 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. This second point is "the simulated machines should model the real world 110% exactly" vs "I don't need 100% simulation accuracy and wan't to be able to use configurations which are not possible in real world". Depends on how people will use qemu. I think while the first argument may be valid for x86 where people want to run e.g. Windows on Linux, for embedded processors like ARM or MIPS the second may be valid and interesting as well. Cheers Dirk