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. Which is why I don't understand why they are 2 ISA_MIPS32R6/ISA_MIPS64R6 definitions. >> >> 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'm not sure I understood well your comment, but I also find how R6 is handled messy... I'm doing this removal (from helper to decoder) with the decodetree conversion. > 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) Something like that, I'm starting by converting the messier leaves first, so the R6 and ASEs. My approach is from your "series4" to "series1" last. Regards, Phil.
