Jeremy Bennett

These have impacts on the compiler team - the current spec is already in [core-v-binutils-gdb](https://github.com/openhwgroup/corev-binutils-gdb). We need a process to manage ISA changes that break software. In this case the...

I suggest there are three things to do. 1. We need a process to make sure software TG signs off on any changes that affect the SW world - something...

@jm4rtin Yes my point was really about process. For now everything is in development (on the `development` branch in the `corev-binutils-gdb` repo). We are working from the `core-v-docs` specification. We...

There is no rush. We've missed Stage 3 for GCC 11, so we have a year. The delay is not due to ISA freeze, the issue of vendor specific relocations...

Stability will help the SW team - it just means we don't end up redoing work. But if the architecture needs to evolve we can handle it. The important thing...

That is in essence the issue around vendor relocations. The RISC-V PS-ABI defines relocations 192-255 for vendor use. However there is no mechanism for how we avoid clashes between different...

@jm4rtin Nice work. One thing we don't have to worry about is SIMD and bitmanip, since we know these are going to be replaced with the official RISC-V versions in...

> Well, the cv32e40p has bitmanipulation and simd and will support them. > So it's better to move all the extensions in the the custom space. With less priority sure,...

> The encoding isn't really a headache for the hardware. Even before they got swapped around there was some other encodings for some of these instructions. It's more of a...

@jm4rtin The number of encoding types/work for the tool chain is not a significant problem for the software tool chain. It's just rows in a table and potentially some extra...