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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
