Compiler Effects

Earlier releases of AMX for many CISC processors were coded in assembly language. The reasons were historical. The most significant benefits were execution speed and code invariability. For these older products, the AMX code executed by the processor today is exactly the same code tested by KADAK and in use by developers world wide since the particular AMX product was first released. Only documented code changes to eliminate faults or add enhancements have been made.

Today, AMX is coded in C to satisfy the demands of developers not familiar with assembly language code and to ease the porting of AMX by KADAK to new and diverse processor architectures. However, the benefits of C have not been without a cost.

The greatest cost has been the sacrificing of AMX code invariability. The quality and efficiency of the AMX kernel is now dependent upon the code generation capabilities of the C compiler with which AMX is compiled. It is unlikely that any two C compilers will produce identical AMX code sequences. In fact, different releases of the same C compiler may very well produce different copies of AMX code. Fortunately, the testing methods developed by KADAK over many years help detect faults induced by compiler variations.

There are other factors introduced by the C compiler which also may affect execution time. The parameter setup and procedure entry and exit code sequences can vary greatly among C compilers. The register preservation requirements of a particular C compiler, over and above those dictated by the processor, may affect AMX overhead.

Finally, beware of code optimizations touted by the compiler vendors. AMX source code does not include the kind of C code sequences which often confuse optimizing C compilers. Despite this fact, several C compilers have, over the years, with the simplest level of optimization enabled, generated invalid instruction sequences for perfectly valid C statements.