3 ms·

Isn't this a function of the tools you were using, not the syntax? Couldn't any of these tools support any syntax and do the same thing?

• JonChesterfield 4y ago
  The line between syntax and functionality is pretty thin for an assembler. I've definitely had code that some assemblers accepted and others didn't on the same arch, so even if they could be equally expressive in practice they aren't. Fairly sure that's also true of inline assembly on clang x64, had to change between intel and at&t for something a while ago.
  • throwawaylinux 4y ago
    Not really. Intel vs AT&T syntax is about how to generate machine code from mnemonics. Cooperation with the linker comes with other directives and options. gas has tight cooperation with GNU ld via directives (which mostly are just implemented with ELF constructs AFAIK), not instruction syntax. It can actually be set to accept either AT&T or Intel syntax, without losing any support for other features.
    • JonChesterfield 4y ago
      The case that comes to mind was emitting a (correct) relocation for one mode and raising an error for the other. That was more likely to be llvm-mc than gas though, so results from on assembler may not apply to all assemblers.
      • throwawaylinux 4y ago
        Emitting a relocation with .reloc directive? Definitely sounds like an llvm-as bug.
        • JonChesterfield 4y ago
          No, it was an arithmetic expression related to labels. And yes I'd agree that it working in... I want to say intel and not at&t (might be the other way around) is a bug/missing feature. Didn't bother fixing or reporting it at the time though.