asciidoctor-sail VS riscv-opcodes

Sail is pretty similar to ASL (both current ASL and ASL 1.0) except that (1) it has a more expressive type system, so that bitvector lengths can all be statically checked, (2) it has proper tagged unions and pattern matching, and (3) there's a wide range of open-source tooling available, for execution, specification coverage, generating emulators, integrating with relaxed concurrency models, generating theorem-prover definitions, etc. We've recently updated the Sail README, which spells some of this out: https://github.com/rems-project/sail .

As Alastair Reid says, one of the main things missing in the current RISC-V specification documents is simply that the associated Sail definitions are not yet interspersed with the prose instruction descriptions. The infrastructure to do that has been available for some time, in the Sail AsciiDoc support by Alasdair Armstrong (https://github.com/Alasdair/asciidoctor-sail/blob/master/doc...) and older LaTeX versions by Prashanth Mundkur and Alasdair (https://github.com/rems-project/riscv-isa-manual/blob/sail/r...).

It uses machine-readable specs from https://github.com/riscv/riscv-opcodes ; yet I needed to extract immediate bit scrambling from their LaTeX sources :). I wonder if there is an easier way. Anyways, the opcode semantics are hand-coded and it simulates enough to boot linux.

A couple of hours work would allow someone to work it out exactly by parsing the files in https://github.com/riscv/riscv-opcodes. I don't know whether the existing parse.py explicitly works this out. It does check for conflicts. If it doesn't provide this information now then it should be easy to add.

Add instruction's match and mask values and optionally add DECLARE_INSN definitions (include/opcode/riscv-opc.h). You can use riscv-opcodes to generate those mask/match values.

I'm a bit surprised René doesn't know about either https://github.com/riscv/riscv-opcodes or https://github.com/michaeljclark/riscv-meta