Re: asm grep

Rod Pemberton wrote:
"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in message
news:Xpwdj.3630$tK5.681@xxxxxxxxxxx

The problem arises in that, in order to minimize checking "obvious
non-matches", I scasb for the first character of "needle", completely
ignoring "lines" (find the beginning/end of the line in which the match
was found only after finding a match). Seems to me this isn't going to
work if we want to print non-matching lines...


If you support LF, CRLF, but not CR, then scasb backwards for LF, i.e., 3
times for -B 2...

Okay, okay, I'll read the friendly man page... (Holy Crap!) Yes, well... no "context" is supported in the asmutils version... Seems like it might be a useful thing. Yeah, we can find a match first, and get "context" in either direction. That's not a problem. I guess if we're in inverse-matching mode, we can find a match first, and then print from "[last_printed]" to the match... and update "[last_printed]"... may not be the roadblock I first thought...

*or* report line-number
where a match is found, instead of "offset" (which seems useful to me).

Same might work here... without losing too much speed when we *don't* need to print/count non-matching lines... Have to think about this...

It's probably easier to implement with a small loop now that you want to
track more than one item, especially since tracking multiple character
values doesn't fit well with single x86 instructions... I.e., you have a
trade-off between functionality vs. speed vs. size.

Definitely! Without functionality, we can make it *real* small and *real* fast! :) We need it to work a *little* like "real grep", at least. Question is, how cheap can we get it...

What's the point? (a non-rhetorical question) If this is to be the "contest" between C and asm to prove "Asm Rulz", we need *all* the functionality of "real grep" - or more - *and* to beat it for speed (size probably won't be a problem). I really didn't intend to enter that contest, I just noticed a little "lint" in the asmutils grep... Then I happened to notice that it was dog-slow... I've convinced myself that I can "improve" the asmutils grep - much faster and, with the *same* functionality, little if any bigger. If I'm *gonna* try to improve the asmutils grep, by how much and in what way? I have no idea.

Best,
Frank
.