MASM 1.0 had a linear symbol table, which meant it quickly got excruciatingly slow as the file size increased.
MASM also uses the syntax one finds in the Intel CPU reference manuals. This is also done in the inline assembler for my compilers.
The gnu assembler syntax reverses the operands, which reverses the operands. This drives me crazy because assembler is hard enough without all the bugs from putting the operands in the wrong order.
Besides, I much prefer to be able to compare my assembler code with the Intel CPU specification.
One day I had the stupid idea to replace the nasm macros of my toy compiler with generated Assembly directly, and to reduce dependencies rely on gas, back when Intel syntax was hardly supported, so AT&T it was.
Using a 'JMP SHORT' was pretty much reflexive; a good reason to do it was it not being in range was sort of a code smell back in the day.
But chips were simpler back then, and a programmer could often leave compiler code in the dust with small bits of assembler (esp. where Fortran was involved).
Nowadays, X86 has become so hard to reason about from a performance point of view that for critical code I just assume that GCC will emit something acceptable given a bit of sensibly-written C, and that to get a big boost beyond that is going to involves GPUs or custom silicon (depending on the application).
Since it's not completely spelled out in the article, MASM was (is?) the Microsoft Macro Assembler. This is an x86 assembler that's been around since pretty much the beginning of the architecture.
Yes, it still is. It's no longer supplied separately and instead is included in Visual Studio (or in the "Build Tools for Visual Studio"), but it is still there. Newer, 64-bit, version is called ML64 but still referred to as MASM/Macro Assembler.
MASM also uses the syntax one finds in the Intel CPU reference manuals. This is also done in the inline assembler for my compilers.
The gnu assembler syntax reverses the operands, which reverses the operands. This drives me crazy because assembler is hard enough without all the bugs from putting the operands in the wrong order.
Besides, I much prefer to be able to compare my assembler code with the Intel CPU specification.