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