8 ms·

What was the original reason for the design of AT&T assembly syntax? (2017)

108 points by luu 6y ago

userbinator 6y ago
My guess is someone long ago decided to "be different" for whatever capricious reason, since I don't think the syntaxes for any other architectures are different from what's in the official manuals. Related article: http://x86asm.net/articles/what-i-dislike-about-gas/ http://x86asm.net/articles/what-i-dislike-about-gas/
- ksaj 6y ago
  That article is from 2007, so I don't think we're going to get that promised update any time soon. I really wish they would have gotten around to it, because toward the end they say: "Another GAS's problem is that it still keeps very old standards, not all of which are the best choice." I'd love to see some examples of those poor choice standards compared in similar fashion as the article's earlier examples. That would be pretty interesting. They might also be updated since then. Can't know without examples. Their argument about jumps was a little bit brilliant. If your syntax (like AT&T's "gas") is: operation [source],[destination] then your jumps should have something before an included comma, to put the destination in the right field: jmp $,destination ; $ alone in assembler means "here" That would be crazy of course, since the source is implicit, and it would suggest you can somehow jump from other places. But not doing it makes the language inconsistent. Intel's destination-first syntax gets around that by lopping off the end instead of something from the middle. This is the same for other opcodes like INC and DEC (increment and decrement) where the source is implied by the destination where the answer is stored. Somehow that never occurred to me, and now I can't not notice it. PUSH and POP kinda mess this up for either format though, since PUSH points to a source, and POP points to a destination. So for consistency, one of them is always backward. It's still less typing. Also I'd (lightly) rebut the claim that Intel's assembler needs 2 steps to make a binary, and MASM doesn't. The Microsoft DOS compilers have a command line switch to invoke the linker for you. Intel's assembler doesn't, like the article says, but if you compile with the make command instead, you accomplish the same thing. Also, Intel's compiler is actually 'as' and not 'gas.' GNU utils used to name it gas, but I only ever see it referred to as the original 'as' these days, and even then, it's linked (the file system type of link... now it's getting confusing!) to a binary with the target architecture in the name. But no 'gas'. This might have happened after the article was written, though.
  - souprock 6y ago
    For the jmp instruction, both source and destination are the rip register. That other thing is an immediate value. Really jmp is just mov or add, with the rip register. Like so: movq somelabel, %rip addq somelabel-%rip, %rip mov rip, _somelabel add rip, _somelabel-rip
    - ksaj 6y ago
      It was never legal to jump that way, though. And it wouldn't make sense if it was allowed by the cpu for your jump source to be somewhere you haven't been yet. So the $ "here" makes more sense, at least to me. Literally "from here, to there" versus "from there, to there." Here's a similar "illegal" re-envisioning of a call: push rip mov rip, _interrupt ; a weird illegal jump ... _interrupt: ... pop rip ; similarly illegal way to RET The workings are the same, but the cpu won't let you write it that way of course. The source and destination are still clear and intact because you start by pushing the source onto the stack before giving the destination, so it's at least good for demonstrating that bit of near-consistency in the Intel syntax. Part of the reason these rip shenanigans aren't allowed is because you'd have a hell of a time jumping or calling to a different SEG (segment), as INT always does, and the jumps can do if you need them to, because you'd have to push change the index pointer and the segment at the same time somehow. So you'd be limited to .COM (single segment memory images) file format with no interrupts if that's how you wanted to go about doing them. Simply "editing" rip, if you could, would stick you to a single memory segment.
kristianp 6y ago
At the moment this question is closed as "opinion based". Which is ridiculous. There really needs to be a better scheme for how questions are closed. It's way too easy for questions to be closed for spurious reasons and the current method of reopening them is too hard. The question is asking for historical information, not an opinion.
- kstrauser 6y ago
  I generally love Stack Overflow, and have been active on it for ages, but there are a huge number of mods who see it as their life mission to close as many questions as possible. See also: Wikipedia deletionists.
  - Twixes 6y ago
    Just… why?
    - weujruerwuwe 6y ago
      Pairing of an ego fed by making "contributions" to the community with an inability to contribute in a way that adds to the knowledge base.
      - indeedmug 6y ago
        It seems like it's wrong that removing contributions would count as a contribution.
        T-hawk 6y ago
        As programmers, aren't we proud when we can get rid of lots of code?
        coldtea 6y ago
        Not if we randomly yank good code
salicideblock 6y ago
I have no info, speculating: could it be to reuse the existing programmer's knowledge and code corpus when porting Unix from PDP-11 to x86 machines? This is assuming that AT&T valued similarity with existing Unix assembly codebases more than it valued similarity with existing external x86 assembly codebases.
- skissane 6y ago
  My speculation: they took their PDP-11 assembler and modified it to make an x86 assembler. Using a PDP-11-inspired syntax, instead of Intel syntax, reduced the number of code changes required.
codetrotter 6y ago
> While Intel always used a dst, src operand ordering for its assembler, there was no particularly compelling reason to adapt this convention and the UNIX assembler was written to use the src, dst operand ordering known from the PDP11. Tangential but I like to see this as sort of two ways of thinking where the operands are in both cases ordered so that what you “have” is closer to “you”. So in Intel syntax it’s like you are thinking from the CPU perspective and what you “have” are places that you want to put data into. So dst, src. In AT&T syntax it’s like you are thinking from the perspective of a program, and what you “have” is data that you want to put into places. So src, dst. I’m not suggesting that this is the reason mind you. Just saying how I like to think about it.
- JJMcJ 6y ago
  Unix on DEC hardware originally predates even the Intel 4004, so of course they used the DEC standard. Also, GNU as assembler has switches to allow Intel syntax if that's what is desired.
  - pjmlp 6y ago
    It wasn't always like that, and I am sure it isn't at the same level as nasm/yasm/masm/tasm.
- Someone 6y ago
  If that’s true, most programming languages work from the CPU perspective. I think that suggests the syntax may have come from consistency with “A = B” in programming languages (similar to the initially weird looking argument order of strcpy and friends in C), or, maybe, programming languages followed what assemblers did, or the two are similar because of some other common reason. What I don’t like about Intel’s syntax is that the normal phrase is ‘move A to B’, but ‘mov A, B’ moves what’s in B to A. (The reason I don’t like it may be because the first CPU I programmed was a 6502, which had separate load and store instructions. Unfortunately, that doesn’t work well with memory-to-memory (which the 6502 doesn’t have) or register to-register (for which the 6502 used a T for ‘transfer’, as in TXA for ‘copy X register into Accumulator) instructions)
csense 6y ago
Having looked at a fair amount of AT&T syntax assembly code over the years, the sheer nonsensicalness of the AT&T syntax cannot be understated. You seriously want to argue that disp(base,index,scale) is clearer than [disp+base+index*scale]? Is there any excuse, other than sheer laziness on the part of the parser writer, to require EVERY NUMERIC CONSTANT to be prefixed with a # and EVERY REGISTER to be prefixed with the percent sign? So I can confidently say that the purpose of AT&T syntax was to make assembly programmers want to gouge their eyes out.
- nn3 6y ago
  For the registers the % prefix avoids needing to add some prefix to every symbol. Otherwise you couldn't have symbols with the same names as registers. Not sure what you mean with every numeric constant prefixed with #. That's not the case on x86 AT&T assembly. Immediates require $, but that's the same as the Intel syntax.
  - jwilk 6y ago
    > Immediates require $, but that's the same as the Intel syntax. No, "$" is not needed (or even allowed) for immediates in Intel syntax.
    - adrian_b 6y ago
      Any assembly language needs to distinguish between immediate values and addresses. So you need a prefix on one of them, unless you use different mnemonics for the same operation, depending on whether it uses an immediate value or a memory operand. Doubling the number of operation mnemonics is clearly worse than having a single prefix. The prefix should be required for the less frequent case, and that is normally the use of immediate values. The Intel syntax as seen in the Intel architecture manuals is somewhat simplified, because it does not contain symbols and expressions. The complete assembly language syntax, for example the one implemented by the Microsoft MASM, needs frequently to distinguish the immediate values. Because MASM followed the Intel manuals, it did not use a prefix on immediate values but instead it used ugly and verbose prefixes on the memory operands, e.g. "WORD PTR ". In order to avoid excessive verbosity, MASM omitted the memory operand prefix in many cases where immediate values could not be used, which is possible only because the Intel instruction set is much less orthogonal than almost any other instruction set. Always using a prefix to distinguish immediate values from addresses is preferable to the inconsistent MASM method, because it can be tricky to remember which instructions can or cannot have both immediate operands and memory operands, so that the prefix is mandatory. Moreover, later ISA extensions could also change the available addressing modes for an operation, possibly mandating the use of the prefix. In conclusion, the MASM way of distinguishing the immediate values, by using "WORD PTR ", "BYTE PTR " and other similar prefixes on many but not all of the memory operands is certainly worse than always using the prefix "$" on immediate values.
amenghra 6y ago
It would have been more clear to adopt an arrow notation: mov a => b vs mov b <= a Then you could support both forms at the same time :)
- enriquto 6y ago
  I cannot help but to read these as "larger than or equal" and "smaller than or equal". Maybe use -> and <- ? Or yet better, unicode arrows: ← → ⇐ ⇒
  - mhh__ 6y ago
    If you think a CPU will do that for you for free you're in for a shock so it doesn't really matter.
- Someone 6y ago
  If you do that, drop the ‘mov’. Before you know it you have a rudimentary programming language with a bunch of special variables, one for each register, and the ability to introduce other names for memory regions. From there, an improvement could be to allow, say R1 = R1 + R2 + R3 even when that requires two instructions.
  - wyldfire 6y ago
    The intent of assembly is to avoid this kind of complexity. However, there's nothing wrong with having the assembly language mnemonics/operators be symbolic. `R1 = R1 + R2` is an acceptable way to represent your architecture's add instruction. You can't support arbitrary expressions of registers (but assemble-time constant expressions are usually ok). > even when that requires two instructions. In fact, some assemblers do provide assembler-mapped instructions or other similar features like this. The inverse is also possible: assembler optimizations to collapse multiple independent instructions into a single one.
    - Someone 6y ago
      > You can't support arbitrary expressions of registers > In fact, some assemblers do provide assembler-mapped instructions or other similar features like this. So, which is it :-) ? I think you know both are true, but for those who don’t: The original intent of assembly was to make it easier to encode instructions. Those assemblers provided a 1:1 mapping between assembly instructions and CPU instructions. (There may even have been assemblers that map assembly instructions 1:1 on machine words, but I think declaration of multi word memory regions was a very early addition. It’s so much more natural to write “give me 10 zero-initialized bytes here” than to write ten statements “give me a zero-initialized byte here” So, that’s your first statement. Macro assemblers (aka high-level assemblers) give you the second one. They let you write macros that, for example, add multi-word addition loops to your (now virtual) instruction set. https://en.wikipedia.org/wiki/High-level_assembler https://en.wikipedia.org/wiki/High-level_assembler: “High-level assemblers typically provide instructions that directly assemble one-to-one into low-level machine code as in any assembler, plus control statements such as IF, WHILE, REPEAT...UNTIL, and FOR, macros, and other enhancements. This allows the use of high-level control statement abstractions wherever maximal speed or minimal space is not essential; low-level statements that assemble directly to machine code can be used to produce the fastest or shortest code. The end result is assembly source code that is far more readable than standard assembly code while preserving the efficiency inherent with using assembly language. High-level assemblers generally provide information-hiding facilities and the ability to call functions and procedures using a high-level-like syntax (i.e., the assembler automatically produces code to push parameters on the stack rather than the programmer having to manually write the code to do this). High-level assemblers also provide data abstractions normally found in high-level languages. Examples include structures, unions, classes, and sets. Some high-level assemblers (e.g., TASM and HLA) support object-oriented programming.”
pjmlp 6y ago
I hate it with passion, porting Intel Assembly to AT&T back when gas couldn't support it properly was a very dumb decision. I should have kept using nasm.

108 points by luu 6y ago

My guess is someone long ago decided to "be different" for whatever capricious reason, since I don't think the syntaxes for any other architectures are different from what's in the official manuals. Related article: http://x86asm.net/articles/what-i-dislike-about-gas/ http://x86asm.net/articles/what-i-dislike-about-gas/

ksaj 6y ago
That article is from 2007, so I don't think we're going to get that promised update any time soon. I really wish they would have gotten around to it, because toward the end they say: "Another GAS's problem is that it still keeps very old standards, not all of which are the best choice." I'd love to see some examples of those poor choice standards compared in similar fashion as the article's earlier examples. That would be pretty interesting. They might also be updated since then. Can't know without examples. Their argument about jumps was a little bit brilliant. If your syntax (like AT&T's "gas") is: operation [source],[destination] then your jumps should have something before an included comma, to put the destination in the right field: jmp $,destination ; $ alone in assembler means "here" That would be crazy of course, since the source is implicit, and it would suggest you can somehow jump from other places. But not doing it makes the language inconsistent. Intel's destination-first syntax gets around that by lopping off the end instead of something from the middle. This is the same for other opcodes like INC and DEC (increment and decrement) where the source is implied by the destination where the answer is stored. Somehow that never occurred to me, and now I can't not notice it. PUSH and POP kinda mess this up for either format though, since PUSH points to a source, and POP points to a destination. So for consistency, one of them is always backward. It's still less typing. Also I'd (lightly) rebut the claim that Intel's assembler needs 2 steps to make a binary, and MASM doesn't. The Microsoft DOS compilers have a command line switch to invoke the linker for you. Intel's assembler doesn't, like the article says, but if you compile with the make command instead, you accomplish the same thing. Also, Intel's compiler is actually 'as' and not 'gas.' GNU utils used to name it gas, but I only ever see it referred to as the original 'as' these days, and even then, it's linked (the file system type of link... now it's getting confusing!) to a binary with the target architecture in the name. But no 'gas'. This might have happened after the article was written, though.
- souprock 6y ago
  For the jmp instruction, both source and destination are the rip register. That other thing is an immediate value. Really jmp is just mov or add, with the rip register. Like so: movq somelabel, %rip addq somelabel-%rip, %rip mov rip, _somelabel add rip, _somelabel-rip
  - ksaj 6y ago
    It was never legal to jump that way, though. And it wouldn't make sense if it was allowed by the cpu for your jump source to be somewhere you haven't been yet. So the $ "here" makes more sense, at least to me. Literally "from here, to there" versus "from there, to there." Here's a similar "illegal" re-envisioning of a call: push rip mov rip, _interrupt ; a weird illegal jump ... _interrupt: ... pop rip ; similarly illegal way to RET The workings are the same, but the cpu won't let you write it that way of course. The source and destination are still clear and intact because you start by pushing the source onto the stack before giving the destination, so it's at least good for demonstrating that bit of near-consistency in the Intel syntax. Part of the reason these rip shenanigans aren't allowed is because you'd have a hell of a time jumping or calling to a different SEG (segment), as INT always does, and the jumps can do if you need them to, because you'd have to push change the index pointer and the segment at the same time somehow. So you'd be limited to .COM (single segment memory images) file format with no interrupts if that's how you wanted to go about doing them. Simply "editing" rip, if you could, would stick you to a single memory segment.

kristianp 6y ago

At the moment this question is closed as "opinion based". Which is ridiculous. There really needs to be a better scheme for how questions are closed. It's way too easy for questions to be closed for spurious reasons and the current method of reopening them is too hard. The question is asking for historical information, not an opinion.

kstrauser 6y ago
I generally love Stack Overflow, and have been active on it for ages, but there are a huge number of mods who see it as their life mission to close as many questions as possible. See also: Wikipedia deletionists.
- Twixes 6y ago
  Just… why?
  - weujruerwuwe 6y ago
    Pairing of an ego fed by making "contributions" to the community with an inability to contribute in a way that adds to the knowledge base.
    - indeedmug 6y ago
      It seems like it's wrong that removing contributions would count as a contribution.
      - T-hawk 6y ago
        As programmers, aren't we proud when we can get rid of lots of code?
        coldtea 6y ago
        Not if we randomly yank good code

salicideblock 6y ago

I have no info, speculating: could it be to reuse the existing programmer's knowledge and code corpus when porting Unix from PDP-11 to x86 machines? This is assuming that AT&T valued similarity with existing Unix assembly codebases more than it valued similarity with existing external x86 assembly codebases.

skissane 6y ago
My speculation: they took their PDP-11 assembler and modified it to make an x86 assembler. Using a PDP-11-inspired syntax, instead of Intel syntax, reduced the number of code changes required.

codetrotter 6y ago

> While Intel always used a dst, src operand ordering for its assembler, there was no particularly compelling reason to adapt this convention and the UNIX assembler was written to use the src, dst operand ordering known from the PDP11. Tangential but I like to see this as sort of two ways of thinking where the operands are in both cases ordered so that what you “have” is closer to “you”. So in Intel syntax it’s like you are thinking from the CPU perspective and what you “have” are places that you want to put data into. So dst, src. In AT&T syntax it’s like you are thinking from the perspective of a program, and what you “have” is data that you want to put into places. So src, dst. I’m not suggesting that this is the reason mind you. Just saying how I like to think about it.

JJMcJ 6y ago
Unix on DEC hardware originally predates even the Intel 4004, so of course they used the DEC standard. Also, GNU as assembler has switches to allow Intel syntax if that's what is desired.
- pjmlp 6y ago
  It wasn't always like that, and I am sure it isn't at the same level as nasm/yasm/masm/tasm.
Someone 6y ago
If that’s true, most programming languages work from the CPU perspective. I think that suggests the syntax may have come from consistency with “A = B” in programming languages (similar to the initially weird looking argument order of strcpy and friends in C), or, maybe, programming languages followed what assemblers did, or the two are similar because of some other common reason. What I don’t like about Intel’s syntax is that the normal phrase is ‘move A to B’, but ‘mov A, B’ moves what’s in B to A. (The reason I don’t like it may be because the first CPU I programmed was a 6502, which had separate load and store instructions. Unfortunately, that doesn’t work well with memory-to-memory (which the 6502 doesn’t have) or register to-register (for which the 6502 used a T for ‘transfer’, as in TXA for ‘copy X register into Accumulator) instructions)

csense 6y ago

Having looked at a fair amount of AT&T syntax assembly code over the years, the sheer nonsensicalness of the AT&T syntax cannot be understated. You seriously want to argue that disp(base,index,scale) is clearer than [disp+base+index*scale]? Is there any excuse, other than sheer laziness on the part of the parser writer, to require EVERY NUMERIC CONSTANT to be prefixed with a # and EVERY REGISTER to be prefixed with the percent sign? So I can confidently say that the purpose of AT&T syntax was to make assembly programmers want to gouge their eyes out.

nn3 6y ago
For the registers the % prefix avoids needing to add some prefix to every symbol. Otherwise you couldn't have symbols with the same names as registers. Not sure what you mean with every numeric constant prefixed with #. That's not the case on x86 AT&T assembly. Immediates require $, but that's the same as the Intel syntax.
- jwilk 6y ago
  > Immediates require $, but that's the same as the Intel syntax. No, "$" is not needed (or even allowed) for immediates in Intel syntax.
  - adrian_b 6y ago
    Any assembly language needs to distinguish between immediate values and addresses. So you need a prefix on one of them, unless you use different mnemonics for the same operation, depending on whether it uses an immediate value or a memory operand. Doubling the number of operation mnemonics is clearly worse than having a single prefix. The prefix should be required for the less frequent case, and that is normally the use of immediate values. The Intel syntax as seen in the Intel architecture manuals is somewhat simplified, because it does not contain symbols and expressions. The complete assembly language syntax, for example the one implemented by the Microsoft MASM, needs frequently to distinguish the immediate values. Because MASM followed the Intel manuals, it did not use a prefix on immediate values but instead it used ugly and verbose prefixes on the memory operands, e.g. "WORD PTR ". In order to avoid excessive verbosity, MASM omitted the memory operand prefix in many cases where immediate values could not be used, which is possible only because the Intel instruction set is much less orthogonal than almost any other instruction set. Always using a prefix to distinguish immediate values from addresses is preferable to the inconsistent MASM method, because it can be tricky to remember which instructions can or cannot have both immediate operands and memory operands, so that the prefix is mandatory. Moreover, later ISA extensions could also change the available addressing modes for an operation, possibly mandating the use of the prefix. In conclusion, the MASM way of distinguishing the immediate values, by using "WORD PTR ", "BYTE PTR " and other similar prefixes on many but not all of the memory operands is certainly worse than always using the prefix "$" on immediate values.

amenghra 6y ago

It would have been more clear to adopt an arrow notation: mov a => b vs mov b <= a Then you could support both forms at the same time :)

enriquto 6y ago
I cannot help but to read these as "larger than or equal" and "smaller than or equal". Maybe use -> and <- ? Or yet better, unicode arrows: ← → ⇐ ⇒
- mhh__ 6y ago
  If you think a CPU will do that for you for free you're in for a shock so it doesn't really matter.
Someone 6y ago
If you do that, drop the ‘mov’. Before you know it you have a rudimentary programming language with a bunch of special variables, one for each register, and the ability to introduce other names for memory regions. From there, an improvement could be to allow, say R1 = R1 + R2 + R3 even when that requires two instructions.
- wyldfire 6y ago
  The intent of assembly is to avoid this kind of complexity. However, there's nothing wrong with having the assembly language mnemonics/operators be symbolic. `R1 = R1 + R2` is an acceptable way to represent your architecture's add instruction. You can't support arbitrary expressions of registers (but assemble-time constant expressions are usually ok). > even when that requires two instructions. In fact, some assemblers do provide assembler-mapped instructions or other similar features like this. The inverse is also possible: assembler optimizations to collapse multiple independent instructions into a single one.
  - Someone 6y ago
    > You can't support arbitrary expressions of registers > In fact, some assemblers do provide assembler-mapped instructions or other similar features like this. So, which is it :-) ? I think you know both are true, but for those who don’t: The original intent of assembly was to make it easier to encode instructions. Those assemblers provided a 1:1 mapping between assembly instructions and CPU instructions. (There may even have been assemblers that map assembly instructions 1:1 on machine words, but I think declaration of multi word memory regions was a very early addition. It’s so much more natural to write “give me 10 zero-initialized bytes here” than to write ten statements “give me a zero-initialized byte here” So, that’s your first statement. Macro assemblers (aka high-level assemblers) give you the second one. They let you write macros that, for example, add multi-word addition loops to your (now virtual) instruction set. https://en.wikipedia.org/wiki/High-level_assembler https://en.wikipedia.org/wiki/High-level_assembler: “High-level assemblers typically provide instructions that directly assemble one-to-one into low-level machine code as in any assembler, plus control statements such as IF, WHILE, REPEAT...UNTIL, and FOR, macros, and other enhancements. This allows the use of high-level control statement abstractions wherever maximal speed or minimal space is not essential; low-level statements that assemble directly to machine code can be used to produce the fastest or shortest code. The end result is assembly source code that is far more readable than standard assembly code while preserving the efficiency inherent with using assembly language. High-level assemblers generally provide information-hiding facilities and the ability to call functions and procedures using a high-level-like syntax (i.e., the assembler automatically produces code to push parameters on the stack rather than the programmer having to manually write the code to do this). High-level assemblers also provide data abstractions normally found in high-level languages. Examples include structures, unions, classes, and sets. Some high-level assemblers (e.g., TASM and HLA) support object-oriented programming.”

pjmlp 6y ago

I hate it with passion, porting Intel Assembly to AT&T back when gas couldn't support it properly was a very dumb decision. I should have kept using nasm.