Re: [PATCH v3 04/15] target/mips/mips-defs: Introduce CPU_MIPS64 and cpu_type_is_64bit()

[Philippe Mathieu-Daudé]

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.