ASM Community

It's quite simple: bring them to the same case and then compare them. It can be done dinamically in one loop or divided in two parts to convert first and then compare. Using appropriate way is havilly dependable on your conditions Do you care of both or one of values, how long the strings suppous to be ect. ect. I'm pro asm+database programmer and in my job there a lot of formation and copmaring tasks, after having been looking quite a while for proc major strategy I began developing teq. using tables and copmlex index addressing - for my job in lots of cases it became the way to get shortest and fastest result. If you use big table just for one proc it might seem quit memory consuming, but when you write a set of procs, and almost all of them you use in fairly big project then size of tables is almost nothing, you just put them in global section making them available for any proc, and writing procs passing them as parameter address of table. For example you can use the same table for UCASE conversions caseunsencetive search and comparing ect(upto 100 procs!). Create table of uninterraptive array and replace value of members UCASE with lowcase or in opposit. Then you don't need to check each time if it casesomething. Most universal whay with this will something like. edi pointer of one string esi pointer to another some where before the loop xor eax,eax xor edx,edx @@: in loop mov al, mov dl, mov al,tbl mov dl,tbl inc edi cmp al,dl jne notequ inc esi dec ecx jne @B Please note: it takes ~ 5-7 clocks for byte (iteration) and rep scasb 12once and + 4 byte for each byte comparasion So it will be fastest whay you never get using any other teq without table. In addition a lot of M32LIB procs useless in other not English speaking countries just for it use ULCASE proc with just first halve of ASCII table and other halve is national relative, but if you replace those procs with ones using tables they can be used there programmers needs just make their country seciffic table and pass pointer of them to the procs. The Svin.

invoke strcmpi,addr string1,addr string2

why reinvent the wheel? umbongo

please be careful with manipulating single byte strings, and think to the german or arabic people, which will get problems with there special characters. Windows function work (mostly :)) proper.

You want my system at work, they have a policy of running anti-virus software on every single file. I mean everything, .hlp .html .tmp - the lot, it takes 2 minutes to open the VC++ help file!!!!!! If you want to optimise anything call norton and work for them...... Umbongo This message was edited by umbongo, on 3/23/2001 1:05:00 PM

Ernie, This library module is more or less hot off the press but it is testing up OK so far and you will find it will rip the titz of API calls. Now the down side is that its case sensitive search and it has no error checking built into it so if you pass an incorrect parameter, it will crash. In particular, specifying the starting position to search from at a position past the source length minus the search string length will cause a page fault. In the last service pack, the 2 case conversion modules were made a lot faster so converting a buffer to uppercase then searching it would probably be very fast as the case conversion would get it into cache. Regards, hutch@pbq.com.au

; #########################################################################

    .386
    .model flat, stdcall
    option casemap :none   ; case sensitive

    .code

; #########################################################################

bSearch proc StartPos:DWORD,lpString:DWORD,lnStrng:DWORD,
                            lpSubStr:DWORD,lnSubSt:DWORD

    push ebx
    push esi
    push edi

    mov esi, lpSubStr
    mov ah,          ; 1st byte in AH

    mov esi, lpString     ; source in ESI
    add esi, StartPos
    mov edx, lnStrng      ; len in EDX
    lea edx,   ; add esi to edx + 1
    sub edx, lnSubSt      ; subtract substr len from source len

; ---------------------- Main Loop --------------------------
  bsSt:
    mov al, 
    inc esi
    cmp al, ah            ; cmp byte to start character
    je sbLoop             ; jump to subloop if equal
    cmp esi, edx          ; test exit condition
    jne bsSt              ; jump back if not equal

    mov eax, -1           ; -1 = no match
    jmp bsOut
; -----------------------------------------------------------
  sbLoop:
    push esi              ; source offset is in ESI
    dec esi               ; start comparison from correct position
    mov edi, lpSubStr     ; substring offset in EDI
    mov ecx, lnSubSt      ; substr len in ECX
; ---------------------- Sub Loop ---------------------------
  cmSt:
    mov al,          ; read source byte
    mov bl,          ; read search byte
    inc esi
    inc edi
    cmp al, bl            ; test byte
    jne cmOut             ; exit subloop if not matching
    dec ecx               ; decrement counter
    jnz cmSt              ; return to compare next byte if ECX not zero
; -----------------------------------------------------------
;   if ECX = 0 fall through to following instruction
; ---------------------- If Match ---------------------------
    pop esi               ; restore esi
    dec esi               ; correct to get true position
    sub esi, lpString     ; sub start address from esi
    mov eax, esi          ; copy to eax as return value
    jmp bsOut
; ------------------------ Else -----------------------------
  cmOut:
    pop esi               ; restore ESI
    jmp bsSt              ; return to start

  bsOut:

    pop edi
    pop esi
    pop ebx

    ret

bSearch endp

; #########################################################################

    end

This message was edited by hutch--, on 3/23/2001 5:44:32 PM

Alex, I have just learnt something useful when using tables although in a slightly different context, it is very important to have the table aligned even when you are making BYTE reads from it. I worked on an algorithm with a friend of mine that uses XLATB and got a wide range of speeds depending on the alignment of the 256 byte table, even though XLATB reads in BYTE size. Regards, hutch@pbq.com.au

That point about tables needing to be aligned - it is quite true. The only reason I can think is, even though the values themselves are read as bytes - the hardware doesn't! For each memory access, a value is read using the full bus width (ie a DWORD), regardless of whether this is to used as a byte, word, or dword once the dword is read - then it is masked and shifted accordingly if needed to fit the instruction So, the first byte read, in an aligned table will still need to be masked and shifted, but once this is done - the next byte to be read is already in the pipeline and has already been read so this is quick (and so for the next two bytes after that) But if the table is misaligned then this 'cached-bytes' effect is partly lost, since the loss on the first byte isn't made up by the next three Although, I'm not sure how much impact this will cause for byte tables, since only the first (hardware)dword is misaligned. But for word and dword tables it can be very bad, since usually two dword fetches will be required just to fetch a single (soft)dword (...which would be like getting a chache-miss on every second read - ouch!)

The Intel cache is pretty strange to me. Instead of a single cache, it's actually a bunch of little caches, each four levels deep (has this changed in the latest chips?) So it's extremely sensitive to access patterns. In the 486, the bad number was 2048. If you accessed data that was a multiple of 2K apart, you quickly flushed out the mini-cache. The 486 was worse than the Pentium because code and data bytes were mixed together in the L1 mini-caches. A loop with two levels of subroutine calls spaced 2K apart (three code sections), add in a couple of data accesses 2K apart from each other and the code -- and you get a lot of cache misses. Even worse is the 4K page size used for VM (virtual memory). If you have lots of RAM, this won't be a problem. But if you don't, you can have a similar scenario (with the bad number 4096) and get thrashing. With the L1 cache, each cache line in the 486 is 16 bytes (it's 32 in the Pentiums), so the 2K figure is pretty close to reality. With the VM pages, it's better to state reality -- it's how many 4K pages you need (vs. how many you can hold in RAM) that determines whether you thrash or not. Another thing to keep in mind about byte writes -- if the hardware does not support byte selection during writes, at least one whole dword will need to be read in before writing. If that dword is cached, a whole 32-byte cache line in a Pentium must be filled (meaning eight dwords must be read!) I'm not really sure of the exact Pentium behavior.