Re: asm grep

Frank Kotler <fbkotler@xxxxxxxxxxx> wrote in part:
In a thread that had drifted a long way from PSHUFW and the Nasm manual,
I was complaining about the asmutils grep...

Ummm... did I mention that the asmutils grep ended in a segfault on my
(38M) testfile? Yeah. I haven't looked at why, yet. That one can use
some attention. Glad you brought it up, Santosh!

Well... true to its name "gets" doesn't check for buffer overrun! :(

Only a highly unusual file will trigger it - requires a "run" of over
16k without a linefeed (0x0a). My "testfile" happened to do it (thought
that was pretty much "text"...). Arguably not worth fixin'.

I also mentioned "lint", and that I thought "call strlen" could be
improved... Well, I de-linted it, and "improved" strlen...

A while back, someone was asking about the advantages, or not, of using
macros to replace calls to subroutines. Mostly, it "saves the call and

Did anyone mention using the Boyer-Moore skip search algorithm
(wiki & elsewhere)? If speed is important, first get the best
algorithm! If size is important, then it's hard to beat the slow,
un-hardware-optimized REP / CMPSB .

For simple reads I doubt the MMX tricks or cache blocking used in
bcopy() help much. But you can always try blocking REP/CMPSB into
MMU burstsize chunks and headed by multistride PREFETCH or dummy loads.

I also complained that the speed was horrible. The issue is *exactly*
the example Robert cited - "sys_read ebp, tmp, 1" - we're calling the OS
for every byte. If the "C newbie" did the same, he'd be slow too, but he
probably knows fread() and/or fgetc()... may not know that read()
exists. These do the buffering for him, so he's probably gonna kick our ass!

Exactly. Getting to the unbuffered versions in C is not a newbie skill.

-- Robert

.