The MASM Forum Archive 2004 to 2012
Welcome, Guest. Please login or register.
March 23, 2023, 07:27:00 AM

Login with username, password and session length
Search:     Advanced search
128553 Posts in 15254 Topics by 684 Members
Latest Member: mottt
* Home Help Search Login Register
+  The MASM Forum Archive 2004 to 2012
|-+  General Forums
| |-+  The Campus
| | |-+  About LOCAL string
« previous next »
Pages: [1] 2 Print
Author Topic: About LOCAL string  (Read 10948 times)
stbfish
Guest


Email
About LOCAL string
« on: September 16, 2009, 06:08:02 AM »


LOCAL szDir[124]:BYTE

how to initialize it to all 0? like this szBuffer db 124 dup(0)

when i define a LOCAL Var, what is the default value inside?
Logged
BlackVortex
Member
*****
Posts: 983



Re: About LOCAL string
« Reply #1 on: September 16, 2009, 06:47:05 AM »

Well, default value is zero !

Right ?
Logged
sinsi
Member
*****
Gender: Male
Posts: 1758


RIP Bodie 1999-2011


Re: About LOCAL string
« Reply #2 on: September 16, 2009, 07:02:02 AM »

Because locals are on the stack they could be any value. You will need to zero it yourself - RtlZeroMemory I think will work here.
Logged

Light travels faster than sound, that's why some people seem bright until you hear them.
ecube
Guest


Email
Re: About LOCAL string
« Reply #3 on: September 16, 2009, 09:29:36 AM »

sinsi is right, and this is important to remember as it could have unexpected results for your program. I always rtlzeromemory my local buffers before using it, unless I Use GlobalAlloc or similar

Code:
myproc proc
local mybuf[1024]:BYTE
invoke RtlZeroMemory,addr mybuf,1024

;now save to use
ret
myproc endp

a global buffer will always be initalized to zero though e.g
mygbuf byte 1024 dup(?)

also when it comes to buffer sizes I usually try and stick with 1 evenly divisible by 4,since the 32bit processor reads everything in dwords, you could also use align 4, align 8 etc before it... to speed things up.

align 8
myebuf byte 16 dup(?)
Logged
NervGaz
Member
**
Posts: 25


Re: About LOCAL string
« Reply #4 on: September 16, 2009, 09:34:14 AM »

RtlZeroMemory should work fine... But IIRC it's a lot faster just using a "rep stosb/w/d" to do it...
mind you I haven't really been coding anything in asm for a good few years so I think
someone else might be better suited to give and example that'll work straight away...
I'll give it a shot tho...
Code:
xor eax,eax
lea edi,szDir
mov ecx,31 ;as it's a quarter of the buffers size
rep stosd

hopefully I got that right
Logged
ecube
Guest


Email
Re: About LOCAL string
« Reply #5 on: September 16, 2009, 09:38:29 AM »

RtlZeroMemory should work fine... But IIRC it's a lot faster just using a "rep stosb/w/d" to do it...
mind you I haven't really been coding anything in asm for a good few years so I think
someone else might be better suited to give and example that'll work straight away...
I'll give it a shot tho...
Code:
xor eax,eax
lea edi,szDir
mov ecx,31 ;as it's a quarter of the buffers size
rep stosd
hopefully I got that right



I disagree, back when I started the speed test thread on Zero memory functions http://www.masm32.com/board/index.php?topic=6576.0 , it was determined RtlZeroMemory was the fastest on buffers 1024 bit+ and masmlib memfill was faster on smaller buffers. I think RtlZeroMemory uses rep in its code anyway.
Logged
NervGaz
Member
**
Posts: 25


Re: About LOCAL string
« Reply #6 on: September 16, 2009, 09:43:42 AM »

Again it's been ages since I coded in asm, actually apart from a few filemaker scripts
(i know not even really coding) it's been ages since I coded anything... But yeah I
remember a similar conversation about 7 or 6 years ago on a forum... Only reason i
mentioned stosb/w/d was that the buffer in his example was 124 bytes long...
Logged
hutch--
Administrator
Member
*****
Posts: 12013


Mnemonic Driven API Grinder


Re: About LOCAL string
« Reply #7 on: September 16, 2009, 09:56:33 AM »

A couple of things, in most instances when you allocate a buffer on the stack for text, you only ever need to write ONE ZERO at the start, not zero fill the entire buffer. As long as you don't try and write past the end of the allocated space, normal zero terminated string procedures only need to know the start address of the buffer.

If you really must zero fill the buffer, DON'T use REP STOSD as its slow on the first 500 bytes or so, do it in the normal manner using a DWORD sized register with zero in it.
Logged

Regards,



Download site for MASM32
http://www.masm32.com
NervGaz
Member
**
Posts: 25


Re: About LOCAL string
« Reply #8 on: September 16, 2009, 10:06:15 AM »

Goes to show how much I remember...  heh...
Logged
Slugsnack
Member
*****
Posts: 463


Re: About LOCAL string
« Reply #9 on: September 16, 2009, 11:16:58 AM »

RtlZeroMemory should work fine... But IIRC it's a lot faster just using a "rep stosb/w/d" to do it...
mind you I haven't really been coding anything in asm for a good few years so I think
someone else might be better suited to give and example that'll work straight away...
I'll give it a shot tho...
Code:
xor eax,eax
lea edi,szDir
mov ecx,31 ;as it's a quarter of the buffers size
rep stosd
hopefully I got that right



I disagree, back when I started the speed test thread on Zero memory functions http://www.masm32.com/board/index.php?topic=6576.0 , it was determined RtlZeroMemory was the fastest on buffers 1024 bit+ and masmlib memfill was faster on smaller buffers. I think RtlZeroMemory uses rep in its code anyway.

Source for RtlZeroMemory, taken from debugging in VC++ ( nice comments Microsoft ! ) :

Code:
memset proc \
        dst:ptr byte, \
        value:byte, \
        count:dword

        OPTION PROLOGUE:NONE, EPILOGUE:NONE

        .FPO    ( 0, 3, 0, 0, 0, 0 )

        mov     edx,[esp + 0ch] ; edx = "count"
        mov     ecx,[esp + 4]   ; ecx points to "dst"

        test    edx,edx         ; 0?
        jz      short toend     ; if so, nothing to do

        xor     eax,eax
        mov     al,[esp + 8]    ; the byte "value" to be stored

; Special case large block zeroing using SSE2 support
    test    al,al ; memset using zero initializer?
    jne     dword_align
    cmp     edx,0100h ; block size exceeds size threshold?
    jb      dword_align
    cmp     DWORD PTR __sse2_available,0 ; SSE2 supported?
    je      dword_align

    jmp     _VEC_memzero ; use fast zero SSE2 implementation
    ; no return

; Align address on dword boundary
dword_align:

        push    edi             ; preserve edi
        mov     edi,ecx         ; edi = dest pointer

        cmp     edx,4           ; if it's less then 4 bytes
        jb      tail            ; tail needs edi and edx to be initialized

        neg     ecx
        and     ecx,3           ; ecx = # bytes before dword boundary
        jz      short dwords    ; jump if address already aligned

        sub     edx,ecx         ; edx = adjusted count (for later)
adjust_loop:
        mov     [edi],al
        add     edi,1
        sub     ecx,1
        jnz     adjust_loop

dwords:
; set all 4 bytes of eax to [value]
        mov     ecx,eax         ; ecx=0/0/0/value
        shl     eax,8           ; eax=0/0/value/0

        add     eax,ecx         ; eax=0/0val/val

        mov     ecx,eax         ; ecx=0/0/val/val

        shl     eax,10h         ; eax=val/val/0/0

        add     eax,ecx         ; eax = all 4 bytes = [value]

; Set dword-sized blocks
        mov     ecx,edx         ; move original count to ecx
        and     edx,3           ; prepare in edx byte count (for tail loop)
        shr     ecx,2           ; adjust ecx to be dword count
        jz      tail            ; jump if it was less then 4 bytes

        rep     stosd
main_loop_tail:
        test    edx,edx         ; if there is no tail bytes,
        jz      finish          ; we finish, and it's time to leave
; Set remaining bytes

tail:
        mov     [edi],al        ; set remaining bytes
        add     edi,1

        sub     edx,1           ; if there is some more bytes
        jnz     tail            ; continue to fill them

; Done
finish:
        mov     eax,[esp + 8]   ; return dest pointer
        pop     edi             ; restore edi

        ret

toend:
        mov     eax,[esp + 4]   ; return dest pointer

        ret

memset  endp

        end
Logged
ecube
Guest


Email
Re: About LOCAL string
« Reply #10 on: September 16, 2009, 11:23:11 AM »

Nice Slugsnack  BigGrin I wonder if lingo or the other speed guru's could speed that up. I'm suprised they used sse2, considering how a lot of other WinAPI are slow.
Logged
Slugsnack
Member
*****
Posts: 463


Re: About LOCAL string
« Reply #11 on: September 16, 2009, 11:51:44 AM »

Nice Slugsnack  BigGrin I wonder if lingo or the other speed guru's could speed that up. I'm suprised they used sse2, considering how a lot of other WinAPI are slow.
Huhhh I don't see any SSE2 instructions lol. Only regular x86 ones
Logged
sinsi
Member
*****
Gender: Male
Posts: 1758


RIP Bodie 1999-2011


Re: About LOCAL string
« Reply #12 on: September 16, 2009, 12:06:49 PM »

Well, you missed the interesting bit
Code:
    jmp     _VEC_memzero ; use fast zero SSE2 implementation

Logged

Light travels faster than sound, that's why some people seem bright until you hear them.
ecube
Guest


Email
Re: About LOCAL string
« Reply #13 on: September 16, 2009, 12:21:56 PM »

hehe woops  BigGrin
Logged
hutch--
Administrator
Member
*****
Posts: 12013


Mnemonic Driven API Grinder


Re: About LOCAL string
« Reply #14 on: September 16, 2009, 01:53:52 PM »

Something that needs to be kept in mind with memory copy algos is if both locations, (source and destination) are already in processor cache. If they are the DWORD sized copy is reasonably fast but if the target and source are not in cache, you get cache pollution problems. REP MOVSD and the SSE/MMX version if written correctly read through cache but write back directly to memory which is usually faster when source and destination are not both in cache.

You test this by allocating two memory blocks that are large enough not to fit into cache then copy data from one to the other.
Logged

Regards,



Download site for MASM32
http://www.masm32.com
Pages: [1] 2 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP The MASM Forum Archive 2004 to 2012 | Powered by SMF 1.0.12.
© 2001-2005, Lewis Media. All Rights Reserved.
Valid XHTML 1.0! Valid CSS!