Now available is the latest Beta Release of NASMX - NASMX v1.0b5
You can get your copy at:
http://sourceforge.net/projects/nasmx/ This version contains many new enhancements:
1. Win64 fastcall code supported.
2. Floating point parameters are now supported.
3. Stack Local Variables (SLV) addressing is now supported.
4. Win64 callstack optimization
5. Minor bug fixes and improvements
1. Win64 fastcall code supportedThe framework for 64-bit Windows calling convention has been implemented. There are quite a few "gotchas" which were worked around and optimizations to code emission that were made. Although demos 1-4 assemble and execute successfully, demo5 assembles but does not execute properly ( fame and fortune - well, at least fame - to the person who finds and provides a patch for this!). See /demos/win64 for examples. I'm putting a plug in here for Agner Fog's objconv program as it was used extensively during NASMX Win64 development. Thanks Agner!
2. Floating point parameters are now supportedOne of the hardest parts of building this framework was designing in floating point support. The framework does its best to encapsulate the nitty gritty details per calling convention. See /demos/win32/demo14 and /demos/win64/demo4 for usage.
3. Stack Local Variables (SLV) addressing is now supportedPassing the SLV address was an important improvement. NASMX now allows you to easily create an array of data and provide the address to a called function. It is based on nasm's own simple syntax: if brackets are used you want the contents of that variable; If no brackets are used you want the address.
For example:
proto func_wants_dword, dword i
proto func_wants_addr, ptrdiff_t ptr
proc myproc
locals
local mydwordarray, dword, 10 ; create an arrar of 10 dwords on the stack
endlocals
invoke func_wants_dword, dword[var(.mydwordarray)] ; get the contents of the first dword
invoke func_wants_addr, var(.mydwordarray) ; provide the address of the array
endproc
4. Win64 callstack optimizationAn issue was identified with the previous LOCALS macro and the callstack optimization. To resolve this a new macro was designed to not only fix it but provide a way to prevent any further changes to the NASMX syntax following this release. The new macro, NASMX_PRAGMA, will officially be used for supplying "hints" as to how code is to be emitted.
For example:
%ifidni __OUTPUT_FORMAT__,win64
; Tell NASMX that when creating the prologue to subtract
; an additional number of bytes from rsp to make room for
; the max parameters used by functions which follow.
; It eliminates extraneous sub/add rsp opcodes.
NASMX_PRAGMA CALLSTACK, 96
%endif
5. Minor bug fixes and improvementsA few bugs were squashed along the way
All demos assemble much faster now due to the creation of a master include "windemos.inc" that defines only the imports, structures, and enums used by the NASMX demos. It is recommended that you do likewise when coding your project since pulling in the entire fileset for Windows ( ie: windows.inc,kernel32.inc,user32.inc ) really puts a strain on nasm's preprocessor.
SummaryNASMX may begin to feel like a HLL compiler grafted onto Nasm using macros, and that's pretty much how I felt implementing it. However, the effort and the results make this the best release thus far. Please download this release and provide feedback to this thread. The goal now is to transition to a Release Candidate status following the official release of Nasm v2.10 and additional testing. Your feedback is vital to the success of this project. Thank you and happy hacking!