From: luser.droog@nospicedham.gmail.com   
      
   On Tuesday, September 15, 2020 at 3:32:03 AM UTC-5, wolfgang kern wrote:   
   > On 14.09.2020 19:15, luserdroog wrote:   
      
   > > I said this wrong. These are "to" forms, not "from". The first   
   > > argument to my CMP macro can be F to create a "from" opcode or blank   
   > > (as above) to create a "to" opcode. Elsethread I mentioned the   
   > > expanded operator function listed in my codegolf answer, that should   
   > > be "addbf" (the "from" form) not "addbt". Sigh. addbf (add byte from)   
   > > being opcode 0x00.   
   >   
   > Why easy when you can make it complicated ?   
   > what's wrong with the assembler syntax used by NASM,FASM,..(long list)   
   > and also AMD and Intel in their docs ?   
   >   
   > sorry if the lines wrap   
      
   The whole idea of this project was to build something running on top   
   of the 8086 emulator. This was to exercise the emulator and shake   
   out bugs, but also to motivate implementing more opcodes.   
      
   For the assembler part, I wanted to put the assembled bytes into a C   
   data structure. I also wanted complete control over the exact encoding   
   of the opcodes, mostly so I could make sure it was using codes that   
   are actually implemented in the emulator.   
      
   For these reasons, the best choice I could think of was to make the   
   assembler with C preprocessor macros that yield a comma separated   
   list of byte values. One advantage of this approach is that I can   
   design the *machine code* to be (somewhat) readable. I put opcodes   
   in hex, M/R/R-M bytes in octal, and offsets in decimal.   
      
   "We choose to do these things not because they are easy, but because   
   they are hard."   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)