Comment by appyn
3 days ago
This syntax is far too simple and won't adequately capture semantics for some architectures, for example Hexagon with its packeted instructions or SHARC with its complex parallel instructions.
One can already see how this syntax isn't up to the task by the decision to put x86 prefixes on a separate line. The author tries to justify it but this comes across as trying to excuse a poor design decision.
Also the AI slop tone of this article is awfully grating. I nearly gave up reading it because the LLM editing artefacts were so jarring.
Odin is never going to support SHARC nor Hexagon, so it is literally not a problem.
And I do not even seen why a universal syntax for such ISAs is impossible to support either at the syntax level. Hexagon's `.new`/`:sat`/`:<<1` stuff could be easily added into the universal syntax (with a better syntax), even if other ISAs do not support it. Same with SHARC's parallel-operation separators: you just pick a different syntax.
Even now, the full `[base + indexscale + disp]` syntax is not semantically supported for RISCV64 because they do not support `indexscale` in their memory operands.
Yes the prefix syntax is a quirk but if can tell me an alternative syntax that is context-free to solve this problem that is also not too stark nor dense too read, please do! I am open to new ideas, but it seems that even other assemblers like Plan9, Go, and D, all came to similar conclusion with `lock; xadd ...`.
And the article was not LLM written.
Does Odin feel like a language which would ever target SHARC ?
SHARC is pretty weird, there's neither LLVM nor the GNU backends for SHARC. If you explained that you want to have something less crazy than ancient C they're going to say you want a Blackfin not SHARC because that's a more plausible target. SHARC's addressable memory comes in 32-bit uh, bytes.