Provide a method to generate 'march' strings from UDB

[AnimeshAgarwal28]

Currently there is no straightforward way to generate a march string, these strings are used by down stream projects like binutils to specify the base isa and extension.

A use case I found out:
The GAS tests in binutils have a -march flag in the disassembly files, if GAS tests are to be generated from UDB we need an accurate method to generate the strings.

[AFOliveira]

To extend on this, there is no way to convert the UDB object for extensions into a isa_string.

I.e. RISC-V has a certain set of rules that describe how a ISA string is written and we should be deriving ISA strings for our cfgs when describing a processor.

[ThinkOpenly]

FYA, there is a description of the "Extension Naming Conventions" in chapter 37 of the RISC-V ISA unprivileged manual. It covers case sensitivity, underscores, versioning, ordering, etc.

[AFOliveira]

But I don't think it's only about extensions right? I.e. we have extension that aren't formally defined in the ISA manul, like "Sm"

[ThinkOpenly]

But I don't think it's only about extensions right? I.e. we have extension that aren't formally defined in the ISA manul, like "Sm"

Are you stating a concern about non-extensions appearing in the arch string? Other than the bases, everything else is an (optionally versioned) extension. The example you mention is an extension in every way except nominally. UDB defines it. It may be innocuous to leave them present, but probably better to filter them out. There is nothing tagging them as "not a recognized extension", though, so we would need to add that, likely as a new YAML attribute.

[jordancarlin]

Unfortunately, tools like gcc reject ISA strings with extensions they don't recognize, so we will definitely need to filter them out. There are several other "extensions" that aren't allowed in a gcc march string either (S and U if I recall correctly).

[AFOliveira]

Are you stating a concern about non-extensions appearing in the arch string? Other than the bases, everything else is an (optionally versioned) extension. The example you mention is an extension in every way except nominally. UDB defines it. It may be innocuous to leave them present, but probably better to filter them out. There is nothing tagging them as "not a recognized extension", though, so we would need to add that, likely as a new YAML attribute.

Indeed, I think this should be an Yaml attribute for the extensions schema. IMO we could make it optional so that we could simply specify the non-named extensions.

Unfortunately, tools like gcc reject ISA strings with extensions they don't recognize, so we will definitely need to filter them out. There are several other "extensions" that aren't allowed in a gcc march string either (S and U if I recall correctly).

Yes, that's also true. As I stated earlier(not in this issue), we need to first do the general ISA string and then also convert that ISA string it to each tool format. Indeed ISA string -> tool format is a useful tool, even outside UDB scope.