Kind of random: I have my own C compiler that I recently added the ability to target RV64, in addition to my own ISA (my CPU core runs both my own ISA and RV64, namely RV64G with a few custom extensions). One bit of wonk though is that my ISA and compiler took a different path: Early on, I had implemented the Hitachi SH-4 ISA, and my first ISA was basically a direct superset of SH-4. Later, I did a partial reboot, redesigning the encoding scheme, but mostly keeping the same basic ABI design (loosely derived from the WinCE SH-4 ABI), and much of the ASM remained backwards compatible (there are differences, mostly with misc instructions and features that were dropped; with some things being faked in the assembler). Adding RV64 was a bigger challenge, but more in terms of significant ABI differences (such as different registers for passing registers and caller/callee save, ...). But, now there is another bit of wonk: My assembler does not use the proper RISC-V ASM notation, but instead still uses a notation derived from GCC/GAS SuperH notation (loosely M68K like, but without the % prefixes, ...). In concept, it wouldn't be too hard for the assmbler to support the proper RV64 ASM notation, but would need to find a good way to tell them apart (in this case there is some level of syntactic overlap. This is unlike, say, Intel vs GAS syntax on x86 where there was less room for ambiguity as to which is which). Most troublesome difference is that the two notations have different operand ordering, and there may not necessarily always be sufficient context to make it unambiguous (say, between RV code written in "Rd, Rs1, Rs2" order vs "Rs1, Rs2, Rd"; so "fingerprinting" does not seem like a safe strategy in the absence of more obvious and unambiguous differences). And, here, the likely main way to fingerprint them would be things like "LI Rd, Imm" vs "MOV Imm, Rd" and similar (and various other cases where proper RV ASM uses different mnemonics; for my compiler it was initially easier to just keep using the mnemonics and similar from my existing ISA, but remapping them to the analogous RV64 encodings). But, fingerprinting may be sufficient (it is either this or define an explicit assembler directive); one area of concern here being if someone makes a mess by going mix/match with the mnemonics.
Kind of random: I have my own C compiler that I recently added the ability to target RV64, in addition to my own ISA (my CPU core runs both my own ISA and RV64, namely RV64G with a few custom extensions). One bit of wonk though is that my ISA and compiler took a different path:
Early on, I had implemented the Hitachi SH-4 ISA, and my first ISA was basically a direct superset of SH-4. Later, I did a partial reboot, redesigning the encoding scheme, but mostly keeping the same basic ABI design (loosely derived from the WinCE SH-4 ABI), and much of the ASM remained backwards compatible (there are differences, mostly with misc instructions and features that were dropped; with some things being faked in the assembler).
Adding RV64 was a bigger challenge, but more in terms of significant ABI differences (such as different registers for passing registers and caller/callee save, ...).
But, now there is another bit of wonk:
My assembler does not use the proper RISC-V ASM notation, but instead still uses a notation derived from GCC/GAS SuperH notation (loosely M68K like, but without the % prefixes, ...).
In concept, it wouldn't be too hard for the assmbler to support the proper RV64 ASM notation, but would need to find a good way to tell them apart (in this case there is some level of syntactic overlap. This is unlike, say, Intel vs GAS syntax on x86 where there was less room for ambiguity as to which is which).
Most troublesome difference is that the two notations have different operand ordering, and there may not necessarily always be sufficient context to make it unambiguous (say, between RV code written in "Rd, Rs1, Rs2" order vs "Rs1, Rs2, Rd"; so "fingerprinting" does not seem like a safe strategy in the absence of more obvious and unambiguous differences). And, here, the likely main way to fingerprint them would be things like "LI Rd, Imm" vs "MOV Imm, Rd" and similar (and various other cases where proper RV ASM uses different mnemonics; for my compiler it was initially easier to just keep using the mnemonics and similar from my existing ISA, but remapping them to the analogous RV64 encodings). But, fingerprinting may be sufficient (it is either this or define an explicit assembler directive); one area of concern here being if someone makes a mess by going mix/match with the mnemonics.