Related Projects > NASMX
NASMX typedef system update
Rob Neff:
The new NASMX typedef system is slowing moving into place. To give you a brief overview of how powerful (and easy) it is to use just look at the following Windows demo2 code snippet (but can be easily applied to all systems):
--- Code: ---NX_STRUC WNDCLASSEX
NX_RESERVE .cbSize, uint32_t, 1
NX_RESERVE .style, uint32_t, 1
NX_RESERVE .lpfnWndProc, NX_PTR, 1
NX_RESERVE .cbClsExtra, int32_t, 1
NX_RESERVE .cbWndExtra, int32_t, 1
NX_RESERVE .hInstance, NX_PTR, 1
NX_RESERVE .hIcon, NX_PTR, 1
NX_RESERVE .hCursor, NX_PTR, 1
NX_RESERVE .hbrBackground, NX_PTR, 1
NX_RESERVE .lpszMenuName, NX_PTR, 1
NX_RESERVE .lpszClassName, NX_PTR, 1
NX_RESERVE .hIconSm, NX_PTR, 1
NX_ENDSTRUC WNDCLASSEX
--- End code ---
This code defines the in-memory layout of the structure named WNDCLASSEX. Notice that it is now using the new typedefs. Examining the definition in more detail your notice that some structure fields contain an NX_PTR type. This type is defined to expand automatically depending on the output format specified. Thus the NX_PTR fields will be either 32-bit or 64-bit.
To create and instance of this struct we use the new NX_ISTRUC macro:
--- Code: ---wc:
NX_ISTRUC WNDCLASSEX
NX_AT .style, CS_VREDRAW + CS_HREDRAW
NX_AT .cbSize, WNDCLASSEX_size
NX_AT .lpfnWndProc, NULL
NX_AT .cbClsExtra, NULL
NX_AT .cbWndExtra, NULL
NX_AT .hInstance, NULL
NX_AT .hIcon, NULL
NX_AT .hCursor, NULL
NX_AT .hbrBackground, COLOR_BTNFACE + 1
NX_AT .lpszMenuName, NULL
NX_AT .lpszClassName, NULL
NX_AT .hIconSm, NULL
NX_IENDSTRUC WNDCLASSEX
--- End code ---
Compare this version to the old way:
--- Code: ---wc:
istruc WNDCLASSEX
at WNDCLASSEX.cbSize, dd WNDCLASSEX_size
at WNDCLASSEX.style, dd CS_VREDRAW + CS_HREDRAW
at WNDCLASSEX.lpfnWndProc, dd NULL
at WNDCLASSEX.cbClsExtra, dd NULL
at WNDCLASSEX.cbWndExtra, dd NULL
at WNDCLASSEX.hInstance, dd NULL
at WNDCLASSEX.hIcon, dd NULL
at WNDCLASSEX.hCursor, dd NULL
at WNDCLASSEX.hbrBackground, dd COLOR_BTNFACE + 1
at WNDCLASSEX.lpszMenuName, dd NULL
at WNDCLASSEX.lpszClassName, dd NULL
at WNDCLASSEX.hIconSm, dd NULL
iend
--- End code ---
As you can see, the new typedef system is doing a lot for you. Since it already knows at definition what the structure field sizes are it doesn't ask you to repeat them. This is especially important when creating code for both 32-bit and 64-bit systems because of structure field pointer expansion! Notice that your code won't change one bit! Write once, run on both :)
I am maintaining this code on sourceforge.net so if you're interested in following the development you can check out the code via svn:
--- Code: ---svn co https://nasmx.svn.sourceforge.net/svnroot/nasmx/branches/rob nasmx
--- End code ---
It's not quite ready for primetime just yet but it should give you a glimpse of the many things Keith, Bryant, and myself have for this project.
*Edit to show my dev branch for svn co. Again, this is not for usage, just reading! :)
Klod:
Thanks for sharing.
The NASMX link has been removed. I checked
http://www.asmcommunity.net/projects/nasmx
All the downloads are from last year.
Where can I download the latest release?
Klod
Keith Kanios:
--- Quote from: Klod on August 02, 2010, 04:06:38 AM ---Where can I download the latest release?
--- End quote ---
Rob's SVN branch (given in his last post) is essentially the current dev branch.
There isn't any packaged release, as of yet. You'll have to grab it from SVN.
Rob Neff:
Before I finish up nasmx typedef'ing I have another need. That need is for structures and unions within other structures and unions. To use another example from the windows.inc include let's look at a before and after of what the new code should look like, ideally:
--- Code: --- message:
NX_ISTRUC MSG
NX_AT .hwnd, NULL
NX_AT .message, NULL
NX_AT .wParam, NULL
NX_AT .lParam, NULL
NX_AT .time, NULL
NX_AT .pt, NULL
NX_IENDSTRUC MSG
--- End code ---
Notice the MSG.pt structure field. Currently, to access the member var POINT.y in the message structure you have to code as follows:
--- Code: --- mov ecx, message + MSG.pt + POINT.y
mov [ecx], 42 ; Answer to the Ultimate Question of Life, the Universe, and Everything
; - or - maybe this:
mov ecx, message
.
. do stuff
.
xor eax, eax
mov [ecx + MSG.pt], eax ; PT.x
mov [ecx + MSG.pt + 4], 42 ; PT.y
--- End code ---
Wouldn't it make much more sense to code:
--- Code: --- mov ecx, message
mov [ecx + MSG.pt.y], 42
--- End code ---
So what's the big deal here? For this trivial example not much. However, when you have to deal with structures containing structures of structures and unions things can start getting a bit "hairy". You may be asking yourself - "Why do I care about this? I'll just keep my structures simple". Well, in your own code you are free to define and instantiate however you please. But at soon as you need to access operating system defined structures which are deeply nested what are your choices? What if those structure sizes change between OS releases or between 32 and 64 bit versions? Wouldn't it be nice if somebody else already did the hard part and made it simple to access those system definitions? NASMX to the rescue.
So a slight change is in order, specifically, allowing the nesting of structures and unions. Let's create the proper definition of the POINT and MSG structures:
--- Code: ---NX_STRUC POINT
NX_RESERVE .x, int32_t, 1
NX_RESERVE .y, int32_t, 1
NX_ENDSTRUC POINT
NX_STRUC MSG
NX_RESERVE .hwnd, NX_PTR, 1
NX_RESERVE .message, uint32_t, 1
NX_RESERVE .wParam, size_t, 1
NX_RESERVE .lParam, size_t, 1
NX_RESERVE .time, uint32_t, 1
NX_RESERVE .pt, POINT, 1
NX_ENDSTRUC
--- End code ---
When processing the MSG structure NASMX will see that field .pt is an embedded POINT structure. It will reserve POINT size space and define the following offsets accordingly:
--- Code: --- MSG.pt.x
MSG.pt.y
--- End code ---
Notice that the field .hwnd is defined as an NX_PTR, and fields .wParam and .lParam are size_t. This means that these particular fields will expand in size depending on the bitness of the current build ( ie: 32 or 64 bits ). When creating your code on 32 bit platforms the sizes are defined as DWORD but on 64 bit platforms they become QWORDs. The offsets of embedded structure members will be automatically adjusted accordingly freeing you from the task of modifying your own code.
This is all currently being designed and developed right now. No code is yet available to play around with but I'm hoping to have an alpha release within the next week or two. Comments, questions, or suggestions are welcome. Stay tuned for further developments. :)
Klod:
stupid question,
how do you "grab" a copy from svn
https://nasmx.svn.sourceforge.net/svnroot/nasmx/branches/rob nasmx
this does not work
regards klod
Navigation
[0] Message Index
[#] Next page
Go to full version