ASM Community

This algo gets a file name from a full path by overwriting the buffer with the full path with just the file name.

; ?????????????????????????????????????????????????????????????????????????



;       Overwrites the full pathname of a file with its file name



; ?????????????????????????????????????????????????????????????????????????



FileFromPath proc lppath:DWORD



    mov ecx, lppath

    mov edx, lppath



  @@:

    mov al, [ecx]

    inc ecx

    mov [edx], al

    inc edx

    cmp al, 0           ; test for zero

    je @F               ; exit if zero

    cmp al, "\"         ; test for "\"

    jne @B              ; jump back if not

    mov edx, lppath     ; else reset edx with buffer address

    jmp @B              ; then jump back

  @@:



    ret



FileFromPath endp



; ?????????????????????????????????????????????????????????????????????????

Please feel free to make a faster version.

Regards,

hutch@movsd.com

Little mistake correction:

FileFromPath proc lppath:DWORD

    mov ecx, lppath

  _reset:

    [COLOR=red]mov edx, ecx[/COLOR]

  @@:

    mov al, [ecx]

    inc ecx

    cmp al, "\"         ; test for "\"

    je _reset           ; reset if so

    mov [edx], al

    inc edx

    cmp al, 0           ; test for zero

    jne @B              ; jump back if not

    ret

FileFromPath endp

Actually, your "correction" makes this function an implementation of delay() for a few msecs (depending on strlen(lppath)). :)


Duh... Why can't I type faster? :( While typing this post, hutch replied already.

Sorry. :stupid:

NaN,

An interesting idea, the original was to pass an address to the algo and use it as was after, I guess it depends on which is more convenient to you to use.

Regards,

hutch@movsd.com

What is aim speed or size?
Or maybe speed + size if size optimization doesn't harm speed?

Thinking about the Suggestion by NaN and Maverick, here is the next version, a non destructive algo that returns the address of the beginning of the file name after the last "\".

; ?????????????????????????????????????????????????????????????????????????



FileFromPath2 proc lppath:DWORD



    mov ecx, lppath

  strt:

    mov eax, ecx

  @@:

    inc ecx

    cmp BYTE PTR [ecx], "\"

    je strt

    cmp BYTE PTR [ecx], 0

    jne @B



    inc eax



    ret



FileFromPath2 endp



; ?????????????????????????????????????????????????????????????????????????

If doe one MOV that is unneeded as its faster than using a jmp over the MOV and it starts 1 byte up from the start which does not matter in a path.

Regards,

hutch@movsd.com

John,

You are right of course but the proc was designed for stripping file names from full paths so it requires a full path.

I take your point that an algo that handles both would need to be different.

Regards,

hutch@movsd.com

:grin: <lol> :grin:

Do you really need to super optomize a simple routine? Im mean, when are you ever going to get a file path long enough to see the results anyways??

However, for those who like to refine their skills, i can fully understand this. But IMHO, my origion post or hutches latter version will get the job done fine. However Hutch's version will fail if someone uses this improbable string "\filename.exe",0.

One more thing, im not an optomizing person, so i dont know 100%, but it seems to me 32bit comparisons in flat32 mode is better than 8 bit comparisons, due to pipeline issues. This is why i always load the 8 bits into a formated eax register and keep all other code applicable to 32bit registers....


:grin: :grin:
:NaN:

IMHO, it may be worth optimizing for speed.
In essense, the function can be written in C as:

char *

FileFromPath(char *lppath)

{

    char * cp;

    cp = strrchr(lppath,'\\\');

    if (cp)

    	cp++;

    else

    	cp = lppath;

    return cp;

}

So, the libc strrchr part may be worth optimizing because it can be used as a general purpose function. In fact, if you target for 686 or later, you can make it faster by using CMOVcc, and scan lppath at most once.

; need .686 somewhere.

FileFromPath:

    mov   edx,[esp+4]

    ; strrchr part

    xor   ecx,ecx

    ; one may wish to put

    ; align 16 here for speed.

@@: mov   al,[edx]

    cmp   al,'\\'

    cmove ecx,edx

    inc   edx

    test  al,al

    jne   @B



    lea   eax,[ecx+1]

    test  ecx,ecx

    cmove eax,[esp+4]

    ret

29 bytes for C calling convention, 31 bytes for STDCALL.