cool !

Because I had needed such a function to write a file direct from a string.
Such a pretty algorithm isn usefull at this prob.
But there cant be a nother solution for that, or?
Posted on 2003-05-31 10:24:46 by Forginforcer
lol must have been one of my first posts:confused:
Posted on 2003-05-31 17:55:11 by Qages
I usually do not try to contribute to any thread in which others are optimizing
as my skills in this area are quite lacking...

However I did have a couple of related questions and observations.

After a closer look at the underlying algorithm and a revisit to my trusty
ASCII table :grin:, it was quickly apparent that under normal circumstances
testing bit 80h should be enough to find the null character. Therefore it
would be my assumption that the tighter the main loop the better and if
you like you can test for special cases after.

Jenns code (which makes my head spin frankly) seems to try and
weed out the special cases inside the loop - I admit I have not done the
math all the way though on this for understanding so I may be mistaken.

buliaNazas code seems more along the lines in which I would personally
code it, but I am curious as to a couple of things...

1> Would this code not be prefered in terms of speed? (buliaNaza's)

mov edx, esi
lea eax, [edx-01010101h]
add edx, 4
and eax, 80808080h
jz loop

...test special cases here if you like...

This code snip brings me to my second question ;)
If I understand some of optimizing at all, lea eax, should be
U pipe and add edx, 4 should be V pipe no? Even if this is not true, for the
question please assume it is. would the next line of and eax, 80808080h cause
a stall for accessing eax in the next pair?

Sorry for the load of questions =) I find this thread very interesting...

Hmm, actually I might have answered my first question on my own as I cant recall
if lea eax, is using edx as an address or if it is reading the contents
at that address...
Posted on 2003-06-10 21:40:11 by Graebel
Posted on 2003-06-11 05:49:26 by lingo12