From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FXjWV-0000GX-Sm for qemu-devel@nongnu.org; Sun, 23 Apr 2006 14:41:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FXjWV-0000GD-0L for qemu-devel@nongnu.org; Sun, 23 Apr 2006 14:41:31 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXjWU-0000GA-U0 for qemu-devel@nongnu.org; Sun, 23 Apr 2006 14:41:30 -0400 Received: from [64.233.184.230] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FXjYY-0007X0-R3 for qemu-devel@nongnu.org; Sun, 23 Apr 2006 14:43:38 -0400 Received: by wproxy.gmail.com with SMTP id i14so876056wra for ; Sun, 23 Apr 2006 11:41:29 -0700 (PDT) Message-ID: <444BCA67.6020300@gmail.com> Date: Sun, 23 Apr 2006 20:41:43 +0200 MIME-Version: 1.0 Subject: Re: [Qemu-devel] new MIPS instructions References: <444BB919.3060403@bellard.org> <20060423174847.GA9279@networkno.de> In-Reply-To: <20060423174847.GA9279@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: qemu-devel@nongnu.org Thiemo Seufer wrote: > Fabrice Bellard wrote: >>I suggest adding a parameter to cpu_mips_init() telling the exact CPU >>model which is emulated. Optionnal features (such as the FPU) could be >>specified with an additionnal parameter. > > Probably with an additional switch "emulate everything we know about", > which would be especially useful for usermode emulation where CPU > specifics don't matter that much. Good points, but I don't know which is the best way to go ;) I think there are pros for both ways: Pro "emulate everything we know about" or "one MIPS fits all": Compile your program with a -march option you want, load the binary (or now the ELF as well ;) ) into QEMU and (if QEMU has support for the selected architecture) it will run. Without the user to select any special configuration on the command line (or tweaking inside QEMUs source code). It will run correctly without the user even to think about any special QEMU configuration. This was what I assumed before investigating why my code with a special -march option didn't work. Pro "additional parameter": FPU is a good example for this. If the processor I want to emulate has no FPU I would assume if my code uses (accidently?) FPU instructions I get exception/error/warning from QEMU. It confused me that QEMU (wrongly) executes my program with unsupported instructions (architecture) without any warning. "one MIPS fits all" is a user friendly and QEMU easy to use option, while "additional parameter" is the option for emulation accuracy. I'm not an ELF expert: Does ELF contain information about architecture compiled for? If yes, we can combine both ways above? Load ELF file, read architecture from it and let QEMU autoselect correct architecture features (or give error if not supported). Then we have emulation accuracy but don't need additional options. Dirk