From: zfysz@nospicedham.fysnet.net
"wolfgang kern" wrote in message
news:oit3g8$6b0$1@gioia.aioe.org...
Hi guys,
Thanks for your comments. I will try to answer everyones questions
within this post.
First, to clarify, the strings will only contain alpha and numeric
characters, including a single '.' char. (for now).
> If your strings contain also numbers then a OR 0x20 would work while AND
> 0xDF wont.
Why not? If guarenteed to only have alpha and numeric chars, an
AND will work also. Numeric chars have bit 6 cleared, while alpha
chars have bit 6 set.
Rod said:
> If you say what these strings are for, there might be some
> simplification for your usage.
And Robert said:
> Are the strings limited to *only* letters? Otherwise you'll end up
> comparing '[' and '{' as equal (for example).
I am using it when comparing filenames when searching for the
loader file within the specified file system. This routine needs
to be called (unchanged) no matter the file system being used.
For now, string0 is a fixed value of:
'loader.sys',0
string1 can be any string (alpha, numeric, or '.') from the specified
file system being searched.
Rod also said:
> If this is for assembly, I'm wondering why you're using -1, 0, 1
> returns. These are good for C, but for assembly, you'd be better off
> with setting processor flags for Jcc branch instruction. Is this for
> C code for Smaller C? ... Yes, they're ASCIIZ, so very likely C code.
It is all assembly. However, here is the reason why I am trying to
stick with some sort of standard. I have (currently) seven file systems
and/or MBR's that may call this routine. If I make is specific to
one source file, it may throw a bug in another without notice.
I don't want to rely on something in one file and assume it in another.
However, since I won't be using C (or calling it from C), I can
change it to use something else, though I need to maintain the
less-than, equal, or greater-than return values for future use.
Zero flag, of course, for equal, and sign (or carry) flag for
less-than and greater than could be an option.
zero = clear = not equal
zero = set = strings are equal
carry = set = string0 < string1
carry = clear = string0 > string1
This all can be created with a single 'sub' instruction.
wolfgang said:
> But if your strings are allowed to contain anything else than A..Z, a..z,
> 0..9 then both (AND and OR) will fail without proper filters.
Yes they would. This is a thought for future code. For example,
currently I only allow
'loader.sys',0
to be searched for. However, what if I decide to use "long file names"
such as what Ext2/3/4, LeanFS, etc allow.
'loader version 1.2.3.4[rev0]',0
Now we have a problem.
> you already mentioned it: replace the calls with OR 0x20,
> and I wouldn't use HLL-styled return values.
I currently use an AND 0xDF which will set the zero flag accordingly.
However, if you will explain why an AND 0xDF won't work (using alpha
and numeric chars only), I can modify my code accordingly.
Again, I have numerous first stage boot/loader files, one for each
file system I support, along with other sources, and only want
to maintain one source file for stricmp (along with numerous other
library calls). I then want to be able to, for future filesystems
and first stage code files, to rely upon this library call without
having to rely on any quirks or assumptions. A guarantee that it
will return -1, 0, or +1 is a common return for such a function call.
All of the file systems I currently support, have enough room within
the first stage code to allow a proper stricmp for any ascii char
zero to 255, except for my ext2 code. Unfortunately, ext2 only allows
512 bytes for the first stage boot code. I either have to load
any additional sectors or use only the first 512 bytes. The problem
with ext2/3/4, loading additional first stage boot code is not as
easy as it may seem.
Anyway, I am mostly just posting/commenting for the company of others,
just to hear your thoughts.
Thank you,
Ben
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
