follow up...

[denc4]

This is a follow up to a previous post I made on comparing
two memory buffers. I wanted to write a utility which could
search for a pattern in a file from beginning to end, and
from end to beginning, as desired.

After abandoning the project for some weeks I finally picked
it up again, and decided to do it differently. Instead of
just trying to implement all functionality in one procedure
I now wrote a library with a few routines that are dedicated
to the task of reading a file forward or backward, and
managing the buffer it writes to.

Here's a slightly simplified version of the calling code,
it searches the file from tail to head:

    call BUFFER_READFIRST_BACK
    jcxz end

    lea si,searchpattern+sizeof searchpattern-1
    std
    lodsb

  lp:
    repnz scasb
    jnz nomatch
    cmp cx,sizeof searchpattern-1
    jb nomatch

    push si
    push di
    push cx
    mov cx,sizeof searchpattern-1
    repz cmpsb
    pop cx
    pop di
    pop si
    jnz lp

; match found!

    inc cx
    call BUFFER_GETFILEOFFSET_BACK
    jmp end

  nomatch:
    call BUFFER_READNEXT_BACK
    test cx,cx
    jnz lp

  end:
; no match found.

It's no Boyer-Moore string searching... but it works for me.
If anybody would like the library source, just ask.

 

[TheGreyBeast]

Good code. You could try to optimize it a little more. First thing where to look are jumps and calls, and most of all, inner loops. I bet you can optimize them if you take a look at some optimization articles, such as Agner Fog's Pentium Optimisation manuals.

You'll find them very useful.

There is something in each of us we don't know. Something with great power.

 

[denc4]

You think it's good code?
I've only read the art of assembly so far.. I'm still a novice
from my perspective..

Thanks for the tip though, at least the parts I've read so
far look promising. It seems to cover a lot of C++ also, I
don't know C, so that might be a problem. I'll try to read
it when I can find the time, I still have a lot of other
stuff to read.

I use a 486 and an AMD for my daily work, would it be wise to
learn Pentium optimization techniques in that case?

 

[lionelhill]

No, it wouldn't, and I think there's a danger of missing the point of optimisation. If you don't need an optimal algorithm, by all means don't use one. That's good sense; you shouldn't waste your time making something better than it needs to be. But if you do decide to optimise, first do the things that will make your code orders of magnitude faster (picking a better algorithm). THEN, and only then, mess around reordering op codes so that instructions are paired optimally, and all the other things that go with pentium optimisation. If nothing else, once you've put the bytes in their best order, then any other change whatsoever puts you back at square one. Your code is frozen at that stage, and cannot easily be changed again...

The only bit of low-level optimisation I ever use routinely is making sure data is word-aligned (it makes a vast difference on all processors from 16-bit upwards). And this is only necessary in assembler since any reasonable compiler will do it for you.

 

[TheGreyBeast]

When I said it was good code, I realised you were a novice. I just tried to encourage you, because I saw how other novices make and they build pretty awful code.. I hope you haven't take it as an offense.

 

[denc4]

That "frozen code" seems like a significant drawback. I very
often change my code, so optimization of that level would be
, at least for me, too much.

I have known about aligning code on some boundary. The
"even" directive can be used very easily, the only drawback
is that it makes code less readable, especially when you use
it a lot.

That's the main reason I have never used it. But speed
is also important. I think it would be best to add these
directives when there's nothing left to debug.

GreyBeast:
i was surprised you found it good code, that's all.
thanks for the complement

 

[TheGreyBeast]

Here's another interesting book you should read to write great code: Write Great Code