How to parse the ISA string

[Timmmm]

One part of #175 concerns how to parse the ISA string from a riscv-config YAML file, in order to enable/disable extensions in the Sail model. We got a bit sidetracked (my fault) so I'm moving that discussion here. Summary so far:

1. I wrote a basic Sail parser PoC. It shows that you can do this parsing in Sail, which avoids having to write it twice (in C and OCaml) or dealing with FFI. However it is O(N^2) in the length of the string due to string_drop() creating a new string. May not be an issue. Or if it is it may be possible to change sail.c to use reference counted strings.
2. @Alasdair has written a parser in C which doesn't suffer these problems, but would need to be reimplemented in OCaml (probably not hard if you know OCaml and hard if you don't!), and it doesn't get the results into Sail.

Other things to note/question:

1. The spec says the ISA string is case insensitive. However tools (e.g. GCC) seem to require lowercase, and riscv-config requires uppercase. The Sail model should probably be case insensitive.
2. The spec vaguely talks about the order of extensions, and riscv-config mandates its own strict canonical ordering (and no extraneous underscores). However neither of these affect the execution of the Sail model so IMO they should be ignored.
3. There's an ambiguity with the P extension you need to handle. No big deal; just something to be aware of.
4. The format supports version numbers. Do we definitely need to parse those or can we treat them as part of the name?

This could (any maybe should?) be done independently from the riscv-config work in #175 since it only needs a single string as input, and that's easy to add as a CLI parameter.

[jrtc27]

4. The format supports version numbers. Do we definitely need to parse those or can we treat them as part of the name?

Version numbers are optional so you need to be able to separate the optional major and additional optional minor components from the extension name itself (I mean, you could turn the unversioned or "partially"-versioned names into canonically-versioned strings, but either way you need to have a full parser, so doesn't really matter which direction you go).

[Alasdair]

I think you need to parse version numbers and expose them to Sail, as we might well in the future run into the case where you need something like:

if have_ext("Zfoo") && major_version("Zfoo") == 1 then {

} else if have_ext("Zfoo") && major_version("Zfoo") >= 2 {

}

I looked at the riscv-config ISA string parser code and I think it misses a few cases, it also has the same issue as spike (from our perspective) where it only parses extensions it knows about.

One case I noticed that isn't covered in most of the implementations I saw is that Sv39 in an ISA string indicates the translation scheme, not 'supervisor extension v, version 39'. You can also have something silly likeZbar1p1p1p1 which would be the Zbar1p1 extension, versions 1.1, so you have to be careful to not start parsing a version number too soon.

[Alasdair]

There are some other complexities with the version numbers. Implicitly the major version is stated as being the last released version of the document (so as soon as RISC-V international releases a new spec for an extension, your string changes meaning unless you explicitly versioned everything).

In my code I added a default_major_version argument. However I realise now this is incorrect as not every extension has the same default version. All the base extensions do, but various Z extensions don't. I'll change it to return -1 for unspecified versions or something.

[Alasdair]

We introduced the version numbering scheme with the second release. Hence, we define the default
version of a standard extension to be the version present at that time, e.g., “RV32I” is equivalent
to “RV32I2”.

It's 2.0 for standard extensions. I suppose it might stay that way forevermore depending on how you read 'version present at that time'.

[jrtc27]

No. It was 2.0 for the extensions that were present at the time the scheme was introduced, and some extensions saw later bumps to their default versions (which was and continues to be a total pain for the ecosystem), namely I and A are at 2.1 and F and D are at 2.2. It's 1.0 for all new extensions.

https://github.com/llvm/llvm-project/blob/4ac5b0da8d71b72dc999a462ecfb3695d0803e7c/llvm/lib/Support/RISCVISAInfo.cpp#L52 is LLVM's current table of extensions. For non-experimental extensions the version number is the default. For experimental extensions both -menable-experimental-extensions and the version number are required (even if it might end up being the final version number; this ensures that 1.0-rcN spec versions aren't declared final by the toolchain and so late updates due to public review can be made without changing the version, which is a bit awful but so be it).

[Alasdair]

Right, but if default versions can be bumped at any point in the future like with A then there isn't a sensible thing for the parser to do other than report 'not present', and leave having the table of default versions to the consumer

[jrtc27]

We're (toolchain people) hoping to stop RVI from making such changes, because they come with changed semantics... e.g. bumping I from 2.1 to 2.2 split out Zicsr from it and so code that used to work fine for rv64i had to be modified to enable rv64izicsr, but only when using a toolchain new enough to have split the extension out.

[Alasdair]

Following that LLVM convention with -menable-experimental-extensions seems like the thing we should do.