Inspired by ToutEnMasm's ZEROLOCALES, I am trying to figure out an elegant (=tiny and fast) macro to clear the local variables. Here is what I got; I tested it quite a lot but am still uncertain whether my logic is valid for all situations, therefore please feedback! :bg
##### The Macro #####
ClearLocals MACRO
mov edx,edi ; move edi to a free ACD register
mov ecx,ebp ; Base pointer into counter
mov edi,esp ; current stack pointer as destination
sub ecx,edi ; subtract from counter
mov al,0 ; fill with zeros
cld ; forward
rep stosb ; fill
mov edi,edx ; get edi back for Windows
ENDM
##### Its usage: just call ClearLocals directly after the LOCALs #####
##### example taken from the recent MAPISendMail thread #####
SendMail proc MsgSubject:DWORD, MsgBody:DWORD, MsgPathAtt1:DWORD, MsgPathAtt2:DWORD
LOCAL hMAPI:DWORD
LOCAL dll_SEND:DWORD
LOCAL MMessage:MapiMessage ;48 bytes
LOCAL MsgFile2:MapiFileDesc ;structure on stack needs reverse order: File2 first
LOCAL MsgFile1:MapiFileDesc ;24 bytes
LOCAL MsgTO:MapiRecipDesc ;24 bytes
ClearLocals ;zeros from first to last local (eAx, eCx, eDx will be altered)
invoke LoadLibrary, chr$('MAPI32.dll')
... etc
Interesting JJ, thanks for sharing. :U
Nice idea.
Quote from: jj2007 on October 08, 2007, 03:02:09 PM
Inspired by ToutEnMasm's ZEROLOCALES, I am trying to figure out an elegant (=tiny and fast) macro to clear the local variables. Here is what I got; I tested it quite a lot but am still uncertain whether my logic is valid for all situations, therefore please feedback!
you can use dword-stosd without any worries as stack will never be unaligned (non dword).
also you can safely remove cld because all windows api-s assume that direction flag is cleared (conventional).
hence if one changes the dir.flag one should also clear it (if you use std - use cld when you are done).
ClearLocals MACRO
mov edx,edi
mov ecx,ebp
mov edi,esp
sub ecx,edi
xor eax,eax
shr ecx,2
rep stosd
mov edi,edx
ENDM
Quote from: drizz on October 08, 2007, 05:35:47 PM
you can use dword-stosd without any worries as stack will never be unaligned (non dword).
also you can safely remove cld because all windows api-s assume that direction flag is cleared (conventional).
hence if one changes the dir.flag one should also clear it (if you use std - use cld when you are done).
Re stack:
I guess a LOCAL MyByte:BYTE would cause the stack to increase by a WORD.
However, if you declare a
LOCAL MyWordVar:WORD
will the stack increase by a DWORD? if no, then
shr ecx,1
rep stosw
would be more appropriate.
I vaguely remember that shr with a counter of more than one costs a cycle more, while mov ax,0 and xor eax,eax cost roughly the same. Any opinions?
By the way, the macro could be modified to become a procedure - an option if you have lots of procedures that require initialising of locals.
Re direction flag: you are prefectly right - I googled this up:
http://support.microsoft.com/kb/106262
On Intel chips, DF can be set to 1 with the STD instruction and can be cleared to 0 with the CLD instruction. If a function sets DF to 1, it should clear DF before terminating. This allows all functions to make the assumption that DF is always 0.
All C run-time functions correctly clear DF upon termination. However, if an exception occurs before a function has a chance to clear DF, the flag will still be set when the exception handler is executed.
Quote from: jj2007 on October 09, 2007, 08:10:28 AMI guess a LOCAL MyByte:BYTE would cause the stack to increase by a WORD.
However, if you declare a
LOCAL MyWordVar:WORD
will the stack increase by a DWORD? if no, then
shr ecx,1
rep stosw
would be more appropriate.
do i need to repeat my self? :eek byte variable will also cause 4 byte allocation on stack.
Quote from: drizz on October 09, 2007, 02:56:19 PM
Quote from: jj2007 on October 09, 2007, 08:10:28 AMI guess a LOCAL MyByte:BYTE would cause the stack to increase by a WORD.
However, if you declare a
LOCAL MyWordVar:WORD
will the stack increase by a DWORD? if no, then
shr ecx,1
rep stosw
would be more appropriate.
do i need to repeat my self? :eek byte variable will also cause 4 byte allocation on stack.
No need for rolling your eyes, Drizz - I asked explicitly what happens with a WORD, not BYTE, local. And I wouldn't ask if 1) it had been explained in the masm32.hlp, see below, and 2. I would be sure that there is no option to "pack" wasteful byte declarations on the stack.
Cheers, JJ :bg
Syntax: LOCAL name [[count]][:qualifiedtype] [, name [[count]]
[:qualifiedtype]]...
Description:
Generates code to create one or more stack (automatic) variables,
which can be accessed only within the current procedure. The
assembler uses the same method used by high-level languages to
create local variables.
The <name> parameter is the name of the variable, and <count> is
an optional expression (which must appear in square brackets)
indicating the number of elements to allocate. The <qualifiedtype>
parameter is any qualified type appropriate to <name>. The default
<qualifiedtype> is WORD in a 16-bit segment and DWORD in a 32-bit
segment.
Once declared in a LOCAL statement, local variables can be
referred to by name. The assembler translates references to these
variables into references to their actual location on the stack
using the BP indirect addressing mode.
The assembler will generate an error if you have already defined
<name> as a label.
Example:
LOCAL array[20]:BYTE
>> ::) << :P
Quote from: jj2007 on October 09, 2007, 08:10:28 AMI guess
i advocate "go and try it out then ask" way of doing things... :bg
so you should have made a testproject and debug with olly trying out different combo for local variables
Cheers :bg
jj,
Here is what the idea looks like in Basic which does this by specification. It also sets a stack frame and does register preservations as well but it zeros the locals before user code is run.
0040111B fn_0040111B:
0040111B 55 push ebp ; set stack frame
0040111C 8BEC mov ebp,esp
0040111E 53 push ebx ; preserve 3 registers
0040111F 56 push esi
00401120 57 push edi
00401121 83EC64 sub esp,64h ; allocate local storage
00401124 681B114000 push 40111Bh
00401129 loc_00401129:
00401129 31F6 xor esi,esi ; clear ESI & EDI
0040112B 31FF xor edi,edi
0040112D B90D000000 mov ecx,0Dh ; set counter
00401132 loc_00401132:
00401132 56 push esi
00401133 49 dec ecx
00401134 75FC jnz loc_00401132 ; loop back to count in ECX
00401136 90 nop
00401137 90 nop
00401138 90 nop
00401139 90 nop
0040113A 90 nop
0040113B 90 nop
0040113C 8B8578FFFFFF mov eax,[ebp-88h]
00401142 8D65F4 lea esp,[ebp-0Ch]
00401145 5F pop edi
00401146 5E pop esi
00401147 5B pop ebx
00401148 5D pop ebp
00401149 C20400 ret 4
Quote from: hutch-- on November 02, 2007, 08:12:27 PM
jj,
Here is what the idea looks like in Basic which does this by specification. It also sets a stack frame and does register preservations as well but it zeros the locals before user code is run.
Thanks, very interesting. I guess you disassembled Visual Basic? The code is a lot more clumsy than the little macro (largely based on ToutEnMasm's code), but the principle is the same. I was a bit uncertain about the exact rules for local variables, i.e. 4-byte allocation on the stack even for byte & word variables, but colleagues here are always helpful in explaining :U
Its actually PowerBASIC which conforms to the specification for basic, stack frame, preserves all of the correct registers, zeros the local variables and sets strings to a NULL string. Align stack variables to a minimum of 4 bytes, larger data types should be aligned at their data size.
the reason that basic snippet (which doesnt look like VB by the way) uses push's instead of stos's is because push doesnt depend on the direction flag and its usualy bad form in an open development environment to alter the direction flag without changing it back (ie, this could be a library procedure called from an arbitrary development environment such as vb, vc, gcc, c#, delphi, etc.. ) .. nor should the code make assumptions about its state
I would use this sort of strategy to both allocate and initialize the locals:
init macro vars
 xor eax, eax
 if vars le 256
  mov cl, vars and 255 ; encode modulo 256
@@do:
dec cl
push eax
jnz @@do
 else
 mov ecx, vars
@@do:
dec ecx
push eax
jnz @@do
 endif
endm
weighs in at 9 bytes for 256 or less locals, or 11 bytes for 257 or more locals
Quote from: Rockoon on November 03, 2007, 05:23:53 PM
I would use this sort of strategy to both allocate and initialize the locals:
Fine if you have access to MASM's "LOCAL" routine (you aren't working for Microsoft by accident? :bg)
You also would have to know the number and size of the local variables.
The ClearLocals macro builds on current MASM behaviour, and works with all types of local variables including structures, by simply using the difference between base page and stack pointer after allocation of locals.
Quote from: hutch-- on November 03, 2007, 04:34:05 PM
Its actually PowerBASIC
Sigh! I have tinkered a bit with PB, hoping I could substitute my trusty old 16-bit GFA with a more recent model. However, PB has a bloat factor of about 5, and the compiler is roughly a factor of 10 slower; that on top of the porting difficulties for a 20,000 lines source forced me to keep an awkward mix of old Basic with a bit of new MASM... until Vista64 throws me out of the game, haha :bdg
Quote from: jj2007 on November 03, 2007, 06:44:01 PM
You also would have to know the number and size of the local variables.
The ClearLocals macro builds on current MASM behaviour, and works with all types of local variables including structures, by simply using the difference between base page and stack pointer after allocation of locals.
i'm sorry I thought you wanted "(=tiny and fast)"
stosb is definately not fast .. high minimum latency .. and its only a byte at a time
as far as your other criticisms.. are you lazy or something? :) .. none of them are actualy valid .. you can indeed calculate the size of the locals any way you want to and still rip through with pushes ..
..but now here is a criticism .. why would you want to initialize ALL locals? Seems like usualy you would only want to initialize structures.. individual temporary machine words should almost never need initialized memory because they start out as registers ..
.. for instance, any handles that get returned from api calls (such as hMAPI in the original post) .. no initial value is valid here .. the code would always ensure that its value was a non-erroring result of an api call .. so why initialize it?
Quote from: jj2007 on November 03, 2007, 06:44:01 PM
Quote from: Rockoon on November 03, 2007, 05:23:53 PM
I would use this sort of strategy to both allocate and initialize the locals:
Fine if you have access to MASM's "LOCAL" routine (you aren't working for Microsoft by accident? :bg)
You also would have to know the number and size of the local variables.
The ClearLocals macro builds on current MASM behaviour, and works with all types of local variables including structures, by simply using the difference between base page and stack pointer after allocation of locals.
All of this is accessible as part of the prologue (http://msdn2.microsoft.com/en-us/library/4zc781yh(VS.80).aspx) macro, which is well documented in Hutch's MASM help file and my additions to the link before. Adding initialisation is relatively simple based on the example there.
My personal preference is to initialise locals manually, since it's rare that you need everything zero initialised.
Cheers,
Zooba :U
jj,
Your comparison between 32 bit PB and 16 bit GFA basics is not well informed. 16 bit anything is smaller. I wrote 16 bit GFA basic in the early 90s and it was a good tool in its time but it never made the adaption to 32 bit code and effectively turned into a dead product. PB is a better dialect in that it properly handles LOCAL variable by default, GFA was a pain with its globals unless specified as local, PB has a very good inline assembler and a much bigger runtime library built into it. It is also fully written in assembler and just recently the compiler was ported to 32 bit so its much faster and has a far larger capacity.
Quote from: Rockoon on November 03, 2007, 07:16:14 PM
i'm sorry I thought you wanted "(=tiny and fast)"
stosb is definately not fast .. high minimum latency .. and its only a byte at a time
ClearLocals MACRO
mov edx, edi ; save edi to a free ACD register
mov ecx, ebp ; Base pointer into counter
mov edi, esp ; current stack pointer as destination
sub ecx, edi ; subtract from counter
shr ecx, 2 ; divide by 4, stack is dword aligned (3 bytes extra)
xor eax,eax ; we want zeroed locals
rep stosd ; fill (5 cycles per local variable)
mov edi, edx ; give edi back to Windows
ENDM
shr exc, 2 and stosd increase speed by a factor of 4 and size by 3 bytes - your choice. Nobody would use a procedure call with lots of local variables in an innermost time-critical loop, but anyway, I respect religious feelings about stosb.
Quote from: Rockoon on November 03, 2007, 07:16:14 PM
as far as your other criticisms.. are you lazy or something? :)
I am definitely lazy! That's why I wanted this macro: Just insert "ClearLocals" behind the last LOCAL, without any arguments, and be reassured there is no garbage in your local variables.
Quote from: Rockoon on November 03, 2007, 07:16:14 PM
.. none of them are actualy valid .. you can indeed calculate the size of the locals any way you want to and still rip through with pushes ..
..but now here is a criticism .. why would you want to initialize ALL locals? Seems like usualy you would only want to initialize structures.. individual temporary machine words should almost never need initialized memory because they start out as registers ..
.. for instance, any handles that get returned from api calls (such as hMAPI in the original post) .. no initial value is valid here .. the code would always ensure that its value was a non-erroring result of an api call .. so why initialize it?
Of course, you can calculate the size and do other athletic exercises, but me I want it simple & stupid. And yes you are not forced to initialize your locals. Nobody forces you to type "ClearLocals" after your last LOCAL. Nobody forces you to use horribly un-professional constructs like .IF eax==0 in your code. These things are meant for lazy unprofessional old people like me...
Quote from: jj2007 on November 04, 2007, 10:39:47 AM
I am definitely lazy! That's why I wanted this macro..
..the basic strategies have been expained to you .. if you complain about such trivial details such as how the amount of memory is handed to the macro then I can only assume one thing.. that you are so lazy that you want others to not only define a strategy but also implement it for you...
cut and paste much?
Well... I think it's a nifty idea. Good job. :U
Quote from: Mark Jones on November 04, 2007, 05:14:43 PM
Well... I think it's a nifty idea. Good job. :U
You made my day, thanxalot :bg
Assuming we're in a "proc" block or a routine that uses either of these:
enter bytes,0
...
push ebp
mov ebp,esp
sub esp,bytes ;"bytes" certainly should be a multiple of 4
this works, a little more neatly than Basic's method:
@localzeros macro bytes
mov ecx,bytes/4
mov esp,ebp
@@: push 0
loop @B
endm
...
myroutine proc var1:DORD
@localzeros 20h
;do whatever with the data
@localzeros 20h ;reset the locals
;do some more stuff
ret ;inside a proc, "ret" is a macro which uses "leave" or "mov esp,ebp"
myroutine endp
This manoeuvre is used in some C routines I have seen.
Although the CPU supports instructions such as "dec esp" and "inc esp", those quickly cause trouble in protected mode. ESP should always be a multiple of four.
Not quite sure if I understood what your routines do, but the second one requires that you know the size of your locals.
My version seems almost foolproof, although I modified it recently to preserve edx; while ecx is still NOT preserved.
Usage example:
DlgHook proc hwnd:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
LOCAL rcDesktop:RECT, rcNew:RECT
LOCAL sLen:DWORD,ColWidth:DWORD,ecxR:DWORD
LOCAL colTxt:DWORD,colBg:DWORD
LOCAL hLVID:DWORD
LOCAL lvi:LVITEM,hdi:HDITEM
LOCAL lvc:LVCOLUMN
LOCAL lvFlag:DWORD, lvCt:DWORD, lvPos:DWORD
LOCAL LocBuf[lBuf]:BYTE, pBuf:DWORD
ClearLocals ; all done!
ClearLocals MACRO ; first instruction after LOCALS - ecx NOT preserved!!
mov eax, edi ; save edi to a free ACD register
mov ecx, ebp ; Base pointer into counter
mov edi, esp ; current stack pointer as destination
sub ecx, edi ; subtract from counter
shr ecx, 2 ; divide by 4, stack is dword aligned (3 bytes extra)
push eax ; contains original edi
xor eax,eax ; we want zeroed locals
rep stosd ; fill (5 cycles per local variable)
pop edi ; give edi back to Windows
ENDM
The routine "myroutine" was just a stub to illustrate where the macro could go, first to zero the locals on entry to the routine, and again later in the routine, even if there is new stuff on the stack at that point. Variant:
@resetlocals macro ;zero everything from esp up to ebp
mov ecx,ebp
sub ecx,esp
mov esp,ebp ;discard existing locals
shr ecx,2
@@: push 0
loop @B
;esp is now the same as it was prior to the macro
endm
Hello,
After reading this posts and make some experiments ,I have found one error.
A correct optimized macro is:
Quote
ZEROLOCALES MACRO dernierelocale:REQ
mov edx,edi
mov ecx,ebp
lea edi,dernierelocale
sub ecx,edi
xor eax,eax
shr ecx,2
rep stosd
mov edi,edx
ENDM
Loading edi with the adress of the last local is required.In case you used "uses esi edi ebx" , those three registers are erased if you put esp in edi
Since I need this very often, I decided to re-write it as a procedure. Usage:
MyProggieWithFunnyLocals proc
LOCAL tmp:DWORD, tl:DWORD, flShow:DWORD
LOCAL xPosC:DWORD, yPosC:DWORD, HtC:DWORD, WdC:DWORD
LOCAL TxSize:SIZEL
LOCAL rc:RECT
LOCAL CtrlDc:DWORD
LOCAL LocBuf[60]:BYTE
call ClearLocals
.. do things ...
As you see, no arguments are needed, so even PROTO and INVOKE are not necessary. But you need one global variable in the data? section.
jj
.data?
EspGlob dd ?
...
ClearLocals proc ; first instruction after LOCALS - eax will be zero on exit
pop EspGlob ; save the return address - now the stack is identical to the calling procedure
xchg eax,ecx ; save ecx
mov ecx,ebp ; base page of calling procedure
sub ecx,esp ; ebp - esp = No. of bytes in locals
mov esp,ebp ; discard existing locals
shr ecx,2 ; divide by four
@@: push 0 ; dwords on stack
loop @B
xchg eax,ecx ; restore ecx
push EspGlob ; restore the return address
ret
ClearLocals endp
Hello,
To jj2007,your proc go to
crash if you use "uses esi edi ebx"
see this
Quote
push ebp
mov ebp,esp
add esp,0FFFFFDA8h ;- size of local
push esi
push edi
push ebx
<- esp is here
pop ebx
pop edi
pop esi
leave
ret
Quote from: ToutEnMasm on February 20, 2008, 09:36:13 PM
Hello,
To jj2007,your proc go to crash if you use "uses esi edi ebx"
Quote
Thanks for this warning, ToutEnMasm. :U