On Thu, 20 Nov 2014, Peter Maydell wrote: > > For user emulation mode I think we want to default to the highest ISA > > level supported, for maximum user flexibility. Currently the MIPS64r2 > > ISA is the highest 64-bit ISA we have a real processor support for so > > use it and the 5KEf which is the processor we have that implements it. > > Later, as newer processors are added, we can bump it further up. > > Is it feasible to define an "any" CPU for linux-user which > basically enables all known ISA features? This is what we > do on ARM and some other target CPU families. If some CPU > features conflict with each other (so you can't validly > have a CPU with all of them) that might make it awkward, though.
It's not possible, the MIPS16 and microMIPS instruction sets are mutually exclusive as the same resource (the ISA bit or the LSB of the PC) is used to switch to either mode from the standard MIPS mode, depending on what a given processor implements. Besides it is worthwhile to have a processor that implements the microMIPS or the standard MIPS instruction set only, to trap unwanted mode switches in software that is supposed to use one of these instruction sets only (there is no such issue with the MIPS16 instruction set as it it not fully self-contained and the presence of the standard MIPS instruction set is also required). Additionally MIPSr6 is incompatible with any earlier ISA in the standard MIPS mode. The rest can probably be arranged although there are grey areas, specifically not all optional instruction sets have their opcodes defined in the microMIPS instruction set. But for the user emulation mode that should probably be OK as long the artificial processor is not available for the system emulation mode. In the system emulation mode such a processor could lead software to confusion, for example the Linux kernel examines processor configuration bits and configures itself accordingly. That works just fine across all the optional features in the standard MIPS mode, but a microMIPS kernel will not have access to the relevant maintenance instructions that have not been defined in the microMIPS instruction set. An example is the SmartMIPS extension whose ACX register has to be maintained in context switches and the access to which requires instructions that have not been defined in the microMIPS instruction set. So most likely there's a stub somewhere there that makes it panic instead. But in any case we'd need at least 3 processors anyway: MIPSr5 with the MIPS16 extension, MIPSr5 with the microMIPS extension and MIPSr6. Please note that as I suggested the right emulation could be chosen automagically based on ELF file header flags. In fact I have a patch outstanding already down the queue that does some processor reconfiguration based on that, just like the Linux kernel would do. That approach could be further extended up to selecting among processors available, so e.g. a program that contains some microMIPS code would pick up a microMIPS-enabled processor and one including MIPS16 code would pick up one with the MIPS16 extension instead. Thanks for your input though, the idea makes sense overall where possible. Maciej
