> <<
> Another is the use of 'absolute'.
> Using absolute as a sort of permanent typecast often forces register
> variables onto the stack. In this case, the data is already memory
> based so it works out.
> >>
>
> From way back, I see absolute as the normal complement for untyped params.
> Can't say your pointer and assignment look like a convincing improvement.
Absolute implies memory address. However, many params don't have any
memory associated with them as they are values. By using the 'absolute'
approach to typecasting them you force them on to the stack and out of a
register, making them slower in the process. Upon reflection though,
'var' params are always associated with memory so using absolute on them
generalizes well. I'll have to make a note of that as I like the look
of 'absolute' over typecasts.
> <<
> BTW: I really wish they would 'fix' the for loop because I rather
> dislike using while to do a for loops job.
> >>
>
> Could you go into detail?
The compiling and optimization of 'for' loops is probably the most
complex operation the compiler does. (case statements would run a close
second, IMO) The basic approach is to convert the loop variable (i) into
a counter that typically heads towards zero, and to convert any arrays
to typed pointer variables that are incremented along their respective
arrays. This avoids the need to multiply, which pre-Pentium II was
quite an expensive operation. However, it overlooks the fact the arrays
with element sizes of 1, 2, 4 and 8 are special cases that are directly
supported by x86 CPU's. Consequently, it is not the best generalized
approach to these types of loops. Now since classes are actually
pointers it is easy to see that the preponderance of arrays fall into
this catagory, and so I believe that the compiler should handle them
differently. This was my "wish".
So much for the generalities. As I said the for loop optimization is
complex. In some cases it does a pretty good job in spite of itself on
these types of arrays. In this instance, since the for loop conditional
is smart enough to avoid the 'test' for zero the extra increment for the
array doesn't hurt. If however, you were to reference two or three
different arrays then the problem would start to look a bit more
obvious. Additionally, it tends to eat up registers with all the arrays
and so it is often forced to reload them in more complicated loops.
I don't quite see what the For does worse than
> would a While in the same place. The For looks under-optimized because it
> sticks to ecx when it already uses a loop var,
This is the counter + array iterator that I mentioned. Using ecx is
just coincidental.
--
Bob Lee
High Performance Delphi - http://www.econos.com/optimize/
Updated August 2