Related Projects > NASMX
BUG of "USES MARCO"
encryptor256:
Did some testing with new nasmx.inc (117,979 bytes).
* Above problems seems to be fixed.
But there is something else.
1. Trying to use more registers
Code compiled with: "nasm.exe -f win64 test.asm -o test.obj"
--- Code: ---bits 64
%include "nasmx.inc"
proc testProc,dword x,dword y
uses r10,r11,r12,r13,r14,r15,rdi,rsi,rbx
locals none
xor rax,rax
endproc
--- End code ---
Results in:
--- Code: ---test.asm:5: error: parser: instruction expected
--- End code ---
2. Macro "invoke" saves arguments in stack, before call is made
I think, this has to be done in procedure context, rather than before call is made with invoke macro.
What if somebody call wsprintfA, this procedure doesn't care,
if somebody saved those arguments into shadow space before.
The one who designed "wsprintfA" ,that is his responsibility to save registers if he needs to do that.
This has to be procedure issue rather than invoke macro issue.
Yes, somebody could use FASTCALL_STACK_PRELOAD, but this is not the case.
Of course, backward compatibility does not permits to change something.
.- But what if somebody build obj library and call it from other languages, like C.
In C, the somebody will not have access to invoke macro and it will not save somebody's arguments.
.- What if somebody need to switch between somebody's custom procedures and some system procedures, like wsprintfA.
Switching between each call could be full of pain.
What if, what if, what if... endless loop of "what if's".
Who is this "somebody", well, no one know's, some mystical person. :D
3. 2.21: NASMX_PRAGMA: Defining pragmas
Was reading NASMX fables, from book "NASM-X.CHM" and found one thing, something...
So i made up a Puzzle Game:
Here is one letter too much, which one? : "FASTCALL_STACK_PRELOAD, [ ENABLED | DISABLE ]"
Yes, you think left right,
this is how it should be:
".... ENABLE ....".
* One byte removal is required.
And that's it, for now!
Rob Neff:
--- Quote from: encryptor256 on February 25, 2014, 08:02:44 AM ---
--- Code: --- uses r10,r11,r12,r13,r14,r15,rdi,rsi,rbx
test.asm:5: error: parser: instruction expected
--- End code ---
--- End quote ---
The USES macro definition currently only accepts up to 8 parameters. I guess we should expand this to a larger number that accounts for all general regs. Of course, at that point, we may want to use the pushad/popad opcodes for 32-bit apps ( 64-bit apps don't have that luxury ) to get a shorter/faster program.
--- Quote from: encryptor256 on February 25, 2014, 08:02:44 AM ---Switching between each call could be full of pain.
--- End quote ---
I'm not sure what point you're trying to make here. For Win64 simply NASMX_PRAGMA FASTCALL_STACK_PRELOAD, DISABLE and assume nothing about the shadow space other than it exists for you. If you mean something else perhaps create another thread to continue discussing there?
--- Quote from: encryptor256 on February 25, 2014, 08:02:44 AM --- one? : "FASTCALL_STACK_PRELOAD, [ ENABLED | DISABLE ]"
--- End quote ---
Good eye! Will fix!
encryptor256:
Okay, here was one more:
Compile this code with: "nasm -f win64 test.asm -o test.obj"
--- Code: ---bits 64
%include "nasmx.inc"
NASMX_PRAGMA FASTCALL_STACK_PRELOAD, DISABLE
IMPORT myprocedure
proc testProc,dword x,dword y
uses rbx
locals none
invoke myprocedure,0xFEED,0xA,0xBEEF
xor rax,rax
endproc
--- End code ---
NDisasm with: "ndisasm -b 64 test.obj"
Notify: Twice the sub instruction.
--- Code: ---0000003C 55 push rbp
0000003D 4889E5 mov rbp,rsp
00000040 48895DF0 mov [rbp-0x10],rbx
00000044 4883EC10 sub rsp,byte +0x10
00000048 4883EC20 sub rsp,byte +0x20
0000004C B9EDFE0000 mov ecx,0xfeed
00000051 BA0A000000 mov edx,0xa
00000056 41B8EFBE0000 mov r8d,0xbeef
0000005C E800000000 call qword 0x61
00000061 4883C420 add rsp,byte +0x20
00000065 4831C0 xor rax,rax
00000068 5B pop rbx
00000069 4889EC mov rsp,rbp
0000006C 5D pop rbp
0000006D C3 ret
--- End code ---
AND: Is that normal, that invoke macro loads constant parameters into 32 bit registers?
Bye.
Rob Neff:
--- Quote from: encryptor256 on February 25, 2014, 05:40:03 PM ---Notify: Twice the sub instruction.
--- Code: ---0000003C 55 push rbp
0000003D 4889E5 mov rbp,rsp
00000040 48895DF0 mov [rbp-0x10],rbx
00000044 4883EC10 sub rsp,byte +0x10 ; <-- allocates USES storage space , created by USES macro
00000048 4883EC20 sub rsp,byte +0x20 ; <-- alocates parameter space , created by INVOKE macro
0000004C B9EDFE0000 mov ecx,0xfeed
00000051 BA0A000000 mov edx,0xa
00000056 41B8EFBE0000 mov r8d,0xbeef
0000005C E800000000 call qword 0x61
00000061 4883C420 add rsp,byte +0x20 ; <-- restore parameter space , performed by INVOKE macro
00000065 4831C0 xor rax,rax
00000068 5B pop rbx
00000069 4889EC mov rsp,rbp
0000006C 5D pop rbp
0000006D C3 ret
--- End code ---
--- End quote ---
INVOKE cannot know whether you have actual code between it and the prior USES/LOCALS macros.
You may wish to use NASMX_PRAGMA CALLSTACK, 32 prior to your proc definition to see how your stack pointer is better optimized.
--- Quote from: encryptor256 on February 25, 2014, 05:40:03 PM ---AND: Is that normal, that invoke macro loads constant parameters into 32 bit registers?
--- End quote ---
Yes, if it is a value that can fit in 32-bits - will use the shorter opcodes.
encryptor256:
--- Quote from: Rob Neff on February 25, 2014, 05:54:12 PM ---
--- Quote from: encryptor256 on February 25, 2014, 05:40:03 PM ---Notify: Twice the sub instruction.
--- Code: ---0000003C 55 push rbp
0000003D 4889E5 mov rbp,rsp
00000040 48895DF0 mov [rbp-0x10],rbx
00000044 4883EC10 sub rsp,byte +0x10 ; <-- allocates USES storage space , created by USES macro
00000048 4883EC20 sub rsp,byte +0x20 ; <-- alocates parameter space , created by INVOKE macro
0000004C B9EDFE0000 mov ecx,0xfeed
00000051 BA0A000000 mov edx,0xa
00000056 41B8EFBE0000 mov r8d,0xbeef
0000005C E800000000 call qword 0x61
00000061 4883C420 add rsp,byte +0x20 ; <-- restore parameter space , performed by INVOKE macro
00000065 4831C0 xor rax,rax
00000068 5B pop rbx
00000069 4889EC mov rsp,rbp
0000006C 5D pop rbp
0000006D C3 ret
--- End code ---
--- End quote ---
INVOKE cannot know whether you have actual code between it and the prior USES/LOCALS macros.
You may wish to use NASMX_PRAGMA CALLSTACK, 32 prior to your proc definition to see how your stack pointer is better optimized.
--- Quote from: encryptor256 on February 25, 2014, 05:40:03 PM ---AND: Is that normal, that invoke macro loads constant parameters into 32 bit registers?
--- End quote ---
Yes, if it is a value that can fit in 32-bits - will use the shorter opcodes.
--- End quote ---
Okay, thanks, it's clear, for now. :)
Navigation
[0] Message Index
[*] Previous page
Go to full version