From: terje.mathisen@nospicedham.tmsw.no   
      
   James Harris wrote:   
   > On 22/07/2017 21:11, Bartc wrote:   
   >> On 22/07/2017 20:54, James Van Buskirk wrote:   
   >>> "Bartc"  wrote in message news:slMcB.398733$fp7.107811@fx39.am4...   
   >>   
   >>>> Otherwise you have these register names:   
   >>>   
   >>>>   8-bit     16-bit     32-bit    64-bit   
   >>>   
   >>>>   DIL       DI         EDX       RDX   
   >>>>   CL        CX         ECX       RDX   
   >>>>   R8L/R8B   R8W        R8D       R8   
   >>>   
   >>> Again, an obession:   
   >>>   
   >>>   8-bit     16-bit     32-bit    64-bit   
   >>>   
   >>>   DIL       DI         EDI       RDI   
   >>>   CL        CX         ECX       RCX   
   >>>   R8L/R8B   R8W        R8D       R8   
   >>   
   >> I think that demonstrates the trouble I have with the official   
   >> register names!   
   >   
   > Lots of history led to where we are now!   
   >   
   > I prefer plain numbering such as the IBM S360+ and others which simply   
   > call registers r0 to r15. (Sub-registers would need modifications but   
   > they could be logical and consistent.)   
   >   
   In x64, where the register set is pretty close to fully orthogonal, it   
   would have been nice to have simple reg numbers, but as long as you have   
   to know about the exceptions to those rules ("For this type of   
   instruction you save one or more opcode bytes if you can make sure to   
   use the originally intended registers") then anyone interested in both   
   size and speed optimization have to know their history as well as the   
   original register allocations.   
      
   Talk to any of the of the original (now grey haired) hackers and we'll   
   gladly tell you how some patterns are pretty much required.   
      
   I.e. input buffer in *SI, destination in *DI, counts in *CX, *BX for   
   table lookups, *DX as temp storage and *AX is of course the accumulator.   
      
   Using *BP as well was considered advanced programming. :-)   
      
   As long as the problem looks like this the naive code can be close to   
   minimum size, but in the meantime many of those implied register   
   instructions (LODS/STOS/LOOP*/etc) have been mistreated, ending up   
   slower than the typical explicit compiler-generated code.   
      
   Terje   
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)