On 12/16/20 4:14 AM, Jiaxun Yang wrote: > 在 2020/12/16 上午10:50, Jiaxun Yang 写道: >> TBH I do think it doesn't sounds like a good idea to make 32-bit >> and 64-bit different. In fact ISA_MIPS32R6 is always set for targets >> with ISA_MIPS64R6. >> >> We're treating MIPS64R6 as a superset of MIPS32R6, and ISA_MIPS3 >> is used to tell if a CPU supports 64-bit. >> >> FYI: >> https://commons.wikimedia.org/wiki/File:MIPS_instruction_set_family.svg > > Just add more cents here... > The current method we handle R6 makes me a little bit annoying. > > Given that MIPS is backward compatible until R5, and R6 reorganized a lot > of opcodes, I do think decoding procdure of R6 should be dedicated from > the rest, > otherwise we may fall into the hell of finding difference between R6 and > previous > ISAs, also I've heard some R6 only ASEs is occupying opcodes marked as > "removed in R6", so it doesn't looks like a wise idea to check removed > in R6 > in helpers. I think we are in agreement :) Your comment seems what I addressed last month as this series: https://gitlab.com/philmd/qemu/-/commits/mips_decodetree_lsa_r6/ (I'll try to rebase it and post during the week-end.) > So we may end up having four series of decodetrees for ISA > Series1: MIPS-II, MIPS32, MIPS32R2, MIPS32R5 (32bit "old" ISAs) > Series2: MIPS-III, MIPS64, MIPS64R2, MIPS64R5 (64bit "old" ISAs) > > Series3: MIPS32R6 (32bit "new" ISAs) > Series4: MIPS64R6 (64bit "new" ISAs) > > Thanks > > - Jiaxun
