Effect of pointers etc.

> The algorithms contain lots of 2 dimensional arrays (naturally). Now what
> is the cost in terms of hardware of macros such as these
>
> #define DISP1(i,j) *(dispar.disp0 + i*MAX_X0 + j)
> #define DISP(i,j) *(dispar.displr + i*MAX_X0 + j)
> #define DISPold(i,j) *(dispar.disp_old + i*MAX_X0 + j)


You really need to expand on this. Why??? The reason is that code within a
macro cannot be optimized directly. It is dependent upon where the macro
is expanded and the code that is substituted within it. Remember macros
are textual substitution which occur before lexing and parsing and
expressions are not even identified until after parsing (let alone the
semantic meanings). Expressions are usually what is optimized.


Assuming the optimum case like the following...


              int y, z;
              x = DISP1(y, z) + DISP(y, z) + DISPold(y, z);


This code will expand in the following after macro preprocessing.


              int y, z;
              x = *(dispar.disp0 + y*MAX_X0 + z) +
                      *(dispar.displr + y*MAX_X0 + z) +
                      *(dispar.disp_old + y*MAX_X0 + z);


Most optimizing compilers can calculate the expression y*MAX_X0+z once
since it is within the same basic block. Better opt. compilers could also
do it if the expression appeared in several different basic blocks.


Next, if this expression appeared inside a loop and both y and z are loop
invariant, then the expression can be hoisted outside of the loop.


Lastly, if y and z are compile time constants, the expression y*MAX_X0+z
can be folded into a compile time constant.


Most C compilers work with the following phases (yes, it is really a
little simplistic)...


      C-preprocessing --> Lex analysis --> Parsing --> Semantics Analysis -->
            Optimizations --> Backend Code Generation


I hope that this helps....


Thank you.


Steve Simmons
--

Return to the comp.compilers page.
Search the comp.compilers archives again.