[HN Gopher] Explaining how the MASM 2-pass assembler works
       ___________________________________________________________________
        
       Explaining how the MASM 2-pass assembler works
        
       Author : rwmj
       Score  : 39 points
       Date   : 2021-09-12 17:04 UTC (5 hours ago)
        
 (HTM) web link (www.os2museum.com)
 (TXT) w3m dump (www.os2museum.com)
        
       | cdcarter wrote:
       | 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.
        
         | genezeta wrote:
         | > (is?)
         | 
         | 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.
        
       | zh3 wrote:
       | 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).
        
         | sitzkrieg wrote:
         | very true, esp when using const, static or restrict correctly
        
       | WalterBright wrote:
       | 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.
        
         | blake1 wrote:
         | I strongly agree with your last sentence, but the issue goes
         | beyond operand order: the addressing syntax for AT&T is nigh
         | incomprehensible to me.
        
         | mhh__ wrote:
         | Angels die when AT&T syntax is used. I genuinely hate it.
        
           | pjmlp wrote:
           | 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.
           | 
           | Never again.
        
       ___________________________________________________________________
       (page generated 2021-09-12 23:00 UTC)