Related Projects > NASMX
NASM-X prologue/epilogue optimizations
encryptor256:
This sentence seems absurd to me:
--- Quote from: Rob Neff on February 27, 2014, 05:07:57 PM ---Basically, the simple act of defining the PROC with parameters means that you will be accessing the spill area.
--- End quote ---
Well of course i'm going to access the spill area, anyone would, because there(in spill area, shadow space) lies first four arguments.
Spill area / Shadow space is 32 bytes long and even more, if procedure have more than four arguments.
--- Quote from: Rob Neff on February 27, 2014, 05:07:57 PM ---Otherwise, if you weren't planning on doing that then you would define a simple PROC with zero parameters.
--- End quote ---
Yes, generally, no one needs to access spill space/shadow space, if procedure doesn't have any arguments.
--- Quote from: Rob Neff on February 27, 2014, 05:07:57 PM ---But what about a PROC with 5 or more arguments where we may or may not want to spill registers but we need the stack frame built and param offsets equated in order to access the 5th, 6th, 7th, or 8th parameter(s)?
--- End quote ---
Yes, and parameters/arguments are stack/base frame offset's.
Stack space is already allocated by the caller.
If your procedure have 13 arguments, then caller must allocate this space to store those arguments and have a valid call to this procedure who have 13 arguments.
If your procedure have 13 arguments, caller allocates 13 * 8 + stack alignment space.
If your procedure have 13 arguments:
1. first four arguments are passed via registers and, on procedure side they are save into spill space/shadow space/register home address space.
1.1. !!! If procedure will not save these first four arguments they might be lost due to of call of internal procedure or else.
2. other 9 arguments are already saved on stack.
+ Yes there is a need for stack frame pointer, like RBP.
Later on, in procedure that had those 13 arguments:
First argument is accessed via RBP+8*2.
Second argument is accessed via RBP+8*3.
Third argument is accessed via RBP+8*4.
And so on...
Basic idea:
Catch idea or my insanity(it seems, im the only one who understands what im talking about). :D
Did i ever tell you the definition of "Insanity"??
:D
x64 -> Macro idea versus plain code.
1. Macro procedure example:
--- Code: ---; *******************************************
;
; Procedure: testProcA
; argument: ptrMessage
; argument: ptrTitle
;
; Procedure takes two arguments and call's MessageBox.
;
;
proc testProc,ptrdiff_t ptrMessage,ptrdiff_t ptrTitle
locals none
invoke MessageBox,ptrdiff_t [argv(.ptrMessage)],ptrdiff_t [argv(.ptrTitle)],0
xor rax,rax
endproc
--- End code ---
2. Plain code procedure example:
--- Code: ---; *******************************************
;
; Procedure: testProcA
; argument: ptrMessage
; argument: ptrTitle
;
; Procedure takes two arguments and call's MessageBox.
;
align 16
testProcA:
;
; Save arguments
;
mov [rsp+8*1],rcx
mov [rsp+8*2],rdx
%define ptrMessage rbp+8*2
%define ptrTitle rbp+8*3
;
; Create stack
;
push rbp
mov rbp,rsp
lea rsp,[rsp-8*4]
xor rcx,rcx
mov rdx,[ptrMessage]
mov r9,[ptrTitle]
xor r8,r8
call MessageBoxA
xor rax,rax
.quit:
;
; Clear stack n quit
;
lea rsp,[rsp+8*4]
pop rbp
ret
--- End code ---
So, procedure testProcA, takes two arguments, then i save them into spill space/shadow space/home location.
Later on, i use "ptrMessage" to access first argument and so on.
And by the way, this is only my suggestion.
At least that part felt so wrong, when invoke macro,
tried to store first four arguments into stack before a call is made.
At procedure, procedure code is responsible to store/save first four arguments registers into spill space/shadow space/home location.
And that's it.
Bye,
Encryptor256.
Rob Neff:
What you've just described is exactly how NASM-X already works - with the exception of automatically saving register parameters to the shadow space in the prologue.
So I see a few options for PROC with parameter arguments:
* automatically save registers to shadow space
* automatically save registers to shadow space UNLESS some pragma has disabled the feature.
* only save registers to shadow space if some pragma has enabled the feature
* force the developer to save to the shadow space if s/he requires it. ( <-- this is what NASM-X currently does )
I already understand which option you personally prefer. ;)
encryptor256:
--- Quote from: Rob Neff on February 27, 2014, 07:05:17 PM ---What you've just described is exactly how NASM-X already works - with the exception of automatically saving register parameters to the shadow space in the prologue.
So I see a few options for PROC with parameter arguments:
* automatically save registers to shadow space
* automatically save registers to shadow space UNLESS some pragma has disabled the feature.
* only save registers to shadow space if some pragma has enabled the feature
* force the developer to save to the shadow space if s/he requires it. ( <-- this is what NASM-X currently does )
I already understand which option you personally prefer. ;)
--- End quote ---
Yes, "automatically save registers into shadow space".
And
if there are 2x arguments, then save only those two.
if there are 3x arguments, then save only those three.
User "miz" from this thread Typo in nasmx.inc and issue with invoke on win64, well "he said": "no mater how arguments procedure have, it will always save those four arguments saved, even if procedure have only two or maybe even none".
--- Quote from: Rob Neff on February 27, 2014, 03:55:16 PM ---See also this thread which discusses whether invoke should spill registers or not.
--- End quote ---
"spill registers or not" - No, "yes or no / turn on or turn off", but how many registers to save.
- "he didn't said to turn them on or off. He said, if procedure have zero arguments then it saves those argument registers anyway".
This should be pragma option,
enabled by default: "saving register parameters to the shadow space in the prologue."
If there are 2x arguments, then save only those two.
If there are 3x arguments, then save only those three.
This should be a pragma option,
disabled by default : "force the developer to save to the shadow space if s/he requires it. ( <-- this is what NASM-X currently does )".
"( <-- this is what NASM-X currently does )"
Wrong,
New comer will not know that he have to save arguments manually.
"What you've just described is exactly how NASM-X already works"
Yes, and it works wrong.
Which part? This invoke macro part:
--- Code: ---xor rcx,rcx
mov [rsp],rcx
call ExitProcess
--- End code ---
That is not Win64 calling convention.
Invoke macro doesn't have to save first four arguments on stack, it is procedures duty.
First four arguments are passed via registers.
Option: "FASTCALL_STACK_PRELOAD", that loads first four registers into stack, before a call is made, is wrong on win64.
Let's say, i design and call ExitProcess, this is how it should be:
Design:
--- Code: ---ExitProcess:
;
; Procedure have one argument, so
; Save arguments - only one
;
mov [rsp+8*1],rcx
;
; ... Other code
;
ret
--- End code ---
Call:
--- Code: ---xor rcx,rcx
call ExitProcess
--- End code ---
First four arguments must be saved on procedure part, but NOT on invoke part.
Offtopic: Documentation of pragma option FASTCALL_STACK_PRELOAD
New comer might struggle with this, to find out, which one is default, ENABLE or DISABLE.
Okay, fine, there is no need to drink hot water here,
it seems NASMX users are satisfied with the way - how it works
and im just here trying to suggest something that doesn't matters anyway. :)
Bye,
Encryptor256.
Rob Neff:
I certainly agree that newcomers will not fully understand convention requirements. I'll admit that sometimes I'm too close to the details and thus tend to look at issues from the position of an expert user. I need to remember to come up for some air and see what some of the additional user issues lurking there, waiting to bite back.
So, moving the stack pre-load from INVOKE to PROC would solve many potential issues there. However, again from the point of an expert user, there ARE situations that warrant disabling or enabling pre-loading at any point within the source code. Thus I want pre-load pragma options for both PROC and INVOKE macros so that more advanced users can use it to over-ride default behavior. For one or more procedures I may need to turn on pre-loading during an INVOKE or turn off pre-loading in the PROC prologue.
Thus the defaults should work for the majority of cases but we would also have an "escape" mechanism if we need it in order to alter default behavior.
I'll work on it this week-end and hopefully have something for you to play with by Sunday.
encryptor256:
--- Quote from: Rob Neff on February 28, 2014, 05:14:11 PM ---I certainly agree that newcomers will not fully understand convention requirements. I'll admit that sometimes I'm too close to the details and thus tend to look at issues from the position of an expert user. I need to remember to come up for some air and see what some of the additional user issues lurking there, waiting to bite back.
So, moving the stack pre-load from INVOKE to PROC would solve many potential issues there. However, again from the point of an expert user, there ARE situations that warrant disabling or enabling pre-loading at any point within the source code. Thus I want pre-load pragma options for both PROC and INVOKE macros so that more advanced users can use it to over-ride default behavior. For one or more procedures I may need to turn on pre-loading during an INVOKE or turn off pre-loading in the PROC prologue.
Thus the defaults should work for the majority of cases but we would also have an "escape" mechanism if we need it in order to alter default behavior.
I'll work on it this week-end and hopefully have something for you to play with by Sunday.
--- End quote ---
Sounds nice!
--- Quote from: Rob Neff on February 28, 2014, 05:14:11 PM ---hopefully have something for you to play
--- End quote ---
Well, there is not a lot to play with, i know how it should be. :D
Hey, maybe there is no need to change - anything.
Only one who complains, was, user ankiller with his topic BUG of "USES MARCO".
And that bug is\was fixed.
If no one complains, then why change something. Users are satisfied with current release, no new glitches, and so on.
There is other things to work on: What new comers would like to?
- I think they all would like ta have some cross platform IDE, NASM/X IDE, Code Designer, Visual Studio. :D
Navigation
[0] Message Index
[*] Previous page
Go to full version