Sorry, but passing args via registers has nothing to do with the stack needing aligned. And the reserved space I mentioned IS the spill..

The L1 cache is as fast as registers? Why do we even have registers, then? >_>

Azu wrote:

Sorry, but passing args via registers has nothing to do with the stack needing aligned. And the reserved space I mentioned IS the spill..

I agree, but I also agree with Bogdan Ontanu. I mean, I like to pass by registers if it ends up that way too (custom convention) but seriously fastcall64 is retarded.

EDIT: I meant that I like to pass registers as parameters if I don't need to push them later (to 'save' them), unless I want to optimize for size (in which case I would probably use 'pushad' since it's 1 byte even if it's slower... but this is only in 32-bit).

Otherwise (i.e if I don't use them immediately and have to 'save' them for later) pushing on the stack usually is smaller. Both have advantages, and combining them is useful. However the worst thing to do is to reserve the stack for that and then pass by registers. It is the most retarded thing I've seen.

Azu wrote:

The L1 cache is as fast as registers? Why do we even have registers, then? >_>

Well first of all, registers are encoded specially in instructions (smaller) so they could be faster because of THAT, but not because of the access itself. (of course pushing under 32-bit is even smaller than "mov"!). Secondly, you can't have instructions that move from memory to memory for example, for this reason (encoding). The registers are special because their encodings are special.

And of course they are ALWAYS in a special "L1 cache" (which the stack rarely is not -- if for example, you run a really intensive memory operation that doesn't use the stack at all -- i.e no local variables).

   ???  add     rsp, 32                                 ; 00402030 _ 48: 83. C4, 20
   ???  sub     rsp, 32                                 ; 00402034 _ 48: 83. EC, 20
        lea     rcx, [rbp-54H]                          ; 00402038 _ 48: 8D. 4D, AC
        mov     rdx, 0                                  ; 0040203C _ 48: C7. C2, 00000000
        mov     r8, 72                                  ; 00402043 _ 49: C7. C0, 00000048
; Note: Memory operand is misaligned. Performance penalty
        call    qword ptr [imp_memset]                  ; 0040204A _ FF. 15, 0000233C(rel)
   ???  add     rsp, 32                                 ; 00402050 _ 48: 83. C4, 20
   ???  sub     rsp, 32                                 ; 00402054 _ 48: 83. EC, 20
        mov     rcx, 0                                  ; 00402058 _ 48: C7. C1, 00000000
        call    qword ptr [imp_GetModuleHandleA]        ; 0040205F _ FF. 15, 00002093(rel)
    

The current fasm macros do not preallocate the stack at the procedure entry.

They do if you choose the static RSP prologue/epilogue variant. See Customizing the "proc" thread.

revolution wrote:

The current fasm macros do not preallocate the stack at the procedure entry.

They do if you choose the static RSP prologue/epilogue variant. See Customizing the "proc" thread.

But isn't this still an error? That code looks like do-nothing code, in other cases though it seem's to work as intended.

And another question, is the proc64 macro passing floating point values correctly (single precision?), if you look at the dis-assembly, Visual C/C++ is using xmm0, xmm1, xmm2, etc. registers first, while fasm is using rcx, rdx, etc.

Not a macro question, but, looking at the dissassembly, are you passing parameters to opengl using xmm registers. I didn't know you could do that. Is this just for 64bit coding?

Do-nothing doesn't do any harm, does it? Why it was chosen for the default macro behavior to allocate stack frame each time separately, is explained in that oldest thread.

If you read that other thread carefully, you will notice that "float" prefix should be used in such case. Check out the "WIN64/OPENGL" example that comes with fasmw package, too.

Wait a second, madmatt, it was you who asked this question in the other thread, where I demonstrated a disassembly of a procedure from OpenGL example with static RSP frame enabled.
Or is someone stealing your identity?

Ok, I got my opengl example working good now. You pass floats differently in the proc64 macro than with the proc32 macro, 'float dword' for single precision, just 'float' for double precision.

And if you want to get rid of redundant RSP operations, just use "frame" macro.

madmatt wrote:

Ok, I got my opengl example working good now. You pass floats differently in the proc64 macro than with the proc32 macro, 'float dword' for single precision, just 'float' for double precision.

Yes. You can also use 'float qword' for double precision.
This is all going to be documented in the new manual on Win32/Win64 headers, but I have't started it yet.

The stack pointer (RSP) must be 16-byte aligned when making a call to an API. With some APIs this does not matter, but with other APIs wrong stack alignment will cause an exception. Some APIs will handle the exception themselves and align the stack as required (this will, however, cause performance to suffer). Other APIs (at least on early builds of x64) cannot handle the exception and unless you are running the application under debug control, it will exit.