home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,756 of 4,675   
   James Harris to Terje Mathisen   
   Re: Manners everyone!   
   04 Jan 19 14:58:49   
   
   From: james.harris.1@nospicedham.gmail.com   
      
   On 04/01/2019 12:45, Terje Mathisen wrote:   
   > Bernhard Schornak wrote:   
   >> R.Wieser wrote:   
   >>   
   >>   
   >>> Terje,   
   >>>   
   >>>> As long as you are using a post-1986 CPU you can use stack-relative   
   >>>> adressing, in which case EBP is perfectly usable as a regular register,   
   >>>   
   >>> I know, and I'm sure bernard knows that as well.   
   >>   
   >> Yes. What I called "Intelligent Design" is code for recent   
   >> processors, not for hardware shown in museums. I developed   
   >> it before iNTEL came up with the less sophisticated, down-   
   >> graded version they publish in their 'optimisation guides'   
   >> since a couple of years.   
   >>   
   >> And, since I research this in depth for more than a decade   
   >> now, I do know (and can prove it experimentally) that this   
   >> kind of stack management is faster than abusing rBP. As it   
   >   
   > This is where you are wrong!   
      
   Can those who call for manners please be tactful...?   
      
   >   
   > Not specifically, i.e. using a single ESP update followed by MOV is   
   > probably faster on many cpus, but not in general:   
   >   
   > Simply because long series of PUSH/POP are so common in both compiler   
   > and assembler code, cpu architects have a lot of good reasons for trying   
   > to make this sort of code significantly faster, and they almost   
   > certainly will do so. (The most obvious hw optimization is to regard   
   > multiple sequential PUSH or POP operations as a single macro op, this is   
   > effectively the same as using explicit MOV operations while avoiding the   
   > code size impact.)   
   >   
   > In the meantime you have to ask yourself:   
   >   
   > Did you measure these speedups in smaller micro benchmarks, or as part   
   > of a substantial code base? The reason I'm asking is because time and   
   > time again it turns out that smaller code is faster code!   
   >   
   > A few PUSH/POP instructions of one byte each saves significant code   
   > space compared with MOV EAX,[ESP+nnn] operations taking at least 3 bytes   
   > each.   
      
   One thing I took from the earlier discussion is that it's probably worth   
   having a stack-frame layout where the callee-save registers can either   
   be pushed or moved into place. Then the best mechanism for a given   
   target CPU and set of optimisation goals can be used without altering   
   anything substantial.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca