The NASMX v1.0rc2 release candidate is now available for download.
The following Operating Systems are officially supported with this release:
Linux x86
Linux x64
Windows x86
Windows x64
You can now choose the appropriate download for your distribution:
Linux -
http://sourceforge.net/projects/nasmx/files/nasmx-1.0/linux/Windows -
http://sourceforge.net/projects/nasmx/files/nasmx-1.0/windows/All supported OSes have fully functional demos that you can assemble and run.
Much work has gone into callstack alignment, optimizations, and bug fixes.
Note for x64 developers:
Register shadow storage(Windows) / register spill area(Linux) is fully supported.
Remember that when using the fastcall calling convention (the default for Linux64/Win64) the parameters supplied to your procedures are already contained in the appropriate registers.
The storage/spill area is simply a facility where YOU can store the register contents to. It's similar in concept to parameter passing on the stack except that, while the stack space has been allocated, the parameter value is instead contained in a register.
Thus you should be familiar with your operating systems parameter passing calling convention:
Windows: RCX, RDX, R8, R9 (ints, longs, ptrs)
XMM0, XMM1, XMM2, XMM3 (floats/doubles)
Linux : RDI, RSI, RDX, RCX, R8, R9 (ints, longs, ptrs)
XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7 (floats/doubles)
For example:
proc my64bitfunc, qword ptrString, qword length
locals none
; save register parameter contents to spill area
%ifidni __OUTPUT_FORMAT__,win64
mov qword [argv(.ptrString)], rcx
mov qword [argv(.length)], rdx
%elifidni __OUTPUT_FORMAT__,elf64
mov qword [argv(.ptrString)], rdi
mov qword [argv(.length)], rsi
%endif
endproc
Parameters not stored in registers are contained on the stack.
When mixing int/float args you must pay attention to your operating systems calling convention.
The differences between Linux and Windows is rather significant for those of us trying to write portable code.
Quick notes for all developers:
1.) Do not make use of the push/pop/leave/ret opcodes as these are only necessary for the framework. Your code will eventually fail if you do this.
2.) Save registers with either the USES macro or to stack local variables.
3.) Use the RETURN macro to exit a function where needed.
4.) Remember to always prepend a dot(.) within the function when a)defining jmp labels, b)using local variables or c)using parameter names.
The dot-prefix is what associates the labels to the function. This convention assures that you can have multiple functions defined within one source file that reuse the same names.
You should/will get errors if you forget about this.
For example:
proc my64bitfunc
uses rbx, r11 ; this will save the registers before use
locals
local myvar, qword ; define a stack local variable
local buffer, byte, 512 ; defining an array
endlocals
.
.
; using the dot-prefix to access local labels
mov qword [var(.myvar)], rax
invoke memset, var(.buffer), 0, 512
cmp rax, 0
jnz .not_zero
return -1 ; function return value
.not_zero:
.
.
return 0 ; function return value
; (or you can simply set rax here before endproc )
endproc ; saved register contents automatically restored
Please download your platform's package and give it whirl.
The macro framework is stable with some non-GUI examples being able to easily cross-compile.
The Linux/Windows GUI examples provide a nice start for new assembly developers.
There is a wealth of information in the demo source regarding the use of the NASMX framework.
Project documentation is currently rather sparse but I hope to have something available for the official stable release.
Please reply to this thread if you've identified bugs specific to NASMX.
Thank you and enjoy!
