Author Topic: Announcing NASMX v1.0rc2  (Read 2845 times)

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 430
  • Country: us
Announcing NASMX v1.0rc2
« on: June 04, 2011, 10:27:59 PM »

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 -
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:

Code: [Select]
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

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:

Code: [Select]
proc   my64bitfunc
uses   rbx, r11   ; this will save the registers before use
    local myvar, qword       ; define a stack local variable
    local buffer, byte, 512  ; defining an array
    ; 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
    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!