×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

follow up...

follow up...

follow up...

(OP)
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:

CODE

    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.

RE: follow up...

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.

RE: follow up...

(OP)
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?

RE: follow up...

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.

RE: follow up...

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.

RE: follow up...

(OP)
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 ;)

RE: follow up...

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

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close