Now available is the latest Beta Release of NASMX - NASMX v1.0b4
You can get your copy at: http://sourceforge.net/projects/nasmx/
While striving to develop a system that is portable across operating systems (Linux, MachOS, Windows) as well as permitting 32 and 64 bit linkage among those operating systems using various compilers, many under-the-hood changes have been implemented. Please note that full 64-bit support is still not yet available although the foundation has been laid which will enable this capability in the next beta release.
This version contains many new enhancements such as:
1. New supported calling conventions - cdecl, pascal, stdcall, fastcall
2. Windows compiled help file NASMDOC.CHM which includes the lastest Nasm v2.10 documentation
3. New syntax changes
4. Minor bug fixes1. New supported calling conventions - cdecl, pascal, stdcall, fastcall
To ease interfacing with various compilers calling conventions can now be specified when importing, prototyping, or defining your procedure. For example, to create a procedure that will be called from a Pascal compiler simply prototype and define your procedure as:
proto pascal, myfunc, ptrdiff_t hWnd, size_t wParam, size_t lParam
proc myfunc, ptrdiff_t hWnd, size_t wParam, size_t lParam
invoke GetWindowLong, [argv(.hWnd)], GWL_USERDATA
cmp eax, 0
return 1 ; return an error code
return 0 ; return success
By simply changing the calling convention of the defined procedure and recompiling you instantly get the proper calling convention changes. Not specifying a calling convention implies use of the default calling convention for the operating system being targeted. For example, if you are developing code that targets win32 then the default calling convention will be stdcall, in which case you need do nothing further. The name mangling will be performed automatically, thus calling your assembly routine from C is as simple as specifying the __stdcall attribute when defining your header prototype ( ie: extern __stdcall MyCFunc(HWND hWnd) ).
Specifying a calling convention over-rides the system default for that procedure so be sure to understand this or otherwise you may receive linker errors regarding unknown functions.2. Windows compiled help file NASMDOC.CHM which includes the lastest Nasm v2.10rc2 documentation
This file contains the entire Nasm v2.10 documentation and makes it available as a Windows compiled help file. The help file contains a Contents and Index tab enabling you to quickly search for help on any topic. Windows developers will find this much faster to use than the standard html files which ship with Nasm due to the indexed search capability.3. New syntax changes
If you noted from the example given above there are quite a few changes that enable both cross-platform and cross-compiler support.
3.1 Calling convention support
Prototyping or importing a procedure definition usage:
PROTO [CALLCONV,] PROCNAME [,ARG1 [,ARG2,...]]
IMPORT [CALLCONV,] PROCNAME [,ARG1 [,ARG2,...]]
CALLCONV = cdecl, pascal, stdcall, fastcall
3.2 LOCALS macro
This macro is ALWAYS required when implementing your function.
It properly sets up the prologue entry of the function and marks
the beginning of your procedure local variables if any.
LOCALS [none] [xxx]
none = the procedure does not make use of any local variables
xxxx = amount of additional storage space (in bytes) to reserve on the stack.
This is an optimization feature that will be put to good
use when full Win64 support is available
3.3 LOCAL macro
Create local storage space on the stack for procedure local variables
LOCAL VARNAME, TYPE [, QUANTITY]
VARNAME = the name of the local variable
TYPE = byte, word, dword, qword, etc...
QUANTITY - number of TYPE to allocate ( default is 1 if unspecified )
local bFlags, dword
local my_ptr_array, ptrdiff_t, 20
3.4 ENDLOCALS macro
This macro is required when you are implementing a procedure that makes
use of local procedure variables.
3.5 RETURN macro
Enables the procedure to return a single value.
It is extremely important for the proper operation of your procedure that
you make use of either this macro or execute "jmp NASMX_ENDPROC" to exit
your routine. That way you can be sure that your function epilogue performs
the proper cleanup based upon the currently defined calling convention for
that function. Avoid naked "ret" opcodes (especially for the pascal and
stdcall calling conventions!).
3.6 ARGV and VAR: Accessing local variables and parameters
To properly put and get values within your procedure use the following syntax:
mov eax, dword [argv(.hwnd)]
mov dword [var(.mylocalvar)], eax
The location of your variable is defined in reference to the entry point and
the name is locally defined to the procedure name. In other words, always use
the "dot" notation when referencing procedure local variables or parameters.
Although this is a breaking change from earlier versions it enables you to
access elements within an array. A trivial example:
locals ; the always required macro
local myarray, dword, 10 ; create a dword array
endlocals ; required when defining locals
mov eax, dword[var(.myarray)+(4 * sizeof(dword))] ; obtain the 5th element of array (0 is 1st element)
3.7 ptrdiff_t and size_t
When attempting to write portable code these typedefs expand to the native byte size
of the target platform ( either 32 or 64 bit). Those of you familiar with C++ have
probably come across this quite often. Use these typedefs in your code when you
strive to write portable assembly.4. Minor bug fixes
Provided fix to context fall-through lookupSummary
There is quite a lot to chew on with this release. Please download this release and provide feedback to this thread. It is my sincere hope that there will only be one more beta release before transitioning to a Release Candidate. With only 2 things left on my todo list NASMX is much closer to a truly platform portable system.
I hope you find it useful in your programming endeavors. Thank you.