JC>On (03 May 97) Herman Schonfeld wrote to Carey Bloodworth...
 CB>Unrolling can help.  Pointers slow it down.  I've timed it.
 CB>Contrary to popular convention, pointers are _not_ automatically
 CB>faster than indexing.
 HS> Use an average consumer machine to test out your programs then come
 HS> back with results.
JC>This generally has to do with the compiler, not the machine you run the
JC>code on.  Nearly any decent compiler is written with the knowledge that
JC>`A[b]' is exactly equivalent to `*(A+b)'.  It's easily shown that many
JC>produce identical code regardless of the notation you happen to use in
JC>the source code.  Some produce better code when you use array notation
JC>than when you use pointer notation.  A few do the reverse.  However,
JC>this is strictly a compiler question, not a hardware question.
 HS> With optimizations turned on, my compiler removes unused variables
 HS> from registers which can be used for something else.
JC>If you feel it's good to screw up your programs to compensate for a
JC>deficient compiler, great.  However, attacking the rest of the world
JC>because they use working compilers so they can write readable code is
JC>nonsensical.
JC>    Later,
JC>    Jerry.
Jerry, I'm afraid that your missing the point here.
What I previously claimed was that 'Optimizers don't always produce the 
fastest code'. I hardly see where a[b] or *(a+b) have anything to do with 
hand-optmizations. Sure, some compilers write fast code, but in general the 
fastest code is not generated. ie, I just tested out a scaling program. 
(scales a bitmap to larger/small dimensions)
These are the results
test machine = 486 dx2 66, tseng 4000
version             Blits per Second
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
floating point         31
fixed point            369.5  (nb, optimizers do not implement fixed point)
fixed point + asm      348.9  (watcom writes better asm than me)
fixed point + cp asm   612.3  (using code patching)
Now, if I were to write the code normally without many optimizations I would 
get a rather slow 31 fps. If I used fixed point math (please name a compiler 
which does this for you, I'd really be interested in it) I would get a 
whoppingly fast 370 fps. You might consider this fast enough and just leave 
it and do something else, right? Well, by spending a few minutes by adding 
code patching you could double the fps. Now, that's 20 times faster than the 
original version. I don't think it hurts to hand-optmize code, do you?
... Coming Soon: Mouse Support for Edlin!
--- Ezycom V1.48g0 01fd016b
---------------