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

[Jiaxun Yang <jiaxun.yang@flygoat.com>]

在 2021/1/5 下午6:05, Philippe Mathieu-Daudé 写道:
> Hi Richard,
>
> On 1/5/21 9:34 AM, Philippe Mathieu-Daudé wrote:
>> On 1/5/21 12:30 AM, Richard Henderson wrote:
>>> On 1/4/21 12:11 PM, Philippe Mathieu-Daudé wrote:
>>>> MIPS 64-bit ISA is introduced with MIPS3.
>>>>
>>>> Introduce the CPU_MIPS64 definition aliased to the MIPS3 ISA,
>>>> and the cpu_type_is_64bit() method to check if a CPU supports
>>>> this ISA (thus is 64-bit).
>>>>
>>>> Suggested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>>>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>>>> ---
>>>>   target/mips/cpu.h       | 5 +++++
>>>>   target/mips/mips-defs.h | 4 +++-
>>>>   2 files changed, 8 insertions(+), 1 deletion(-)
>>> I still don't understand this as an alias, as opposed to a separate bit.
>>> (ISA_MIPS3 | CPU_MIPS64R6) does not make sense, because R6 removes instructions.
> Well, FWIW (ISA_MIPS3 | CPU_MIPS64R6) is what we currently have:
>
> #define CPU_MIPS64R6    (CPU_MIPS64R5 | CPU_MIPS32R6 | ISA_MIPS64R6)
>
> #define CPU_MIPS64R5    (CPU_MIPS64R3 | CPU_MIPS32R5 | ISA_MIPS64R5)
>
> #define CPU_MIPS64R3    (CPU_MIPS64R2 | CPU_MIPS32R3 | ISA_MIPS64R3)
>
> #define CPU_MIPS64R2    (CPU_MIPS64 | CPU_MIPS32R2 | ISA_MIPS64R2)
>
> #define CPU_MIPS64      (CPU_MIPS5 | CPU_MIPS32 | ISA_MIPS64)
>
> #define CPU_MIPS5       (CPU_MIPS4 | ISA_MIPS5)
>
> #define CPU_MIPS4       (CPU_MIPS3 | ISA_MIPS4)
>
> #define CPU_MIPS3       (CPU_MIPS2 | ISA_MIPS3)
>
> So CPU_MIPS64R6 -> CPU_MIPS64R5 -> CPU_MIPS64R3 -> CPU_MIPS64R2
>   -> CPU_MIPS64 -> CPU_MIPS5 -> CPU_MIPS4 -> CPU_MIPS3 -> ISA_MIPS3
>
> This patch doesn't make it worst :)
>
>> I now understand your concern.
>>
>> 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).
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.

>>
>>> 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.

Thanks.

- Jiaxun

>
> Might I keep your R-b tag for this patch (eventually improving the
> commit description with some of the info added in this mail) and
> keep going?
>
> Thanks,
>
> Phil.