 Codegen verification/regression tests
 =====================================

 Overview
 -------- 
 These tests are designed to exercise the CPU specific portion of the code
generator, not the C front end or the generic codegen. They are a knockoff
of the 'positive' tests and should likewise be used for regression testing,
but are also designed to aid in development/porting of new codegens.

 In particular, these tests should exercise every single instruction of
the cg 'assembly language', with all possible combinations of operands and
operators. In other words, these tests should validate the implementation 
of xxxoptab and xxxtable modules where 'xxx' is the target CPU type (such
as i86, 386, axp, ppc etc.).

 The first and easier part is to verify that the cg can handle all the
combinations and won't die with an internal error, let alone crash. The second
and much more difficult part is to verify that the generated code actually
delivers correct results. This is probably impossible or at least not
practical to do in the general case, but after passing these tests a cg
developer should have some confidence that there's a good chance the cg will
work for real world programs.

 Verifying that the cg won't generate internal errors does not require the
target hardware and can be easily done in a cross development environment.
Verifying that the generated code is correct requires that it be executed,
which means target hardware or at least some form of emulator is needed.

 Wherever possible, these tests should use plain ANSI C and refrain from
using any compiler specific extensions. That way we can run the tests with
3rd party compilers to verify that the tests are correct, as well as examine
the code generated by competition.


 Implementation
 --------------
 At this point it is thought that C is sufficient for implementing these
tests. There is probably very little C++ could do that C can't on the code
generation level, and the same goes for Fortran. If we had a Pascal compiler,
we'd probably have to use that language to verify the nesting of lexical
levels. But we don't, so there's nothing to test. 

 It seems that the best way to test operators and type conversions is to
construct a large number of very small non-static functions. That way, the
cg can't take any shortcuts and must generate the code with very little room
for transformations that would be undesirable in this case. The functions
look approximately like this:

U4 op_add_U4_I2_U1( I2 a, U1 b )
{
    return( a + b );
} 

 where U4, I2 and U1 are typedefs corresponding to internal codegen types,
ie. unsigned 32-bit integer, signed 16-bit integer and unsigned 8-bit
integer, respectively. The full set of scalar types, with corresponding
C types for a typical 32-bit platform, is this:

 U1 - unsigned char
 I1 - signed char
 U2 - unsigned short
 I2 - signed short
 U4 - unsigned long
 I4 - signed long
 U8 - unsigned long long
 I8 - signed long long
 FS - float
 FD - double
 FL - long double (at this point the same as double)

 Since writing the test matrix for even one binary operator by hand would
be mind numbingly boring, the tests are generated thorough a combination of
preprocessor abuse and editor search & replace brute force.

 Note that the test matrix for those binary operators which that can handle
all of the above types as operands and results tends to be rather large
(11 * 11 * 11 = 1331). This serves as a useful preprocessor, compiler and
codegen capacity test.


 Execution
 --------- 
 As mentioned above, these tests have two levels: compile only and compile
plus execute. For the first level to pass, it is sufficient that the compiler
generates an object file without generating errors or crashing. For the second
level to pass, the object file also has to be linked, executed, and must
produce an 'OK' test result.
