Hi there!

Is there any other way to write 64-bit invoke/fastcall macros not to destroy RAX contents if argscount > 4? I was happily using those macros until I encountered strange bug when calling BitBlt function and passing its 8th argument in RAX.

I am aware that the simplest solution is passing arguments in a different way - but sometimes using RAX (which stores the result of previously called function) is really handy.

Thank you for your help!

Why are you passing RAX?

You could choose any register instead of RAX but you still need to make some other changes to keep the macro working. Maybe:

@typedef

It's not me who passes RAX - it's Windows ABI. I am asking because I wanted to avoid the situation where I am calling function A which gives me its result in RAX and in the next step I want to pass this value to function B as fifth parameter let's say. In present shape of 64-bit fastcall/invoke macros I have to do one more thing before calling function B: mov RSI, RAX for example (and remember to add 'uses RSI' statement to proc definition). I think that it would be nice if fastcall checks if one of the parameters is being passed in register which it internally uses (RAX at the moment) and saves it somehow.

I could see on internet that NASM users had similar problem in the past and someone was trying to modify NASM's invoke macro in a way not to destroy RAX contents. However I am dealing too shortly with fasm and assembly in general to try to do it by myself. For now I just have to remember that RAX gets scratched if used as register passing fifth, sixth, seventh, etc. function parameter.

It all comes down to what you do when the register you use as a scratch is also an input value. My example above places it in the first slot of the spill area, but this would need some extra code to make it efficient and only save it there when it is needed.

Yes, revolution - exactly.
I started this thread only because the behaviour of 64-bit fastcall/invoke surprised me pretty much. Now, when I know how it works (regarding RAX handling) - I can live with this. I hope this will help some other fasm greenhorns...

I think that at the very least the standard fasm macros should display a warning, or give an error, when it detects that RAX (or EDX for the 32-bit calls) has become invalid.