On 1/6/21 5:23 AM, Jiaxun Yang wrote: > 在 2021/1/5 下午6:05, Philippe Mathieu-Daudé 写道: [...] >>> I based the decodetree logic on the R6 ISA manual, decoding the >>> bits from the more recent feature (a leaf) to the root, following >>> this tree: >>> https://images.anandtech.com/doci/8457/MIPS%20ISA%20Evolution.JPG >>> (2.3 Evolution of the Architecture). >>> >>> Also "2.1 Historical Perspective": >>> >>> In the MIPS IIITM ISA, 64-bit integers and addresses were added >>> to the instruction set. [...] >>> The MIPS32 Release 6 ISA maintains backward-compatibility, with >>> the exception of a few rarely used instructions, though the use >>> of trap-and-emulate or trap-and-patch; all pre-Release 6 binaries >>> can execute under binary translation. [...] >>> The MIPS64 Architecture is based on the MIPS V ISA and is backward >>> compatible with the MIPS32 Architecture. > > Hi all, > > Well I don't think it's worthy to keep R6 backward compatible with previous > Release. Opcodes existed in pre-R6 but removed in R6 will be reused in > future Releases (e.g. R6.1) for different functions. > > And the statement here about trap-and-emul, trap-and-patch is false. It > never > happens in the real world. R2-to-R6 emul in kernel never goes into > production > quality, not to mention IEEE754-2008 (NAN2008) issue. > > Based on documents we have, I'd prefer to treat MIPS ISA into three eras > Classic (I, II, III, IV), Modern (R1, R2, R3, R5), R6+(R6 and afterwards).
Sounds good to me! > The difference inside each era is well-documented in manuals, it can > prevent > us from get into a long-term hide and seek game of finding difference > between > ISA levels. Which is easier when you have access to the manuals ;) >>> >>>> But if this is an intermediate step, >>> As this isn't planned as intermediate step, I'll try to keep >>> CPU_MIPS64 as a separate bit and post the result. >> I'm not sure it is worth the effort, as I plan to check each ISA / >> ASE bit from the CP0_ConfigX bits (similarly target/arm/ does), so >> these definitions should disappear eventually. >> >> I.e. for the MSA ASE see: >> https://www.mail-archive.com/qemu-devel@nongnu.org/msg767523.html >> >> /* Check presence of MSA implementation */ >> static inline bool ase_msa_available(CPUMIPSState *env) >> { >> return env->CP0_Config3 & (1 << CP0C3_MSAP); >> } > Unfortunately MIPS has a bad manner that allows vendors to have random > extensions without unique identification. > ASEs flag can never go...... But identify ASEs from registers is surely > a good > idea though. At least removing MIPS defined ASEs from ASE flag can make > life easier. > > AFAIK Loongson has a CPUID instruction for 3A4000 and we may > implement that to identify Loongson extensions, Ingenic is also marking > MXU support in CP0. There could be some PRID based match to further > reduce ASEs flag. Yes. I'd like to have check_$FEAT() opaque from the TCG helpers perspective. Then how the check is implemented is a different story and can involve CPU specific code (as your 3A4000 example). Regards, Phil.
