From: muta...@gmail.com   
      
   On Friday, July 16, 2021 at 1:09:31 PM UTC+10, Joe Monk wrote:   
      
   > > This is a feature of the assembler. The assembler on the   
   > > mainframe recognizes the LGR and generates a different   
   > > opcode, even though the registers are identically named.   
      
   > LR is OPCODE 18. OPCODE 18 is ALWAYS a 32-bit operation.   
   > LGR is OPCODE B904. OPCODE B904 is ALWAYS a 64-bit operation.   
      
   Sure. And the 8-bit, 16-bit and 32-bit operations done   
   in mov al/ah/ax/eax also have unique opcodes.   
      
   > So just looking at the opcode I know what is going on...   
      
   You do in 80386 machine code too. The CPU wouldn't   
   recognize the instruction correctly if the opcode wasn't   
   correct.   
      
   > By contrast, the MOV instruction is context sensitive.   
   > MOV EAX? 32 bit operation. MOV AX? 16-bit operation.   
   > MOV AH? 8-bit operation. MOV is always opcode B8.   
   > But just looking at the opcode do I know if I am moving   
   > 8 bits, 16 bits or 32 bits? No.   
      
   This is a feature of the assembler, and can easily be   
   changed if you don't like it.   
      
   You can code mov.b and mov.w and mov.l if you prefer   
   (some people do prefer).   
      
   > Thats why IBM object code is so much easier to work with than x86.   
      
   Nope. For starters, most people don't look at the object   
   code. But for those that do, it's a minor issue to look up   
   what each opcode does.   
      
   > And thats why the two machines are worlds apart and dont operate in the same   
   way.   
      
   Nope. The machines are near-identical Turing machines   
   when looked at from the perspective of a C90-compliant   
   application.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)