Register Definitions

[NathanStiles]

I've been studying the code generated by the qeditor.  I maybe finally starting to make sense of it.
Some questions if you please.
1) How do we know that the return value from a call to invoke will end up in eax?

2) Why is rv used here...

Code Select Expand

mov sHgt,        rv(GetSystemMetrics,SM_CYSCREEN)
...but not here...

Code Select Expand

invoke LoadImage,hInstance,700,IMAGE_BITMAP,0,0, LR_DEFAULTSIZE or LR_LOADTRANSPARENT or LR_LOADMAP3DCOLORS
mov hBitmap, eax

...isn't the above the same thing as below?

Code Select Expand

mov hBitmap, rv(LoadImage,hInstance,700,IMAGE_BITMAP,0,0, LR_DEFAULTSIZE or LR_LOADTRANSPARENT or LR_LOADMAP3DCOLORS)

3) There's a lot to read out there on the net.  Should I actually be reading "Intel® 64 and IA-32 Architectures Software Developer's Manual" or just using it as a dictionary?  What should I be reading?

[jj2007]

What should I be reading?

Click on my "tips & tricks" below, you'll find a concise list of stuff to read.
Welcome to the forum :thumbu

[SteveAsm]

I've been studying the code generated by the qeditor.  I maybe finally starting to make sense of it.

Qeditor is a text editor.
What code generated do you mean ?

Some questions if you please.
1) How do we know that the return value from a call to invoke will end up in eax?

Historically, each register in the in the CPU was given a meaningful name and was designated a specific purpose.
The AX register was designated the Accumulator and was assigned the task of holding the return value of a function call.
The AX register is comprised of AH and AL. In 32 bit systems AX is extended to EAX.

2) Why is rv used here...
mov sHgt,        rv(GetSystemMetrics,SM_CYSCREEN)

A call to GetSystemMetrics returns a simple integer value.

invoke LoadImage,hInstance,700,IMAGE_BITMAP,0,0, LR_DEFAULTSIZE or LR_LOADTRANSPARENT or LR_LOADMAP3DCOLORS
mov hBitmap, eax

A call to LoadImage returns a HANDLE.

...isn't the above the same thing as below?

Because different macros are being used.

3) What should I be reading?

Any good book about MASM Assembly Language Programming.
http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&field-keywords=masm+assembly+language

edit:
Additional links:
http://win32assembly.online.fr/tutorials.html

http://webster.cs.ucr.edu/AsmTools/MASM/index.html

http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/index.html

[NathanStiles]

@jj2007 thank you I will review the link you provided

@SteveAsm Thank you for responding.  If you run \masm32\qeditor.exe click the code menu it will generate a simple windows project template for you.

I have in .data?
hBitmap     dd ?   
sHgt        dd ?

so sHgt is the int and hBitmap is the handle i know they're different things but it's still 4bytes each right?

They're allocated the same way.  I don't see the difference.

Even when I changed the code and assembled and linked etc (makeit.bat) it all worked the same no errors warnings etc.

It seems that the rv macro is taking the return value from eax right?

So invoke is a macro?

[SteveAsm]

I have in .data?
hBitmap     dd ?   
sHgt        dd ?

so sHgt is the int and hBitmap is the handle i know they're different things but it's still 4bytes each right?
They're allocated the same way.  I don't see the difference.
Even when I changed the code and assembled and linked etc (makeit.bat) it all worked the same no errors warnings etc.
It seems that the rv macro is taking the return value from eax right?
So invoke is a macro?

Yes.

I the above case:
hBitmap     dd ?   
sHgt        dd ?

both are assigned the same memory size, as DWORD. That's what dd means.
where db would be BYTE, dq would be QWORD.

The difference is in their name. Each variable has it's own unique name.
In this case, the name is descriptive of what it is.
hBitmap means: Handle to Bitmap.
sHgt is an integer value that represents the Y axis of the screen.

When calling the function GetSystemMetrics, you provide it with a single parameter which you wish to query.
In this case, (GetSystemMetrics,SM_CYSCREEN) is asking the system what is the Y dimension of the screen (in terms of X and Y).
sHgt is the value of Y.

And Yes, invoke is a macro.

There are macros intrinsic to MASM (meaning built-in) and there are additional macros in Masm32.
Don't confuse MASM with Masm32. They are two different things.
MASM is the assembler, Masm32 is a library for use with MASM.

If you read the MASM manuals/books they will provide a list of built-in macros.

[dedndave]

@jj2007 thank you I will review the link you provided

@SteveAsm Thank you for responding.  If you run \masm32\qeditor.exe click the code menu it will generate a simple windows project template for you.

I have in .data?
hBitmap     dd ?   
sHgt        dd ?

so sHgt is the int and hBitmap is the handle i know they're different things but it's still 4bytes each right?

They're allocated the same way.  I don't see the difference.

Even when I changed the code and assembled and linked etc (makeit.bat) it all worked the same no errors warnings etc.

It seems that the rv macro is taking the return value from eax right?

So invoke is a macro?

yes - they are all dword in size - that does not necessarily satisfy the type definition
in asm code, we can be sloppy, as long as we know what type of data is stored someplace   :P
but in C code, the typing is stronger - meaning that if you try to put a handle where a uint goes, the compiler may not cooperate
much of what we write in asm is closely related to C because MS has defined their functions that way
so, if i wanted to be "more correct", i could use stronger typing

Code Select Expand

hBmp  HANDLE ?
if you look in windows.inc, you will find that Hutch has provided the TYPEDEF statements for numerous data types

Code Select Expand

HANDLE TYPEDEF DWORD
so - it's a dword, either way   :bg

INVOKE is a macro, but not defined in the include or macro files
instead, it is internal to the MASM assembler

"rv" is a macro that returns a value - it is simply a shortcut
"func" is a similar shortcut that allows direct use of strings where the function requires a pointer
that macro defines the string in the data area and passed the pointer
those macros can be examined by looking in masm32\macros\macros.asm

most windows functions return a result or status in EAX
if you want to see what it is, you can use MSDN as a reference
for example, if you google "CreateWindowEx", one of the first hits will be the MSDN page for that function
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632680%28v=vs.85%29.aspx
scroll down to the "Return Value" section for a description

[dedndave]

a little more info on register usage in windows functions...

as i mentioned above, most windows API functions return a status or result in EAX
from that, you may infer that the EAX register is not preserved across the call   :P
this is also true for ECX and EDX - they may be trashed by the function
also true for FPU/MMX registers and SSE - anybodies guess - lol

however, the EBX, ESI, EDI, and EBP registers are preserved across system cals
also, the direction flag (DF) should be cleared when calling a system function
so - if you set it, you should clear it when done

while it is not a requirement, we generally try to write our functions following the same set of rules
that makes the code "re-usable" in an environment where it may be called from a callback like WndProc

although MS never seems to use ECX or EDX to pass information (C compilers aren't set up that way),
we may use these registers that way in our own functions, if desired
i sometimes return a status in EAX, count in ECX, and pointer in EDX
as i write more functions, i am learning that it is nice to return all 3 registers in some known state
if there isn't anything to return in ECX and/or EDX, i may set them to 0 or return one of the passed parameters
this tends to make the function more flexible, and minimizes any future changes i may have to make

[dedndave]

here is an example
the masm32 library has a console CLS function, but i wanted one that would handle multiple pages
so - i wrote one that requires a handle
while i'm at it, i return some values in EAX, ECX, EDX...

Code Select Expand

;***********************************************************************************

        OPTION  PROLOGUE:None
        OPTION  EPILOGUE:None

ConCls  PROC    hConsole:HANDLE

;Clear Console Screen Buffer, DednDave 12-2011
;
;  This function allows the use of multiple screen buffers, clearing
;only the buffer specified by hConsole. Space characters and the current
;foreground/background attributes for the specified buffer are used.
;
;Call With: hConsole = handle of console screen buffer to clear
;
;  Returns: EAX = screen position (0,0)
;           ECX = total number of characters in screen buffer
;           EDX = buffer character attributes used to clear
;
;     Uses: all other registers preserved

        push    ebx
        push    edi
        mov     ebx,[esp+12]                  ;EBX = hConsole
        xor     edi,edi
        sub     esp,(sizeof CONSOLE_SCREEN_BUFFER_INFO+3) and -4
        INVOKE  GetConsoleScreenBufferInfo,ebx,esp
        movzx   eax,word ptr [esp].CONSOLE_SCREEN_BUFFER_INFO.dwSize.x
        movzx   edx,word ptr [esp].CONSOLE_SCREEN_BUFFER_INFO.dwSize.y
        mul     edx
        push    edx
        INVOKE  FillConsoleOutputCharacter,ebx,32,eax,edi,esp
        pop     eax
        movzx   edx,word ptr [esp].CONSOLE_SCREEN_BUFFER_INFO.wAttributes
        push    edx
        push    eax
        INVOKE  FillConsoleOutputAttribute,ebx,edx,eax,edi,esp
        INVOKE  SetConsoleCursorPosition,ebx,edi
        pop     ecx
        pop     edx
        xchg    eax,edi
        add     esp,(sizeof CONSOLE_SCREEN_BUFFER_INFO+3) and -4
        pop     edi
        pop     ebx
        ret     4

ConCls  ENDP

        OPTION  PROLOGUE:PrologueDef
        OPTION  EPILOGUE:EpilogueDef

;***********************************************************************************

[qWord]

[smartass]
Handles are void pointers and the correct definition is:

Code Select Expand

PVOID typedef ptr
HANDLE typedef PVOID
This declaration would work for 32 and 64 Bit platforms
[/smartass]
:bg

[dedndave]

....and still, it's a dword   :lol

[NathanStiles]

@qWord so using the method you mentioned keeps me from having to replace DWORD declarations used for pointers if my code should be built as 64bit?  Where/how is ptr defined?

@dedndave that code a bit more than I can understand at this point but I apprecate the other information :D I did notice the OPTION and remembered reading that directive "documentation" on MSDN yesterday.  Sadly the options are not explained.  I didn't get to review all the information presented to me in this thread yet but I assume I will eventually be interested in the OPTION directive and it's uses.

@steveasm thank you again

I'm a bit spoiled by VisualStudio and `go to definition`.  Is there some IDE that I can use to perform tasks like that for ASM?

[hutch--]

There is a little confusion going on here, a HANDLE is a unique ID for a target which can be may different things, memory reference, ID for a system defined window, a GDI object and so on.

The SIZE of a handle is determined by the operating system version, in 16 bit Windows it was WORD (2 bytes), in 32 bit Windows it is DWORD (4 bytes),in later version it is larger again and I have no doubt that when the 256 bit Version of Windows/Linux/Whatever appears it will be bigger again.

The reason why an assembler works in generic data sizes is because it works in processor registers and they are determined purely by their SIZE. C/C++ #defines and TYPEDEFs are equates to native data sizes of registers for the hardware that the OS version runs on.

[dedndave]

hi Nathan
MSDN may not be the best place to find info about OPTION
the masm manual is available...
http://www.4shared.com/zip/lCNJTTZk/MASM_61_Manuals_High_Quality_P.html

[NathanStiles]

dedndave that's version 6.1, just about the same version distributed with the masm32 library.  The last version in VS2010 is 10 I remember reading that certain ssse2(I think) instructions aren't supported in that 6.1 version how much is really different in 10 vs 6?

[dedndave]

well - the biggest difference is probably the level of SSE support
most of the syntax definitions have remained unchanged
MS seems to have updated masm a few times without updating the reference   :P
however, there is some reference material on MSDN