7 ms·

D's approach is great, but it has a few limitations for my use case in Odin. It only supports x86_64/amd64 and uses Intel-style syntax, whereas I needed a solut

D's approach is great, but it has a few limitations for my use case in Odin. It only supports x86_64/amd64 and uses Intel-style syntax, whereas I needed a solution that universalizes its syntax across multiple ISAs. D's inline asm is also statement-based rather than a callable template. Though the mixin trick fixes this, it does mean it still uses %0-style parameters making it hard to read and write, something I want to remove completely. It is great to see that we arrived at similar design compromises, especially regarding `lock` being treated as a separate instruction and thus separated with a `;` (which is automatically inserted by the Odin compiler).

WalterBright 26d ago
> only supports x86_64/amd64 It supports x86, too, and we're working on Arm64. > uses Intel-style syntax Yes, because the instruction set references are in Intel syntax. The backwards gcc asm causes me seizures, like trying to write cursive with my left hand. The asm for Arm64 will also follow Arm's instruction specification. > D's inline asm is also statement-based That's so the source code can be tokenized and parsed without needing special behavior inside the asm { ... }. > it still uses %0-style parameters Not sure what you mean. RAX means register RAX. %RAX is not accepted. > especially regarding `lock` being treated as a separate instruction That just makes it easier to parse! Anyhow, thank you for the kind words! I am proud of it, the only troubles I have is when Intel adds wacky new instructions that just don't fit in the instruction encoding tables.
- gingerBill 25d ago
  > It supports x86, too Well I assumed so because amd64 is a superset of x86. But nice to know you're working on arm64 too. Regarding Intel-syntax, I think there is a little miscommunication here since I try to explain what I mean in the article. Intel-ordering is a good idea, but using nothing but the Intel-syntax wholesale is not universal enough, and needs modifying, especially for AMD64 and other ISAs. Odin's is Intel-like too, but fully Intel by design. > That's so the source code can be tokenized and parsed without needing special behavior inside the asm { ... }. This is why Odin's asm templates have their own universalized syntax. Thus the entire article. > Not sure what you mean. RAX means register RAX. %RAX is not accepted. This: https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/atomic.d#L216-L231 https://github.com/dlang/dmd/blob/master/druntime/src/core/i... It's why I referred to your "trick", which is something I wanted to need in the first place. > That just makes it easier to parse! For Odin's asm template syntax, it's not about being easier to parser, it's about having a context free grammar that is the same across ISAs. If I was to allow for prefixes directly in the grammar, either prefixes would have to have their special syntax or you'd need to have a context-sensitive grammar.
  - WalterBright 25d ago
    Oh I see what you mean. The "trick" has nothing to do with the inline assembler - it's a way the user can manipulate strings and then feed the result to the parser. String mixins are a very popular feature of D. A little secret - the D parser does not actually parse the asm syntax. It just snarfs up tokens until it sees the `;`. The semantic phase of the compiler then applies a grammar over it, which is not the D grammar, but the Intel grammar. This enables it to apply custom grammars to each supported instruction set.
    - gingerBill 24d ago
      That "trick" is just a fancy string effectively, the thing I am complaining about in the first part of the article. And that little secret really does mean it is a fancy string again. I did not want any of that for any reason.

WalterBright 26d ago

> only supports x86_64/amd64 It supports x86, too, and we're working on Arm64. > uses Intel-style syntax Yes, because the instruction set references are in Intel syntax. The backwards gcc asm causes me seizures, like trying to write cursive with my left hand. The asm for Arm64 will also follow Arm's instruction specification. > D's inline asm is also statement-based That's so the source code can be tokenized and parsed without needing special behavior inside the asm { ... }. > it still uses %0-style parameters Not sure what you mean. RAX means register RAX. %RAX is not accepted. > especially regarding `lock` being treated as a separate instruction That just makes it easier to parse! Anyhow, thank you for the kind words! I am proud of it, the only troubles I have is when Intel adds wacky new instructions that just don't fit in the instruction encoding tables.

gingerBill 25d ago
> It supports x86, too Well I assumed so because amd64 is a superset of x86. But nice to know you're working on arm64 too. Regarding Intel-syntax, I think there is a little miscommunication here since I try to explain what I mean in the article. Intel-ordering is a good idea, but using nothing but the Intel-syntax wholesale is not universal enough, and needs modifying, especially for AMD64 and other ISAs. Odin's is Intel-like too, but fully Intel by design. > That's so the source code can be tokenized and parsed without needing special behavior inside the asm { ... }. This is why Odin's asm templates have their own universalized syntax. Thus the entire article. > Not sure what you mean. RAX means register RAX. %RAX is not accepted. This: https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/atomic.d#L216-L231 https://github.com/dlang/dmd/blob/master/druntime/src/core/i... It's why I referred to your "trick", which is something I wanted to need in the first place. > That just makes it easier to parse! For Odin's asm template syntax, it's not about being easier to parser, it's about having a context free grammar that is the same across ISAs. If I was to allow for prefixes directly in the grammar, either prefixes would have to have their special syntax or you'd need to have a context-sensitive grammar.
- WalterBright 25d ago
  Oh I see what you mean. The "trick" has nothing to do with the inline assembler - it's a way the user can manipulate strings and then feed the result to the parser. String mixins are a very popular feature of D. A little secret - the D parser does not actually parse the asm syntax. It just snarfs up tokens until it sees the `;`. The semantic phase of the compiler then applies a grammar over it, which is not the D grammar, but the Intel grammar. This enables it to apply custom grammars to each supported instruction set.
  - gingerBill 24d ago
    That "trick" is just a fancy string effectively, the thing I am complaining about in the first part of the article. And that little secret really does mean it is a fancy string again. I did not want any of that for any reason.