hi! roticv i think i need to read about mod 01 and so on , but can you try to explane it ?

thanks.
Posted on 2003-12-09 12:08:51 by Nguga
Originally posted by Nguga
i come to this conclusion , that LOCALS make the code much more bigger then not using locals.



after this i ask YOU all why use LOCALS ???

well i can code enterely without LOCALS , and is much more easy to do it
becouse i can use that everywere and can make new ones if i always need ...
so i do not see the point of using them :)


First of all, the only savings you get by not zeroing out the global object only happens if you call this code exactly once. If you call the procedure more than once, you'll need to zero out that global variable, too. So you don't save much there by using globals.

Also, note that global/static addresses are going to always be four-bytes long when encoded into an instruction. The first 128 bytes of local/automatic variables will only require a one-byte displacement. So if you reference the variables a large number of times, you can organize your local declarations so that most instructions only require a one-byte displacement, thus being shorter.

Locals and globals have completely different semantics. For example, you cannot write reentrant code using global variables. Likewise, when using static object (globals), the variables consume memory the entire lifetime of the application. Sure, your *code* is smaller, but the total amount of memory the program consumes is actually *larger* when using global/static variables (i.e., those bytes of data could just as easily have held a fair number of instructions).

Generally, you should use the variable type (static/global, automatic/local) based on the *semantics* of the storage and not worry as much about the few extra bytes of instructions needed to access one data type versus the other.

Cheers,
Randy Hyde
Posted on 2003-12-09 13:11:07 by rhyde
I only whant to clarify one thing with that say hutch--
or a LOCAL value that is created on the stack at the beginning of the procedure and destroyed at the exit of the procedure.


I dont understand destroyed, I think in two things, zeroize this locals before the return (this is a clean up of locals, you are not destroying nothing ;) ), or only return and this will only change the way you whant to access that locals, in fact, you can access esp, esp+4, esp+8, esp+(4*numberArgument), for the arguments, from the last to the first, the next is esp+(4*n)+(4) for the addres caller, and esp+(4*n)+(4)+(4) for the address of ebp, then you can access the locals at esp+(4*n)+(4)+(4)+(4*nL) where nL is the local to be accessed, if is a dword..., for example, this structure or representation in the stack:

: DWORD ebp + 12
: DWORD ebp + 8
: DWORD ebp + 4
: DWORD ebp
----- Base Pointer -----
: DWORD ebp - 4
: DWORD ebp - 8
: DWORD ebp - 12
----- "Top" of Stack -----


when you mov esp, ebp and pop ebp and ret 8 you can still access the value of the locals (and the arguments passed, etc) with esp+n, if they are not cleaned (not destroyed) before the return.. but shure.. that is tricky :D.

Nice day or night.
Posted on 2003-12-09 15:58:37 by rea
for nguga, you can do two things, modify a little your macro and for each name of local, define a


%macro stack 1-*
.....
;======
;despues de ->defenir_os_arg_locais %2,%1 ; chamar defenir local arg
%define %2_locebp somasizelocal
;======
.........



and make a new macro for invoke, that let you check this, , for example...



%macro invoke2ebp
........
%rep n ;el loop donde se hace el push de los argumentos...
%ifdef %1_locebp ;this
push ebp ; will do
sub dword[esp], %1_locebp ;the work

%elif .... ;here come the normal push (for statics and others not locals)
...
;the normal pushes...
...
stdpush ..
rotate.. and such things....
%endif
...
%endrep
....
%endmacro


hope you get the idea, and you can use a 'automatic' way of simulate what make the other call ....


Nice day or night.
Posted on 2003-12-09 16:14:33 by rea
hi all ! [[ ]]



i will not make any kind of macro like MASM has becouse i want to mantain
the logic of assembly not like the invoke macro that MASM has that is ilogical.



as far we have seen here this proc made in MASM:



TestProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

LOCAL opf:OPENFILENAMEA

mov opf.lStructSize, SIZEOF OPENFILENAME
invoke GetOpenFileNameA,addr opf

xor eax,eax
ret
TestProc endp




the output assembly generated is this for the :

INVOKE GetOpenFileNameA,addr opf


.text:00401125 lea eax,
.text:00401128 push eax ; LPOPENFILENAMEA
.text:00401129 call GetOpenFileNameA



that is ilogical for me , i rather prefer this i got in NASM NAGOA

what i code is real .

proc SaveBitmap

stack opf,OPENFILENAME_size,buffer1,1020
sectiondata
filter_bmp db "*.bmp",0,"*.bmp",0,0
sectioncode

lea eax,
call RtlZeroMemory,eax,OPENFILENAME_size
mov dword ,OPENFILENAME_size
mov dword , 1020
mov dword ,filter_bmp
push ebx
lea ebx,
call RtlZeroMemory,ebx,1020
mov dword ,ebx
pop ebx
lea eax,
call GetSaveFileNameA,eax
cmp eax, 0
jz .goOut
call SendMessageA,, WM_CAP_GRAB_FRAME, 0, 0
call SendMessageA,, WM_CAP_SAVEDIB,0,
call SendMessageA,, WM_CAP_SET_PREVIEW,TRUE, 0
.goOut

endproc





then i could use the other aproach of avoidind using lea .








proc SaveBitmap

stack opf,OPENFILENAME_size,buffer1,1020
sectiondata
filter_bmp db "*.bmp",0,"*.bmp",0,0
sectioncode

sub ebp,OPENFILENAME_size ; make ebp points to opf
call RtlZeroMemory,ebp,OPENFILENAME_size ; clean opf
add ebp,OPENFILENAME_size ; let ebp be ebp
mov dword ,OPENFILENAME_size
mov dword , 1020
mov dword ,filter_bmp
sub ebp,OPENFILENAME_size+1020 ; make ebp points to buffer1 size
call RtlZeroMemory,ebp,1020 ; clean buffer1
mov eax,ebp
add ebp,OPENFILENAME_size+1020 ; make ebp be ebp
mov dword ,eax
sub ebp,OPENFILENAME_size ; make ebp point to opf
call GetSaveFileNameA,ebp ; open dialog save of opf
add ebp,OPENFILENAME_size ; let ebp be ebp
cmp eax, 0
jz .goOut
call SendMessageA,, WM_CAP_GRAB_FRAME, 0, 0
call SendMessageA,, WM_CAP_SAVEDIB,0,
call SendMessageA,, WM_CAP_SET_PREVIEW,TRUE, 0
.goOut

endproc








so the invoke macro of NAGOA NASM is for me more logical .
Posted on 2003-12-09 18:15:51 by Nguga