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