Mail Archives: djgpp/1996/12/01/13:02:28
On Wed, 27 Nov 1996 13:17:14 -0500 (EST), Glen Miner <gminer AT ca DOT newbridge DOT com>
wrote:
>I don't think that removing the recursion is a viable solution, and I
>doubt that it would improve the algorithm's speed any: It's actually doing
>a search of a very wide "tree" of "data". (Sorta like a chess move search
>engine).
It depends on how often you recurse and how many functions are called. Inline
everything you can. Examine the possibility of using depth-first and making it
iterative instead of width-first and recursive. Use the options that minimize
function call overhead (like frame or stack checking), even ones that might
otherwise be unsafe it you know there to be no problem with the code.
>How well will djgpp deal with two dimentional arrays? Say I'm stepping
>through char MyArray[9][9] like so:
>
> for (x = 0; x < 6; x++)
> for (y = 0; y < 7; y++)
> MyArray [x][y] = SomeValue;
Unroll this loop by hand if the compiler won't do it for you:
MyArray[x][0] = SomeValue;
MyArray[x][1] = SomeValue;
...
MyArray[x][6] = SomeValue;
If the compiler doesn't generate straightforward references, use a pointer to
MyArray[x] and auto-increment. Depending on how bad the produced code is (and
this really shouldn't be a problem here), consider putting the values into a
separate linear array and using memmov.
>Will it be smart and index it by a pointer so that it doesn't have to
>recalculate the address every time?
It probably won't make a difference, since compilers have more information
about your intent when you use arrays than when you use pointers. Generally,
the equivalent C code for arrays and pointers will generate the same assembly.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91351-4454 96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list
- Raw text -