GetFilePath

[Vortex]

Here is my GetFilePath function to extract path from filenames. The subroutine appends a slash symbol to the end
of the buffer receiving the path followed by a zero.

Code Select Expand


.386
.model flat,stdcall
option casemap:none

.code

GetFilePath PROC uses esi source:DWORD,dest:DWORD

mov esi,source
mov edx,dest
dec esi
dec edx
mov ecx,edx
@@:
add esi,1
add edx,1
mov al,BYTE PTR [esi]
mov BYTE PTR [edx],al
test al,al
jz @f
cmp al,'\'
jne @b
mov ecx,edx
jmp @b
@@:
mov BYTE PTR [ecx+1],0
ret

GetFilePath ENDP
END
[attachment deleted by admin]

[PBrennick]

Vortex,
This will be a nice addition to the library.  :U

Paul

[TNick]

Hi Vortex! You have a point there, I will use it. Thanks!
Just two questions:
- isn't INC faster than ADD?
- isn't Or faster than TEST?
Or difrent manufacters provide diffrent speeds for this four instructions?

[EDIT]
A last one :)
- cmp  al, '\'
jne  @B

sub al, '\'
jnz  @B
[/EDIT]

Regards,
Nick

[Vortex]

Hi Paul,

Thanks for your kind words.

Hi Nick,

Thanks for your support.

add is faster than inc on P4 processors. test is also a fast instruction. I don't know about the situation of sub vs cmp here.

[TNick]

Hi again. Thanks for claring that up.
I really should search for that updated Agner manual ... :)

Nick

[Vortex]

Nick,

Here are Agner Fog's optimization manuals :

http://www.agner.org/optimize/#manuals

[PBrennick]

Nick,
cmp is a nondistructive test, sub is destructive so care is needed. Sometimes it is okay to use, other times, no.

Paul

[TNick]

Thanks for that link, Vortex.
Hi, Paul! Yep, but in this particular case (cmp al,'\') is working. But I'm not shure about the speed.

Regards,
Nick

[Vortex]

Hi Nick,

My routine is aimed for general purpose usage so small timing effects should not affect the functionnality of the algo.

[Grincheux]

In the same way, the "mov al,Byte Ptr [esi]" could be move before "add esi,1".

   mov      al,BYTE PTR [esi]
   add      esi,1
   mov      BYTE PTR [edx],al
   add      edx,1

   test      al,al
   jz      @f

But I don't understand why you are writing all of these functions which are already existing in the standard API. I am sure that programmers would need others functions.

Thanks, for all. I like this forum, there always is something interesting for evryone.

[TNick]

Hello, Grincheux!

Even if "reinventing the wheel" is considered by most people a waste of time, I (and, probably, Vortex, too) think that great things can came out of this. Think about speed, think about the size, about putting your brain to find a new solution to a problem already solved (wich may be harder than finding a solution without a previous existing answer), about the fact that reading source code for such a function may help others to find solutions to similar problems, ..., ..., ...

And think about the fact that anyone is free to do anything he/she likes with his/her time. :)

Regards,
Nick

[Grincheux]

You are right, I make the same thing too. In French, "Grincheux" means the man who is never pleased...

What I wanted to do is to get more functions about subjects like these : Images, internet, security, GUI...
For such functions where all are "reinventing the wheel". We are not all lucky, because of our own capabilities and knowledge.

You are right too, because I don't like to use code written by another than I. Except for subjects I don't know or don't understand.
I think that functions about databases (by example) would be more useful than Path and files functions that already are in the standard API.

Thanks

[Vortex]

Here is an improved version :

Code Select Expand

.386
.model flat,stdcall
option casemap:none

.code

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

GetFilePath PROC source:DWORD,dest:DWORD

push esi
push edi
mov esi,DWORD PTR [esp+12] ; source
mov edi,DWORD PTR [esp+16] ; dest
xor edx,edx
xor ecx,ecx
@@:
mov al,BYTE PTR [esi+edx]
mov BYTE PTR [edi+edx],al
add edx,1
test al,al
jz @f
cmp al,'\'
jne @b
mov ecx,edx
jmp @b
@@:
mov BYTE PTR [edi+ecx],0
pop edi
pop esi
ret 8

GetFilePath ENDP

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef

END
[attachment deleted by admin]

[Grincheux]

I think that something better can be made by removing PROLOGUE and EPILOGUE. Because we don't need locals variables EBP register can then be used like this we can remove one PUSH ESI/POP ESI. That could be

GetFilePath  :

PUSH EDI
   mov      EBP,DWORD PTR [esp+12]   ; source
               XOR                           EDX,EDX
   mov      edi,DWORD PTR [esp+16]   ; dest
               MOV                           ECX,EDX
MOV AH,'\'
.
.
.
CMP AL,AH
.
.
.
POP EDI
RET 8

;===================A Suggestion :

Replacing

mov      BYTE PTR [edi+edx],al

By

mov      WORD PTR [edi+edx],ax ; In that case CMP AL,AH must be replaced by the original CMP AL,'\'

If so we can remove later

mov      BYTE PTR [edi+ecx],0


That's all. In the same spirit why nt rewrite PathMakePretty...?

[Vortex]

Because we don't need locals variables EBP register can then be used like this we can remove one PUSH ESI/POP ESI.

Grincheux, I am sorry but your method would not work because you need to preserve the original value of EBP if you modify it. Iczelion's tutorial #1:

When you program under Win32, you must know some important rules. One such rule is that, Windows uses esi, edi, ebp and ebx internally and it doesn't expect the values in those registers to change. So remember this rule first: if you use any of those four registers in your callback function, don't ever forget to restore them before returning control to Windows.