qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: MIPS instruction set configuration


From: Fabrice Bellard
Subject: Re: [Qemu-devel] Re: MIPS instruction set configuration
Date: Tue, 27 Jun 2006 22:57:39 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

Marius Groeger wrote:
On Tue, 27 Jun 2006, Dirk Behme wrote:

Fabrice Bellard wrote:

3. [PATCH] Add special MIPS multiply instructions
http://lists.gnu.org/archive/html/qemu-devel/2006-04/msg00375.html


Same remark.


These are NEC VR54xx specific extensions to the MIPS instruction set.

They are used if you use GCC's -march=vr5400 option. See

www.necelam.com/docs/files/1375_V2.pdf

as well.

Can you add some kind of define or dynamic processor definnition in your patch so that we can keep track of the exact instruction set ?


Yes, I will update the patch. Any ideas or proposals from anybody how to do this the best way? Are there already examples from other architectures?

I think a define to be able to completely select/unselect it at compile time combined with possibility for dynamic runtime selection would be the best?


I'm trying to make sense of a compile-time switch -- for the use to select you vr5400 based platform, I can't think of anything else than a new -M option (ie. a new machine definition). So the full set of possible insns must be present and be available depending on the machine (-M ...) at runtime.

Or is it possible to compile qemu for a specific "-M machine"?

You should add a runtime selection system : see the ARM and PowerPC targets (I would prefer a parameter to cpu_init(). It was not done that way on PowerPC for legacy reasons). Each machine should be able to select the processor it needs (and allow the user to change it if needed, but it is not the main point). There is no good reason to make the selection at compile time because the translator can efficiently handle any CPU differences at runtime.

Regards,

Fabrice.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]