4 ms·
RISC-V asm instruction name madness
- Pet_Ant 5y agoSorry, but isn’t it trivial to rename all the instructions and then just have a transpiler? There you go.
- wyldfire 5y agoSure, you can always solve problems by adding indirection. But sometimes you want to debate an effective design of this layer - in this case the assembly language.
- contravariant 5y agoFamously you can solve all problems that way, except the problem of having too many layers of indirection.
- LeFantome 5y agoWell, you could mostly solve it by having a compiler target whatever level of indirection required. No need to chain through them all.
- charcircuit 5y agoIs it possible to view this whole thread at once instead of having to look at each person's message 1 by 1?
- psychoslave 5y agoA bit convoluted, and far from a perfect rendering, but you can try this: elinks 'https://www.realworldtech.com/forum/?threadid=205288' -dump | grep curpostid | sed -e 's/.*https/https/' | while read -r url ; do elinks -dump $url | awk '/By:/, /Previous/' | sed \$d ; done | less
- tmp_cond_trav 5y agoThanks! I pasted the output of this making it easy to read under https://pastebin.com/JeVxYzLM https://pastebin.com/JeVxYzLM
- bhouston 5y agoThe main proposal here for true problem is to normalize longer assembly instruction names. That seems reasonable.
- qayxc 5y agoUnfortunately it seems as if there's too much ad-hoc naming going on as opposed to a reasonable set of conventions.
- zozbot234 5y agoInterestingly, VM instruction sets (JVM, CLR, WASM etc.) tend to have the opposite problem in that the chosen names are pointlessly long, even though the insn sets are so small that more concise mnemonics are definitely possible.
- mananaysiempre 5y agoNot only VMs — SSE/AVX on x86 has been getting more and more ridiculous over the last decade (PCLMULHQLQDQ anyone?), although it isn’t clear that the names are at fault and not simply the haphazard instruction set.
- int_19h 5y agoVM instruction sets are generally not written by people, but they're occasionally read by people (who might have to do so for debugging). And terse mnemonics are not good for readability.
- zozbot234 5y ago> And terse mnemonics are not good for readability. I disagree there, though it would be nice to see some actual research on these issues. I for one see pointlessly long mnemonics as kind of a worst case for surveyability, maybe even worse than pretty-printed English-like phrases as seen in BASIC or COBOL. (Of course, seemingly "long" mnemonics often result from orthogonality in the insn set, e.g. as in PCLMULHQLQDQ mentioned in a sibling comment. In that case, having a "long" mnemonic is indeed better than compacting it and losing track of its internal structure.)
- int_19h 5y agoI dunno; e.g. IL doesn't look pointlessly long to me, and it's certainly nowhere near COBOL level of verbosity: https://en.wikipedia.org/wiki/List_of_CIL_instructions https://en.wikipedia.org/wiki/List_of_CIL_instructions Mostly it uses well-established terse mnemonics - e.g. for branching or arithmetic - but stuff related to CLI object model and other unusual things are spelled out more fully.
- nynx 5y agoWASM went ahead and renamed all the instructions at some point to make them more consistent. e.g. `get_local` was renamed to `local.get`. Maybe RISCV should do the same.
- dingosity 5y agoAll those comments about "interesting" assembly mnemonics for various architectures and not a single person mentioned the 6809's SEX (Sign EXtend) instruction.
- limoce 5y agoCan we have namespaces for mnemonics? Something like vec.gather
- wyldfire 5y agoyou can have arbitrarily complex assembly language when you define a new architecture. You'll have an easier time fitting into existing assemblers if you are able to accept gas-like directives at least. So yeah - just create your mnemonics for your new architecture that happened to be prefixed by the instruction class/domain.
- wyldfire 5y ago> In the V-extension, they have an instruction named "vrgather". > But that instruction is not a gather load instruction. This instructoin is just a shuffle instruction. I don't know that it's the case here but if there's a more general instruction that could do the same effects as another with implicit operands you can preserve the opcode space and create assembler-mapped instructions. So for this case you could make a "vshuffle" mnemonic that encodes a specific vgather with an implied permutation of the inputs. I'm speaking very generally and broadly here - I have no idea about the specifics of the RISC-V vector extension.
- snvzz 5y agoIMHO it is actually a good thing. It promotes looking up what an opcode does, rather than assuming what it does from its name. What an opcode precisely does is actually critical, in assembly. Once the engineer has done so and is intimately familiar with the opcode, the short mnemonic is a non-issue.
- znwu 5y ago> In the V-extension, they have an instruction named "vrgather". > But that instruction is not a gather load instruction. This instructoin is just a shuffle instruction. I think on the contrary, x86's permute/shuffle/gather naming is a horrible legacy mess (plus broadcast and other stuff). The channels width, the source selection, the IMM encoding, all basically nonsense and horrifically non-orthogonal. `vrgather` is literally "gather from register, vector". In risc-v, you can gather from 8 consecutive vector registers (maximum size of a vector register group). That means 1024bits on a bare minimum Zv128b machine. This channel width blows out the 256bits/128bits channel nonsense even in AVX512 and deserve a name closer to memory gather.