hi all !
i was using MASM and testing this in side a proc . and this does not work :
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
then i tried this , and works fine :
.data
opf OPENFILENAME <?>
TestProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
mov opf.lStructSize, SIZEOF OPENFILENAME
invoke GetOpenFileNameA,addr opf
xor eax,eax
ret
TestProc endp
why the local does not work ?? and when in data works ?
i was using MASM and testing this in side a proc . and this does not work :
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
then i tried this , and works fine :
.data
opf OPENFILENAME <?>
TestProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
mov opf.lStructSize, SIZEOF OPENFILENAME
invoke GetOpenFileNameA,addr opf
xor eax,eax
ret
TestProc endp
why the local does not work ?? and when in data works ?
.text:00401118 sub_401118 proc near ; DATA XREF: sub_401031+14o
.text:00401118
.text:00401118 var_4C = tagOFNA ptr -4Ch
.text:00401118 hWnd = dword ptr 8
.text:00401118 Msg = dword ptr 0Ch
.text:00401118 wParam = dword ptr 10h
.text:00401118 lParam = dword ptr 14h
.text:00401118
.text:00401118 push ebp
.text:00401119 mov ebp, esp
.text:0040111B add esp, 0FFFFFFB4h
.text:0040111E mov , 4Ch
.text:00401125 lea eax,
.text:00401128 push eax ; LPOPENFILENAMEA
.text:00401129 call GetOpenFileNameA
this is the assembly that MASM outputs
just to help
.text:00401118
.text:00401118 var_4C = tagOFNA ptr -4Ch
.text:00401118 hWnd = dword ptr 8
.text:00401118 Msg = dword ptr 0Ch
.text:00401118 wParam = dword ptr 10h
.text:00401118 lParam = dword ptr 14h
.text:00401118
.text:00401118 push ebp
.text:00401119 mov ebp, esp
.text:0040111B add esp, 0FFFFFFB4h
.text:0040111E mov , 4Ch
.text:00401125 lea eax,
.text:00401128 push eax ; LPOPENFILENAMEA
.text:00401129 call GetOpenFileNameA
this is the assembly that MASM outputs
just to help
by the way the assembly output looks NASM code :)
Nguga
need clean opf, eg
need clean opf, eg
invoke RtlZeroMemory, addr opf, sizeof opf
mov opf.lStructSize, sizeof opfSpaciva VAM !
i come to this conclusion , that LOCALS make the code much more bigger then not using locals.
TestProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
LOCAL opf:OPENFILENAMEA
invoke RtlZeroMemory, addr opf, sizeof opf
mov opf.lStructSize,sizeof opf
invoke GetOpenFileNameA,addr opf
xor eax,eax
ret
TestProc endp
lets see the real ASSEMBLY output that MASM makes of a PROC using LOCALS:
=======================================================
MASM PROC OUTPUT :
.text:00401118 sub_401118 proc near ; DATA XREF: sub_401031+14o
.text:00401118
.text:00401118 var_4C = tagOFNA ptr -4Ch
.text:00401118 hWnd = dword ptr 8
.text:00401118 Msg = dword ptr 0Ch
.text:00401118 wParam = dword ptr 10h
.text:00401118 lParam = dword ptr 14h
.text:00401118
.text:00401118 push ebp
.text:00401119 mov ebp, esp
.text:0040111B add esp, 0FFFFFFB4h
.text:0040111E push 4Ch
.text:00401120 lea eax,
.text:00401123 push eax
.text:00401124 call RtlZeroMemory
.text:00401129 mov , 4Ch
.text:00401130 lea eax,
.text:00401133 push eax ; LPOPENFILENAMEA
.text:00401134 call GetOpenFileNameA
very big mmmmmmmm....
============================================
============================================
if we declare that in DATA like this
===========================
.data
opf OPENFILENAME <?>
TestProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
mov opf.lStructSize, sizeof opf
invoke GetOpenFileNameA,addr opf
xor eax,eax
ret
TestProc endp
The Real assembly ouput of MASM is litle !:
==============================
.text:00401118 sub_401118 proc near ; DATA XREF: sub_401031+14o
.text:00401118
.text:00401118 hWnd = dword ptr 8
.text:00401118 Msg = dword ptr 0Ch
.text:00401118 wParam = dword ptr 10h
.text:00401118 lParam = dword ptr 14h
.text:00401118
.text:00401118 push ebp
.text:00401119 mov ebp, esp
.text:0040111B mov dword_403019, 4Ch
.text:00401125 push offset dword_403019 ; LPOPENFILENAMEA
.text:0040112A call GetOpenFileNameA
well i supose it is much more litle and it was only one LOCAL .....
============================================
============================================
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 :)
TestProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
LOCAL opf:OPENFILENAMEA
invoke RtlZeroMemory, addr opf, sizeof opf
mov opf.lStructSize,sizeof opf
invoke GetOpenFileNameA,addr opf
xor eax,eax
ret
TestProc endp
lets see the real ASSEMBLY output that MASM makes of a PROC using LOCALS:
=======================================================
MASM PROC OUTPUT :
.text:00401118 sub_401118 proc near ; DATA XREF: sub_401031+14o
.text:00401118
.text:00401118 var_4C = tagOFNA ptr -4Ch
.text:00401118 hWnd = dword ptr 8
.text:00401118 Msg = dword ptr 0Ch
.text:00401118 wParam = dword ptr 10h
.text:00401118 lParam = dword ptr 14h
.text:00401118
.text:00401118 push ebp
.text:00401119 mov ebp, esp
.text:0040111B add esp, 0FFFFFFB4h
.text:0040111E push 4Ch
.text:00401120 lea eax,
.text:00401123 push eax
.text:00401124 call RtlZeroMemory
.text:00401129 mov , 4Ch
.text:00401130 lea eax,
.text:00401133 push eax ; LPOPENFILENAMEA
.text:00401134 call GetOpenFileNameA
very big mmmmmmmm....
============================================
============================================
if we declare that in DATA like this
===========================
.data
opf OPENFILENAME <?>
TestProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
mov opf.lStructSize, sizeof opf
invoke GetOpenFileNameA,addr opf
xor eax,eax
ret
TestProc endp
The Real assembly ouput of MASM is litle !:
==============================
.text:00401118 sub_401118 proc near ; DATA XREF: sub_401031+14o
.text:00401118
.text:00401118 hWnd = dword ptr 8
.text:00401118 Msg = dword ptr 0Ch
.text:00401118 wParam = dword ptr 10h
.text:00401118 lParam = dword ptr 14h
.text:00401118
.text:00401118 push ebp
.text:00401119 mov ebp, esp
.text:0040111B mov dword_403019, 4Ch
.text:00401125 push offset dword_403019 ; LPOPENFILENAMEA
.text:0040112A call GetOpenFileNameA
well i supose it is much more litle and it was only one LOCAL .....
============================================
============================================
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 :)
Nguga
RtlZeroMemory and initialize some members necessary in both case.
i prefer local variable.
RtlZeroMemory and initialize some members necessary in both case.
i prefer local variable.
MASM is pretty bad with local variables, the best assembler I have found for locals is GoAsm:
With local
With global
A few extra bytes, for longer procs you actually save space as the overhead is already paid.erw
With local
00401095 /. 55 PUSH EBP
00401096 |. 89E5 MOV EBP,ESP
00401098 |. 83EC 4C SUB ESP,4C
0040109B |. 6A 4C PUSH 4C ; /Length = 4C (76.)
0040109D |. 55 PUSH EBP ; |Destination
0040109E |. 830424 B4 ADD DWORD PTR SS:[ESP],-4C ; |
004010A2 |. E8 6B4F0000 CALL <JMP.&KERNEL32.RtlZeroMemory> ; \RtlZeroMemory
004010A7 |. C745 B4 4C0000>MOV [LOCAL.19],4C
004010AE |. 55 PUSH EBP ; /pOpenFileName
004010AF |. 830424 B4 ADD DWORD PTR SS:[ESP],-4C ; |
004010B3 |. E8 724F0000 CALL <JMP.&comdlg32.GetOpenFileNameA> ; \GetOpenFileNameA
004010B8 |. 31C0 XOR EAX,EAX
004010BA |. 89EC MOV ESP,EBP
004010BC |. 5D POP EBP
004010BD \. C2 1000 RETN 10With global
00401095 /. 55 PUSH EBP
00401096 |. 89E5 MOV EBP,ESP
00401098 |. 6A 4C PUSH 4C ; /Length = 4C (76.)
0040109A |. 68 04204000 PUSH DialogBo.00402004 ; |Destination = DialogBo.00402004
0040109F |. E8 6E4F0000 CALL <JMP.&KERNEL32.RtlZeroMemory> ; \RtlZeroMemory
004010A4 |. C705 04204000 >MOV DWORD PTR DS:[402004],4C
004010AE |. 68 04204000 PUSH DialogBo.00402004 ; /pOpenFileName = DialogBo.00402004
004010B3 |. E8 724F0000 CALL <JMP.&comdlg32.GetOpenFileNameA> ; \GetOpenFileNameA
004010B8 |. 31C0 XOR EAX,EAX
004010BA |. 5D POP EBP
004010BB \. C2 1000 RETN 10A few extra bytes, for longer procs you actually save space as the overhead is already paid.erw
donkey you sad this : its not ok.... :)
[ With global
code:
00401095 /. 55 PUSH EBP
00401096 |. 89E5 MOV EBP,ESP
00401098 |. 6A 4C PUSH 4C ; /Length = 4C (76.)
0040109A |. 68 04204000 PUSH DialogBo.00402004 ; |Destination = DialogBo.00402004
0040109F |. E8 6E4F0000 CALL <JMP.&KERNEL32.RtlZeroMemory> ; \RtlZeroMemory
004010A4 |. C705 04204000 >MOV DWORD PTR DS:[402004],4C
004010AE |. 68 04204000 PUSH DialogBo.00402004 ; /pOpenFileName = DialogBo.00402004
004010B3 |. E8 724F0000 CALL <JMP.&comdlg32.GetOpenFileNameA> ; \GetOpenFileNameA
004010B8 |. 31C0 XOR EAX,EAX
004010BA |. 5D POP EBP
004010BB \. C2 1000 RETN 10 ]
we do not need this line in globals :)
00401098 |. 6A 4C PUSH 4C ; /Length = 4C (76.)
0040109A |. 68 04204000 PUSH DialogBo.00402004 ; |Destination = DialogBo.00402004
0040109F |. E8 6E4F0000 CALL <JMP.&KERNEL32.RtlZeroMemory> ;
less code :)
NASM using NAGOA.INC PROC is like this
=============================
proc TestProcNAGOA
stack opf,OPENFILENAME_size
lea eax,
call RtlZeroMemory,eax,OPENFILENAME_size ; this is needeed :)
mov dword ,OPENFILENAME_size
lea eax,
call GetSaveFileName,eax
endproc
The NASM NAGOA output in assembly is:
============================
code:00402E20 sub_402E20 proc near ; CODE XREF: start+AF3p
code:00402E20
code:00402E20 var_4C = tagOFNA ptr -4Ch
code:00402E20
code:00402E20 push ebp
code:00402E21 mov ebp, esp
code:00402E23 sub esp, 4Ch
code:00402E29 lea eax,
code:00402E2C push 4Ch
code:00402E31 push eax
code:00402E32 call ds:RtlZeroMemory
code:00402E38 mov , 4Ch
code:00402E3F lea eax,
code:00402E42 push eax ; LPOPENFILENAMEA
code:00402E43 call ds:GetSaveFileNameA ; Create a Save common dialog box
code:00402E49 leave
code:00402E4A retn 0
code:00402E4A sub_402E20 endp
prety good is not it ? :)
[ With global
code:
00401095 /. 55 PUSH EBP
00401096 |. 89E5 MOV EBP,ESP
00401098 |. 6A 4C PUSH 4C ; /Length = 4C (76.)
0040109A |. 68 04204000 PUSH DialogBo.00402004 ; |Destination = DialogBo.00402004
0040109F |. E8 6E4F0000 CALL <JMP.&KERNEL32.RtlZeroMemory> ; \RtlZeroMemory
004010A4 |. C705 04204000 >MOV DWORD PTR DS:[402004],4C
004010AE |. 68 04204000 PUSH DialogBo.00402004 ; /pOpenFileName = DialogBo.00402004
004010B3 |. E8 724F0000 CALL <JMP.&comdlg32.GetOpenFileNameA> ; \GetOpenFileNameA
004010B8 |. 31C0 XOR EAX,EAX
004010BA |. 5D POP EBP
004010BB \. C2 1000 RETN 10 ]
we do not need this line in globals :)
00401098 |. 6A 4C PUSH 4C ; /Length = 4C (76.)
0040109A |. 68 04204000 PUSH DialogBo.00402004 ; |Destination = DialogBo.00402004
0040109F |. E8 6E4F0000 CALL <JMP.&KERNEL32.RtlZeroMemory> ;
less code :)
NASM using NAGOA.INC PROC is like this
=============================
proc TestProcNAGOA
stack opf,OPENFILENAME_size
lea eax,
call RtlZeroMemory,eax,OPENFILENAME_size ; this is needeed :)
mov dword ,OPENFILENAME_size
lea eax,
call GetSaveFileName,eax
endproc
The NASM NAGOA output in assembly is:
============================
code:00402E20 sub_402E20 proc near ; CODE XREF: start+AF3p
code:00402E20
code:00402E20 var_4C = tagOFNA ptr -4Ch
code:00402E20
code:00402E20 push ebp
code:00402E21 mov ebp, esp
code:00402E23 sub esp, 4Ch
code:00402E29 lea eax,
code:00402E2C push 4Ch
code:00402E31 push eax
code:00402E32 call ds:RtlZeroMemory
code:00402E38 mov , 4Ch
code:00402E3F lea eax,
code:00402E42 push eax ; LPOPENFILENAMEA
code:00402E43 call ds:GetSaveFileNameA ; Create a Save common dialog box
code:00402E49 leave
code:00402E4A retn 0
code:00402E4A sub_402E20 endp
prety good is not it ? :)
For the RtlZeroMemory, you only don't need it if you have not used the structure before, if you wish to reuse the proc (ie normal usage) it must be done so in reality it has to be included to make a real example.
BTW GoAsm with locals is 2 bytes smaller than your NASM example if you look at it, and it doesn't trash eax like MASM and NASM, that is my objection to MASM, sad to see that NASM does the same.
BTW GoAsm with locals is 2 bytes smaller than your NASM example if you look at it, and it doesn't trash eax like MASM and NASM, that is my objection to MASM, sad to see that NASM does the same.
THANKS :)
i will change the PROC in NASM , , to make it RIGHT !!
EBP
ADD DWORD PTR SS:,-4C ; /pOpenFileName ebp-4C = OPENFILENAME :)
thats wise !!!
NASM NAGOA.INC it will be like this too RIGHT WAY!
i will change the PROC in NASM , , to make it RIGHT !!
EBP
ADD DWORD PTR SS:,-4C ; /pOpenFileName ebp-4C = OPENFILENAME :)
thats wise !!!
NASM NAGOA.INC it will be like this too RIGHT WAY!
thats wise !!!
It's Jeremy Gordon who is wise, he wrote what is perhaps the best assembler I have seen to date.
sad to see that NASM does the same
No, is the programer, in this case the one that write the macro, now refering to the past...
in thx and hi in the past, when I was coding I see this posibility, but nobody say me if is more eficient instead of lea, i see now, that I can do de modifications to pass the arguments, doing the suficient manipulation with the ebp or esp register.
in fact, can be easy done some like this, if I not remember wrong the names like ..nameOfVar hold the 'displacement' from the ebp register, then using this...
The important is how it pass the argument in this case locals, to the function to be called
code:00402E29 lea eax, [ebp+var_4C]
code:00402E2C push 4Ch
code:00402E31 push eax
code:00402E32 call ds:RtlZeroMemory
code:00402E3F lea eax, [ebp+var_4C]
code:00402E42 push eax ; LPOPENFILENAMEA
code:00402E43 call ds:GetSaveFileNameA ; Create a Save common dialog box
--------------------------------------------------------
push 4c
0040109D |. 55 PUSH EBP ; |Destination
0040109E |. 830424 B4 ADD DWORD PTR SS:[ESP],-4C ; |
004010A2 |. E8 6B4F0000 CALL <JMP.&KERNEL32.RtlZeroMemory> ; \RtlZeroMemory
push 4c
004010AE |. 55 PUSH EBP ; /pOpenFileName
004010AF |. 830424 B4 ADD DWORD PTR SS:[ESP],-4C ; |
004010B3 |. E8 724F0000 CALL <JMP.&comdlg32.GetOpenFileNameA> ; \GetOpenFileNameA
Is interesting that he uses this way to pass data, in the past push/pop vs invoke , i remember that when I was coding the macro, i question what will be more fast: lea eax, or some like mov eax, ebp and sub eax, some
now i see that the correct combination is...
push ebp
sub dword, some_value
If i dont remember badly, the 'displacement' from the ebp to the required local is in the name of the local prefixe by two points, for example:
local hwnd, HWND
local wnd, WNDCLASSEX, msg, MSG
the displacement respect the ebp of
.hwnd is ..hwnd
.wnd is ..wnd
.msg is ..msg
that in respect is:
..hwnd = 0
..wnd = 4
..msg = ..hwnd+WNDCLASSEX_size
nguga, remember that I use the prefixed point, adn you work for delete it ;), a local of the macro funct is: ".name" and hold some like "ebp-some", the 'some' is holded in "..name"
then istead of the combination in nasm of:
lea eax, ; or without this expansion: lea eax, [.opf]
push dword 0x4Ch
push eax
call ds:RtlZeroMemory
it will be:
push dword 0x4c
push ebp
add dword, ..opf
and tada!!!, without modifications to the macro proc or funct you have the same thing working, the thing here with nasm is that nasm do what you say to do...
If we dont know this strategies, then you can not siply use it or them, remember that whit a macro that i wrote, and some that i refer in the links that i provide here, is suported directly the proc or funct without tack frames and only manipulated via esp.
nguga, check out the values of ..vaiableName
I think should work some like:
%error ..variableName
or:
%assign xval ..variableName
%error xval
some one of this two should work, and report the displacement of each local.
But nice to see other strategy here, also i think I can code a macro that move directly the arguments instead of push/pop thing, and only one balance, other thing that I question in the past and now i know is posible ;).
Nice ay or night.
I only point some, because of the know that the two prefixed point is some important to nasm, here I quote what is inside of the f_4_n.inc
; v0.3 17/05/2003 10:47a.m.
; (*)I delete the simbols .. this simbols are special things of nasm
; then i replace this simbols like: ..<name> with: .isTempValue.<name>
; i think now ..lParam is .isTempValue.lParam, but you still accesing the local var
; in your function/proc with .<name>
If you have a new version that this macro, then you should acces .isTempValue.nameOfLocal instead of the anteriors that they will be ..nameOfLocal, for example:
funct WinMain, hInst, hPrevInst, CmdLine, CmdShow
local wc, WNDCLASSEX
local msg, MSG
local hwnd, HWND
sizef 80
%error .isTempValue.wc
%error .isTempValue.msg
%error .isTempValue.hwnd
endfunct
will report:
p11_3.asm:43: warning: 48
p11_3.asm:44: warning: 76
p11_3.asm:45: warning: 80
then I think if we will use this strategy, is necesary change .isTempValue. to some more short and fast to write and to have more significate to us, for the moment i think in some like:
.l.name or .dis.name or ...name dunno any sugestions??? for reference them????
Nice day or night.
; v0.3 17/05/2003 10:47a.m.
; (*)I delete the simbols .. this simbols are special things of nasm
; then i replace this simbols like: ..<name> with: .isTempValue.<name>
; i think now ..lParam is .isTempValue.lParam, but you still accesing the local var
; in your function/proc with .<name>
If you have a new version that this macro, then you should acces .isTempValue.nameOfLocal instead of the anteriors that they will be ..nameOfLocal, for example:
funct WinMain, hInst, hPrevInst, CmdLine, CmdShow
local wc, WNDCLASSEX
local msg, MSG
local hwnd, HWND
sizef 80
%error .isTempValue.wc
%error .isTempValue.msg
%error .isTempValue.hwnd
endfunct
will report:
p11_3.asm:43: warning: 48
p11_3.asm:44: warning: 76
p11_3.asm:45: warning: 80
then I think if we will use this strategy, is necesary change .isTempValue. to some more short and fast to write and to have more significate to us, for the moment i think in some like:
.l.name or .dis.name or ...name dunno any sugestions??? for reference them????
Nice day or night.
hi ! HGB :)
NAGOA is working with
;;=====pedrogc macros ==undef resolved !=======
;; 33 parameters 33 locals
wich are not your hgb macros its another aproach without that
. thing ....
;------------------------------------------------
; proc Funcion,arg1,..,argN
;
; stack var1,4,msg,MSG_size,hWnd,4 ; locals using stack !
;
; mov ,eax
;
; CONST ola , "ola meu!",0 ; data declared in code !
;
; return ; jump to endrotin
;
; lea eax,
;
; return 1 ; jump to endrotin and eax=1
;
; mov eax,
;
; endproc
;-------------------------------------------------
its this one :
;======================
; tipo par de argumentos sem fim
; stack var1,4,var2,4,msg,28
;======================
%macro stack 1-*
%ifctx rotin
%assign somasizelocal 0
%assign %%pare_Argts ((%0) / 2)
%rep %%pare_Argts
%assign somasizelocal somasizelocal+%2
;======
defenir_os_arg_locais %2,%1 ; chamar defenir local arg
;======
%assign n_arg_l n_arg_l+1 ; INCREMENTAR PARA O PROXIMO LOCAL !
%assign c_local_ n_arg_l
%rotate 2
%endrep
sub esp,somasizelocal
%endif
%endmacro
;=====================
;; ======================
%macro defenir_os_arg_locais 2
%if n_arg_l=1
%define %2 pupu_
%define pupu_ ebp - %1
;%error mnmnm pupu_
%endif
NAGOA is working with
;;=====pedrogc macros ==undef resolved !=======
;; 33 parameters 33 locals
wich are not your hgb macros its another aproach without that
. thing ....
;------------------------------------------------
; proc Funcion,arg1,..,argN
;
; stack var1,4,msg,MSG_size,hWnd,4 ; locals using stack !
;
; mov ,eax
;
; CONST ola , "ola meu!",0 ; data declared in code !
;
; return ; jump to endrotin
;
; lea eax,
;
; return 1 ; jump to endrotin and eax=1
;
; mov eax,
;
; endproc
;-------------------------------------------------
its this one :
;======================
; tipo par de argumentos sem fim
; stack var1,4,var2,4,msg,28
;======================
%macro stack 1-*
%ifctx rotin
%assign somasizelocal 0
%assign %%pare_Argts ((%0) / 2)
%rep %%pare_Argts
%assign somasizelocal somasizelocal+%2
;======
defenir_os_arg_locais %2,%1 ; chamar defenir local arg
;======
%assign n_arg_l n_arg_l+1 ; INCREMENTAR PARA O PROXIMO LOCAL !
%assign c_local_ n_arg_l
%rotate 2
%endrep
sub esp,somasizelocal
%endif
%endmacro
;=====================
;; ======================
%macro defenir_os_arg_locais 2
%if n_arg_l=1
%define %2 pupu_
%define pupu_ ebp - %1
;%error mnmnm pupu_
%endif
using no eax register in NASM NAGOA.INC
sub ebp,70
call RtlZeroMemory,ebp,OPENFILENAME_size
add ebp,70
mov dword ,OPENFILENAME_size
mov dword ,buffer1
mov dword ,1020
mov dword ,filter_bmp
sub ebp,70
call GetSaveFileName,ebp
add ebp,70
ebp-70 = opf
70 = OPENFILENAME_size
so its like GoASM
sub ebp,70
call RtlZeroMemory,ebp,OPENFILENAME_size
add ebp,70
mov dword ,OPENFILENAME_size
mov dword ,buffer1
mov dword ,1020
mov dword ,filter_bmp
sub ebp,70
call GetSaveFileName,ebp
add ebp,70
ebp-70 = opf
70 = OPENFILENAME_size
so its like GoASM
why ? use locals when it makes the code more bigger ???
i pass without locals very well ! and makes the code litle .
i pass without locals very well ! and makes the code litle .
Relative to the ebp, if the offset is less than -128, the instruction would be encoded as mod 01 which has a 1byte displacement. However if more than that it would be encoded as mod 10 which has 4byte displacement. So in short, what does matters is the size of local variable. Hope you understand.
why ? use locals when it makes the code more bigger ???
i pass without locals very well ! and makes the code litle .
There is little need of procs besides to use local variables. If you pass a parameter to the proc it is on the stack and is accessed by the same means as a local so if you wish to really save a couple of bytes you can just banish stack frames completely. Anything that you can do with a stack frame can be done with call/ret and no stack frame so why bother with them. The fact is that they are tools to facilitate programming, locals allow you to discard a variable once you don't need it anymore. You should add the 4C bytes of the structure to your calculation of the size of your non-local proc, they are integral to the procedure and permanent so they are in reality a part of it even though they reside outside the address range of the actual proc. In that case the global method is substantially larger than the local one which discards those 4C bytes and therefore does not have them counted in it's size. To prove that those bytes must be included as part of the calculation, try to run the proc without them, if you can't then they are part of the proc and must be counted.
just found what HUTCH thinks about LOCALS and i agree with im very much !
"The choice between GLOBAL and LOCAL variables is the scope in which you need them. In assembler, the difference between a value placed in the DATA or DATA? sections which has GLOBAL scope in the module or a LOCAL value that is created on the stack at the beginning of the procedure and destroyed at the exit of the procedure.
If a value is only needed during a procedure, it makes sense to make it LOCAL as you can reuse the name in another procedure with no problems and it means you can isolate a procedure by using LOCAL values. Stack locals are generally faster as they are recently created and should be in the DATA cache. This is what Intel recommend for values that only need scope within a procedure.
I personally make a habit of making handles GLOBAL so I can use them across many different procs without a messy parameter list for procedure calls but where I don't need GLOBAL scope, I regularly use LOCAL values.
Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd "
"The choice between GLOBAL and LOCAL variables is the scope in which you need them. In assembler, the difference between a value placed in the DATA or DATA? sections which has GLOBAL scope in the module or a LOCAL value that is created on the stack at the beginning of the procedure and destroyed at the exit of the procedure.
If a value is only needed during a procedure, it makes sense to make it LOCAL as you can reuse the name in another procedure with no problems and it means you can isolate a procedure by using LOCAL values. Stack locals are generally faster as they are recently created and should be in the DATA cache. This is what Intel recommend for values that only need scope within a procedure.
I personally make a habit of making handles GLOBAL so I can use them across many different procs without a messy parameter list for procedure calls but where I don't need GLOBAL scope, I regularly use LOCAL values.
Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd "