Re: asm grep


Frank Kotler wrote:

[about Global_Regular_Expression_Print...] aka: INSTR

... I get the feeling Frank is attempting to recruit others, yes?
Not really, although if anyone thinks it's a worthwhile "project", it
can be one...

Yes indeed, but if limited to certain features/file types for speed
reasons then it would need several variants of it.
I'd say a full featured ASM-version can contain several methods
but share the common stuff.

There are a lot of variable configuration bits and mask opportunities,
you'd call them cmd-line switches ;)

for the hay:
*skip header needs to recognise or know the file type
*total size (bytes) known from file anyway
*search range limit: from..until

for the needle:
*size (bytes)
*wildcards ignore characters by byte mask, so search can
include all chars ie: "?" "*" " " "."
the DOS-ANY-size wildcard:"*" wont make much sense.
options:
* case insensitive (shall affect ASCII only)
* search after delimiters only (def list of " ",",",0a,0d,0a0d,b7,...)
* find numbers only
* ignore/skip numbers ;even both wont do very well :)
* list all found
or
* stop on 1st found, can be used together with the search range
for multiple calls (find next after any job done with previous)
* stop on Nth found

I'm not exactly collecting a list, but I'm enjoying hearing what people
think are "useful" or "crucial". (when it comes to "find", I think the
best thing would be to make it more like "grep"... not too interested in
that direction).

I do hate search engines, so a good fast "find" routine may be required.
Best is of course to have all data stored in a way you don't need it :)
All I've done so far is a find-file by name in FAT-directories which
works with discrete dword compares and skips unwanted attribute entries.

....
I painted myself into a corner with the cmpsb/scasb version.
....
CMPSb/SCASb can be faster than loops on larger data (>16 byte),
the trick with 32-bit read at once may save on memory accesses,
but then the comparision will be delayed by shifts (slow on Intels).

...
Hmm, most interesting thing in this thread so far...
Can an assembly grep be small, fast, full featured, and compilable
for both DOS and Linux?

I don't know if Linux got something like 'partread',
I've seen a DOS-extender for it similar to my systems disk RD-function
which allow reads with OFFSET,SIZE from any (even fragmented FAT) file.

Someone would probably have to do an in depth comparison of DOS api and
Linux int 0x80 syscalls... (I've been meaning too, haven't done so...)

What's the dos interrupt for "mmap"?

What's "mmap" ?

I may have painted myself into a corner with that one, too. Is that
gonna work with stdin? Haven't tried that... That's a "must have", I
think, so it may be back to reading a buffer at a time. Bummer.
Nice not having to worry about "breaks"...

I'd had just a 1024 byte circular buffer and search within 512 byte
while the other 512 bytes are read in from disk in the background.
Perhaps not the fastest solution, but somehow memory friendly and as
my HD got a huge read ahead cache it wont lose much time, but
fragmentation will slow down the fastest method anyway.

In DOS:
OPEN file
|read part |
|read next part |while wait for this: search in previous read |
loop above line (until done)
CLOSE
:)
__
wolfgang



.