🚀 go-pugleaf

    Date: 10 May 89 11:55:56 GMT
    From: mcvax!cernvax!ethz!forty2!poole@uunet.uu.net  (Simon Poole)

    If 99% of the people that use dhrystone don't even know what it mesures,
    how are they to know if it's valid or invalid???? 

In my experience, that sort of question rarely comes up when
benchmarkers are talking about their results.

[...]
		    To show why dhrystone results shouldn't be overrated,
[...]
    As you can see a good 30% of the time is spent in the libary routines strcpy
    and strcmp 
[...]

Thanks, Simon, for injecting a note of sanity into a topic that usually
degenerates into religious feuding.

One of the things that wins about GCC is that you've got a lot of
flexibility about how to do things.  In the case of the offending
library functions that are taking 30% of the time, at least one fix is
trivial:  Just declare the things inlinable, and let the compiler do its
thing.  As near as I can tell, that's as good as what you'd get if you
taught the compiler about them as internal functions.  I tried declaring
the simpleminded strcpy implementation inline, and got a couple
instructions of setup, and a 3-instruction loop embedded in the code.  

If that's not good enough, you can probably save one instruction by
hand-coding it, and again, GCC allows you to define hairy assembler
constructs, which can get access to C values.  The double-float code
does this extensively.  Jwahar Bammi has an OSBIND.H that uses this
feature, too.

The point of all this is that you can easily tune the code GCC produces
to look like just about anything.  If what you do with your ST is run
benchmarks all day, then you can make it produce good benchmarks.  If
you do something else, you can tune it for that.  All the sources are
available (several times over), so you can make it do whatever you like.

Finally, for those of you who don't like those solutions, there's an
even easier one:  Don't use it!