Author Topic: Announcing NASMX v1.0b4  (Read 28889 times)

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Announcing NASMX v1.0b4
« on: November 13, 2010, 08:59:45 PM »
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 fixes

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

Code: [Select]
proto pascal, myfunc, ptrdiff_t hWnd, size_t wParam, size_t lParam

proc   myfunc, ptrdiff_t hWnd, size_t wParam, size_t lParam
locals none

   invoke GetWindowLong, [argv(.hWnd)], GWL_USERDATA
   cmp    eax, 0
   jne    .do_stuff
   return 1             ; return an error code
.do_stuff:
   .
   .
   return 0             ; return success

endproc

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,...]]
    where
        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]
    where
        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
    example:
        locals none
        locals 64

3.3 LOCAL macro
    Create local storage space on the stack for procedure local variables
        LOCAL VARNAME, TYPE [, QUANTITY]
    where
        VARNAME = the name of the local variable
        TYPE = byte, word, dword, qword, etc...
        QUANTITY - number of TYPE to allocate ( default is 1 if unspecified )
    example:
        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.
        return 0
    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:

Code: [Select]
    proc myfunc
    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)
    endproc

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 lookup


Summary

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.
« Last Edit: November 14, 2010, 03:55:46 AM by Rob Neff »

Offline avcaballero

  • Full Member
  • **
  • Posts: 133
  • Country: es
    • Abre los Ojos al Ensamblador
Re: Announcing NASMX v1.0b4
« Reply #1 on: November 22, 2010, 09:45:06 AM »
It seems that the new NasmX version has carried a lot of job, because there are a lot of new things. Although I have not had opportunity to check it deeply, there are a couple of things that I'd like to comment:

1. The example 11 fails when linking:

2. I keep on without being able to paint images in the window neither in buttons. I am a little disappointed, because with no doubt it should be that I lack some step. I would beg you indicate me which one is. And, however, it can be verified that the figure is within the executable:

Receive a cordial greeting.

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: Announcing NASMX v1.0b4
« Reply #2 on: November 22, 2010, 02:56:16 PM »
Your LoadIcon and LoadBitmap routines are failing.

Firstly, if your not writing 16-bit code use LoadImage().
The following C Code is taken directly from MSDN:

Code: [Select]
HICON hIcon;

hIcon = LoadImage(   g_hInst,
                           MAKEINTRESOURCE(IDI_MAIN_ICON),
                           IMAGE_ICON,
                           GetSystemMetrics(SM_CXSMICON),
                           GetSystemMetrics(SM_CYSMICON),
                           0);


Make sure you understand MAKEINTRESOURCE for use your own assembler code.
Hopefully that helps!  ;)


Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: Announcing NASMX v1.0b4
« Reply #3 on: November 22, 2010, 03:55:20 PM »
Also, for compiling demo11, you'll need to do two things:

1) Golink really wants that /mix command line arg.  Modify golink command as follows:
 GoLink.exe /console /mix /entry _main DEMO11.obj msvcrt.dll

and

2) Change getch to _getch in both your source and the nasmx\inc\win32\msvcrt.inc

Microsoft has deprecated the use of the getch() function name without the leading underscore.
I'll make sure that's included in the next release.  Thanks!

Offline hmi222

  • Jr. Member
  • *
  • Posts: 6
Re: Announcing NASMX v1.0b4
« Reply #4 on: January 09, 2011, 07:11:18 PM »
Hi!
Thanks for this great job!
Is it possible to get nasmx working for YASM?
Best regards
hmi222

Offline Rob Neff

  • Forum Moderator
  • Full Member
  • *****
  • Posts: 429
  • Country: us
Re: Announcing NASMX v1.0b4
« Reply #5 on: January 09, 2011, 11:00:13 PM »

To be honest, I've never used YASM.  If YASM supports Nasm preprocessor syntax then there's definitely a possibility.