On Jul 5, 8:11 pm, Cactus <rieman...@gmail.com> wrote: > Optimisation of assembler code for Windows x64 within prologue and epilogue > code is pretty heavily constrained by the calling conventions so some of > your changes between versions don't carry across to Windows. > > In particular, unless a frame pointer is declared, the stack pointer must > remain static in the function body (declaring a frame pointer is a pain so I > try to avoid it) and register restore operations in any epiiogue code can > only use pop instructions (i.e. mov instructions are not allowed) > > There is an option in prologue code to use mov rather than push instructions > (provided what is done can be undone by pop's in the epilogue). But at the > moment I only use push operations for register saves in WIndows prologues so > I ignore your mov based alternatives. If there a clear rationale for whiich > approach is better I could adopt a mov based approaach but I am wondering if > this would make much difference in practice? >
It dont make much. pop on the K8 is 2 macro ops whereas a mov is 1 macro-op , also pop/ push on K8 have false dependence , pop/push are smaller though , I not sure about netburst/atom/bobcat but for the others pop/push is probably best > I also have to save rsi and rdi on entry as these are non-volatile on > Windows so there may be further differences that interfere with any lead in > optimisation that you are doing. > Yeah it could be a problem , I've not done any for karaadd yet, assuming you doing it to save the odd cycle , but if it makes the loop run faster (I have many examples where this happens ,eg nand nor). > Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
