Hi. I need a Seek Char function. This function Must be able to seek a char as fast as posible on MASM.

Here is Mine

SeekChar proc uses esi lptz:dword,k:byte

mov esi,lptz
xor ecx,ecx
inc ecx
;mov al,[esi]
;inc esi

.if al==k
xchg eax,ecx
.elseif al==13

.elseif al==0

jmp delopp

xor eax,eax
dec eax

SeekChar endp
Posted on 2003-10-03 07:29:05 by realvampire
More helpful higher-level description: return 1-based index of first occurrence of k in the string (terminated by \0 or \n), or -1 if not found.

I won't ask why this is a bottleneck, but for meaningful optimization, you'll need to specify target CPU, size of the string, its alignment and usage patterns (in cache?), expected position of the target character, and range of characters in the string.

In any case: lodsb is slow (better to use RISC-style instructions in an unrolled loop), and the constant branching due to the .if implementation will hurt.
Posted on 2003-10-03 12:12:56 by Jan Wassenberg
A small step forward:
SeekChar proc lptz:dword,k:byte

mov edx,lptz
xor ecx,ecx
mov al,[edx]
inc edx
inc ecx

cmp al, k
je __k
cmp al, 13
je __CR
cmp al, 0
jne delopp
xor eax,eax
dec eax
xchg eax,ecx
SeekChar endp
...little bigger step:
SeekChar proc lptz:dword,k:byte

mov eax,lptz
mov cl,[eax]
inc eax
cmp cl, k
je __k
cmp cl, 13
jnbe delopp ; mostly taken

je _x
cmp cl, 0
jne delopp
xor eax,eax
dec eax
sub eax,lptz

SeekChar endp
The above improvement isn't the 70% faster one might first think.

Personally, I perfer the use of flags on return from a call:

mov edi, [esi].destPathFile
xor eax, eax
add edi, eax
push "/"
push edi
call SeekChar
jnc NextSlashInPathFile
; EDI points to the file name...
Posted on 2003-10-03 20:12:50 by bitRAKE
I think LODSB can be used to save one more clock. :)
Posted on 2003-10-03 22:39:43 by optimus

I think LODSB can be used to save one more clock. :)
This is not true.
Posted on 2003-10-03 22:41:44 by bitRAKE
It seems so. LODSB takes more clock than MOV+INC
Posted on 2003-10-03 23:02:44 by optimus

LODSB takes more clock than MOV+INC
Yes, this is true.
Posted on 2003-10-03 23:09:58 by bitRAKE
Lodsb only save byte. inc clock are 1. So do mov mem,reg.
But what about .if on MASM?.
Posted on 2003-10-04 20:44:23 by realvampire
.if and .endif should be converted into native assembly code. what's the code then?
Posted on 2003-10-05 00:59:39 by optimus
Well, I would doubt the efficiency of using byte size chunks, it will result in alot of stalls and subsequently a slow algorithm. I haven't looked at this very closely but I would think that it would be much faster to process it as DWORDs. I haven't checked for the end of the string but that is just another check...
Searchforchar proc uses esi k:BYTE

mov al,k
mov ah,k
bswap eax
mov al,k
mov ah,k
mov edi,eax

mov esi,OFFSET String
mov eax,[esi]
xor eax,edi
add esi,4
; test for zero
lea ecx,[eax-01010101h]
not ecx
and ecx,eax
and ecx,80808080h
; no zero found


Searchforchar endp
Posted on 2003-10-05 05:08:57 by donkey
donkey, there is no need for stalls due to byte size accesses and the strings will need to be longer on average to make the DWORD/MMX/SSE2 test method faster. Also, the byte test will be needed on the four/eight/sixteen bytes for DWORD/MMX/SSE2 algorithms, due to the condition where the character is after the end of the string.
Posted on 2003-10-05 10:57:49 by bitRAKE
good thought!
Posted on 2003-10-05 11:03:15 by optimus
Is Donkey Code Fast? Who is the Fastest, BitRake or Donkey?:stupid:
BTW:Great Job all :alright:
Posted on 2003-10-08 08:40:30 by realvampire
"Who is the Fastest, BitRake or Donkey?"

Mine (see the attachment)
More details here:
Posted on 2003-10-08 17:13:53 by lingo12
Hey, I'm just a quick hack - lingo12's code is the real leader here. ;)
Posted on 2003-10-08 20:23:52 by bitRAKE
I believe you have a better code but you keep it for yourself only
Posted on 2003-10-08 21:16:56 by lingo12
Do you think mine is smaller than yours? :grin:
Posted on 2003-10-08 21:22:36 by bitRAKE
...My brain, it have a Limit, you know (or Remember). Can I Know how to use it? (Example, SearchChar lpAddr,theByte). Thank you.
Posted on 2003-10-09 10:56:47 by realvampire