And I'm guessing Intel didn't invent doing it backwards in their own either.

https://en.wikipedia.org/wiki/X86_assembly_language#Syntax

"The AT&T syntax is nearly universal to all other architectures with the same mov order; it was originally a syntax for PDP-11 assembly. The Intel syntax is specific to the x86 architecture, and is the one used in the x86 platform's documentation."

https://en.wikipedia.org/wiki/As_(Unix)

"As of November 1971, an assembler invoked as as was available for Unix. Implemented by Bell Labs staff, it was based upon the Digital Equipment Corporation's PAL-11R assembler."

> The AT&T folks did not even wait for Intel's assembler [...] Nor did they closely model their assembler after it. They just took the assembler they already had for the PDP-11 and adapted it with minimal changes for the 8086.

But even then, you have worlds converging. The 8086 was (barely) capable of running Unix, whereas the Z-80 definitely was not. Was the 8086 a part of the PDP-11 minicomputer world, or was it part of the 8080/Z-80 world? Well, it was both. Complaining that one world produced an assembler before the other did is... a bit exclusivist. Also whiny.

https://github.com/chettrick/uzics

You're wrong ;-)

Neither the 8086 nor the Z80 have virtual memory. The x86 has a larger instruction set and address space (1MB) but as it turns out, early Unix kernels didn't need that much RAM either.

  op src dest 

That is logic.

Ergo op src dest

"Add 4 to x and store result in x" vs "Let x be x + 4"?

So "add 4 coins to that bucket", generally means at the end of that operation the bucket contains at least four coins plus any coins that were already in the bucket.

You know what the logical convention to use would have been? The order that every assembler on the planet already used.

The only reason “AT&T syntax” exists for x86 is because people working at AT&T refused to accept Intel’s manual as the authoritative reference on the syntax, and, instead, decided to follow the convention of the PDP, Motorola, etc. family and friends. Hence why `as` (and subsequently `gas`) have that as the default.

At least the Intel one makes actual mathematical sense: `section:[base + index*scale + disp]`

I quite like the SSA style which tends to be dst0 dst1 opcode src0 src1 but that doesn't model assembly brilliantly. Perhaps that order with read-write arguments required to appear on both sides of opcode with the same symbol has some merit.

https://blog.yossarian.net/2020/06/13/How-x86_64-addresses-m...

They're using a dollar sign for immediates.

As if you can't notice that it's a number.

    addl $4, %eax

- the operation width is provided by the registry

- a number is an immediate

- a register is named

Hence the much less noisy Intel syntax:

    add eax, 4

    add $4, %eax

Compare with

    add 4, %eax

    add eax, DWORD PTR [4]

    add eax, [4]

    add eax, [4]       ; inferred
    add [eax], 4       ; ambiguous
    add DWORD [eax], 4 ; explicit

It's "AT&T syntax" because it dates to the 1978 AT&T Labs effort to port UNIX to the 8086. [1] While the 8086 did not have virtual memory or hardware protection, its memory segmentation model was still adequate to support UNIX, without those. It was the first microprocessor practically capable of running UNIX, and this was realized before the chip was even released. The porting effort started immediately. (Though most of the energy would soon switch to the 68000 when that was released a year later.)

The AT&T folks did not even wait for Intel's assembler. (Written in Fortran, to run on mainframes, or on Intel's development systems). Nor did they closely model their assembler after it. They just took the assembler they already had for the PDP-11 and adapted it with minimal changes for the 8086. Quick and dirty. Which was okay. You're not supposed to write assembly on UNIX systems, anyway. Only the poor people who had to write kernel drivers and compilers would ever have to deal with it.

[1] https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf (see section III)

XENIX for 386 was based on AT&T System V/386, which introduced the AT&T syntax to 32-bit x86. I've found some references to 32-bit XENIX still using an assembler called "masm" but I don't know if it was still based on Microsoft's MASM or just called that for compatibility, or whether it was AT&T or Intel syntax. Also by that point compilers and assemblers weren't included in the base OS anymore, but a "development kit" sold separately.

The Minix compiler and assembler also used Intel syntax.

There was also something called "SCO UNIX" which was apparently more of a straight adaptation of AT&T System V and might have used a pcc compiler and AT&T syntax. It's hard to figure out what happened when because there are a zillion different versions of Xenix/SCO Unix/OpenServer out there.

[1] https://www.scosales.com/ta/kb/100187.html

It was so expensive in Escudos, that for teaching an high school class about UNIX, the teacher would bring a tower (286 or early 386 model) that would be timeshared with the whole class, meaning taking 15 minute slots seating at it, while having prepared the exercises, as much as we could, in Turbo C 2.0 on MS-DOS.

It definitly wasn't SCO UNIX though.

That's how I think of it.

ALSO: I really do not like the MOV instruction; I much prefer LD. The Z-80 instruction names got everything mostly right.

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.

Cooperation with the linker comes with other directives and options. gas has tight cooperation with GNU ld via directives, not instruction syntax. It can actually be set to accept either AT&T or Intel syntax, without losing any support for other features.

Your accomplishments have zero to do with the ‘elite’ tooling you use (why are you gatekeeping and creating class distinctions out of assemblers?), and more that you’ve taken the time to really think about how memory is laid out and how the architecture works - which most of us who started out writing operating systems instead of Rails understand perfectly fine. Nothing about the relationship between gas and ld achieves uniqueness not seen in other native stacks. That’s just made up.

There are multiple operating systems built with hand written NASM. Arguing about assemblers like they matter for more than five seconds is tiring 1990s IRC stuff. They turn syntax into a byte layout. It’s like realizing oh, this assembler sucks at ELF, why don’t I just hand lay one out? and boom, you’re on the way to APE. And really, if you don’t like your assembler, an “elite” programmer would write their own, but that fell out of fashion before most of us were alive.

Given the knowledge it takes to write something like APE I know you know what I’m saying, too, so why are you misleading like this? It comes across like an overstretched attempt to promote your work for a reader who knows the stuff you’re talking about.

I didn’t think it ever really makes sense to disagree with a comment like this, unless one is claiming that the content of your comment is intentionally untrue. Anyways, appreciate your perspective.

Now you’re saying you were swayed by the idea that one shouldn’t use gas directly, which is an entirely different premise — and much more understandable.

You found a stack that worked for you to build APE. Those are your experiences. Pivoting those experiences to absolute observations about what is good or bad or elite is the error, here. And it’s ironic: you’re lamenting believing “the consensus” in your own journey while simultaneously influencing the consensus with conclusions that your available data didn’t earn. Passively responding to negative feedback toward positive replies suggests bad faith, too, so I’d ask if your contribution to the consensus is harmful, like those were that steered you another way.

I also bristle at a niche field having terms like “elite” used casually to influence people entering it, just like you were once upon a time, and I note you ignored that feedback in responding here. That’s also ironic because APE is challenging the idea of how native software is packaged and distributed, which itself requires outside the box thinking, and you’re using language and absolutist pronouncements to create a different box that has a right and wrong.

Your commentary here suggests to me that the loads of people waiting on you to change the world with APE might be waiting a while. That’s unfortunate and directly motivational.

As Stroustrup put it: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

[1]: https://en.wikipedia.org/wiki/McGill_University_School_of_Co...

[2]: https://www.cs.mcgill.ca/~ratzer/backup/welcome.html

[3]: https://mcgill.imodules.com/controls/email_marketing/view_in...

    cmp eax, ebx   ; eax ? ebx
    jg foo         ; jump if eax > ebx

        mov rax,%rax                                                            
  rax:  .ascii "hello\0"

I know that there are ways to ask GCC to emit one syntax or the other, as well as ways to assemble code in either syntax. However I don't know any program that just translates one to the other.

The one thing AT&T syntax has going for it is the "strong typing" of operand widths: `addl` is slightly more readable than `add` + operand-inferred width.

If you want the C preprocessor, you can have it with Intel syntax too (gas can use either), but I think the preprocessing syntax designed for assembly is cleaner with assembly code, and some of those preprocessors are surprisingly powerful.

After a few days, suddenly everything was right side up for the volunteer. Until he took the glasses off ...

The movie ended with a warning to never try this yourself.

Anyhow, I'm reminded of that movie every time I have to switch between AT&T vs Intel syntax. My brain just hurts, and the asm code I write is all wrong.

So, the dmd D compiler's inline assembler syntax is Intel regardless of the OS, and the builtin disassembler is Intel syntax.

https://www.madsci.org/posts/archives/mar97/858984531.Ns.r.h...

"""

[...] first investigated by George Stratton in the 1890 s

[...] he ran another experiment where he wore it for eight days in a row. On the fourth day, things seemed to be upright rather than inverted. On the fifth day, he was able to walk around his house fairly normally but he found that if he looked at objects very carefully, they again seemed to be inverted. On the whole, Stratton reported that his environment never really felt normal especially his body parts, although it was difficult to describe exactly how he felt. He also found that after removing the reversing lenses, it took several hours for his vision to return to normal.

[...]

"""