Hi Jim: > This isn't a criticism of your patch, but I noticed while looking at > this that we accept gXpY and expand to iXpY_mXpY_ etc. However, imafd > are all numbered independently. It doesn't make much sense to specify > a version with g and assume it is correct for all of imafd. Similarly > with the implied extensions, e.g. dXpY is expanded to fXpY_dXpY, > though in this case it is likely that f and d numbers will remain > compatible. And q too. Still it looks a bit funny to be making that > assumption and there probably will be other examples where the > versions of the implied extensions won't match the specified > extension. Actually I see that f implies Zicsr, and those two have > different version numbers, we just haven't implemented Zicsr yet. We > are correctly implementing the rules as specified, the rules just > don't make sense here. We probably need to file an issue against the > riscv-isa-manual project for a clarification of how to handle this > stuff.
I agree the version of G is kind of problematic for GCC implementation, That reminds me there was a long discussion[1] last year, The conclusion is version of G is too confusing, it might just don't accept any version for G. I thought it could deprecate the version for G in GCC 11 and then drop that in GCC 12? For riscv-isa-manual, we could ask them to add a note about the G don't accept version? What do you think about this? And the -misa-spec is supported on the binutils side, so I guess it's time to start to improve those things on GCC now. [1] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aZhMG7NIVTk/m/hX2BRWsMEQAJ Thanks :) > > Jim
