From: not_valid@nospicedham.comcast.net   
      
   "wolfgang kern"  wrote in message news:oktgen$14gj$2@gioia.aioe.org...   
      
   I seem to recall that you are the contributor to this forum who can   
   write x86 assembly code without reference to opcode tables.  I will   
   try to learn from your post and make a few remarks along the way.   
      
   > James Van Buskirk wrote:   
      
   > >> Kind of funny that Intel should list RAX, RCX, RDX, RBX, RSP, RBP, RSI,   
   > >> and RDI   
   > >> in the wrong order in Fig. 1 :)   
      
   > > Just to follow up on my own message, it may seem that the order only   
   > > has meaning for really low-level code where the programmer is looking   
   > > at the machine language, but consider what happens with 64-bit   
   > > addressing: format MS64   
      
   > [list of opcodes ..]   
      
   > not much changed from 16-bit to 32-bit to 64-bit opcodes:   
      
   > register numbers within opcodes remained (except for specials)   
   > r/eax=0 r/ecx=1 r/edx=0 r/ebx=3 r/esp=4 r/ebp=5 r/esi=6 r/edi=7   
      
   To correct your typo, r/edx=2   
      
   > the specials are: 06 in 16 bit mode means [address]   
   > 05 in 32 bit mode means [address], RIP in 64 bit mode 04 in 32/64 modes   
   > mean SIB and 64 bit mode allow also Zxd 32 or full 64-bit beside access to   
   > all the low bytes from GP-regs.   
      
   I would say that any kind of usage of the mod r/m byte to reference   
   memory in 16-bit mode is a special case compared to 32-bit mode   
   where you can do anything except use ESP as a scaled index.  You   
   know, I learned low level programming, which to me includes   
   machine language, assembly language, and C by reading and writing   
   the ROM for my calculator which had a SC-62015 processor.  Had   
   it been an 8088, I don't think I would have ever figured out the   
   instruction set without any documentation.  Of course, the original   
   PC came with DEBUG.COM so you wouldn't have to embark on   
   such an exercise in that context.   
      
   Since impressionable minds may be reading this post I think it may   
   be worthwhile to point out that the 16-bit addressing modes aren't   
   at all available in 64-bit mode as the 67h address size prefix means   
   to AND the effective address with 00000000FFFFFFFFh.  Also any REX   
   prefix maps   
      
   AL CL DL BL AH CH DH BH **not available**   
      
   to   
      
   AL CL DL BL SPL BPL SIL DIL R8B R9B R10B R11B R12B R13B R14B R15B   
      
   So you can't use the middle registers (AH CH DH BH) in an instruction   
   that requires a REX prefix.   
      
   > > the above listing generated by FASM, it can be seen that   
   > > we can't address off of RSP without an SIB byte because the   
   > > mod r/m encoding that would correspond to RSP instead   
   > > call out the presence of an SIB byte, so an SIB byte is required   
   > > even for an effective address of [RSP+offset].  This is echoed   
   > > with R12.   
      
   > Have you ever tried 48 8b 24 24  MOV RSP,[RSP] ? (64 bit)   
      
   Let's see... from 325642.pdf, Table 2-4 Vol 2A, p. 2-9:   
   48 = 0100 1000   
        *REX WRXB   
   The high 4 bits indicate a REX prefix and the REX.W bit is set   
   indicating a MOV into RSP rather than into ESP.  The REX.R bit   
   is clear indicating the MOV is into RSP rather than R12.  The   
   REX.X bit is clear, but this is a don't care because the SIB byte   
   indicates no index register will be used.  The REX.B bit is clear,   
   indicating the base register use to form the address will be   
   RSP rather than R12.   
      
   Next is 8b, which from 325462.pdf, Vol. 2A, p. 3-525 indicates   
   that REX.W + 8b /r is the opcode MOV r64, r/m64, requiring a   
   mod r/m byte, which is   
      
   24 = 00 100 100   
       Mod reg R/M   
   The reg field is 100; combined with the REX.R bit = 0, we see that   
   the full register to receive the MOV is RSP = 0100.   
   With a Mod field of 00 and an R/M field of 100, we see from   
   325462.pdf, Table 2-2, Vol. 2A, p. 2-6 that this means the   
   effective address will be formed from an SIB byte with no   
   displacement.  The SIB byte is   
      
   24 = 00   100  100   
        SS Index Base   
   As seen in 325462.pdf, Table 2-3, Vol 2A, p. 2-7, the scale field   
   is 00 which is actually a don't care because no index register   
   will be used.  The index field is 100, which means that no   
   index register will be used.  the base field is 100, which   
   combined with the REX.B bit of 0 indicates that the full   
   base register is RSP = 0100.   
      
   You can see why I say I probably could never have figured   
   out the machine language with no help on x86 the way I   
   did with the SC-62015, especially considering the implicit   
   or explicit use of segment registers in real mode.   
      
   > > Similarly, the encoding for an effective address of [RBP]   
   > > ends up being occupied by [RIP+offset] so you need to   
   > > specify an effective address of [RBP+0] to encode [RBP].   
   > > Again, this is echoed with R13.   
      
   > yes, but we can have both:   
      
   > 48 8b 45 00  MOV RAX,[RBP+0]  almost same issue as 16 bit   
   > 8b 46 00     MOV ax,[bp+0]   
      
   Right, 325462.pdf, Table 2-1, Vol. 2A, p. 2-5 shows no [BP]   
   encoding in 16-bit addresses.  Of course no [AX], [CX], [DX],   
   or [SP] either.   
      
   > 48 8b 05 04 03 02 01    MOV RAX,[RIP+0x01020304] in 64bit 8b 05 01 02 03   
   > 04       MOV eax,[0x04030201]   
      
   I had trouble with that last instruction until I realized that   
   you meant that it ran in 32-bit mode.  In 64-bit mode I gather   
   that it would be something like   
   8b 04 25 01 02 03 04  MOV eax, [Z'04030201']   
      
   The addresses that can be formed from an immediate alone   
   in 64-bit mode don't seem to be all that useful in that they   
   only allow access to the low or high 2 GB of memory, or   
   the low 4 GB with a 67h address-size override prefix.  I   
   suppose with something like an FS or GS prefix they could   
   index into some data structure like a GOT.   
      
   > > If you didn't know the register order, you wouldn't know   
   > > that addressing off of R12 and R13 is a little funky like   
   > > addressing off of RSP and RBP, so you might and end with   
   > > some longer encodings than you would if you planned   
   > > register allocations taking this into account.   
      
   > Yes, so whenever you program for 64-bit you should know the difference to   
   > 32bit code.   
   > smart tools will anyway show what's possible and what's not.   
      
   Thanks for the informative post on x86 opcodes.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)