Nesting C-Macros, CRC calculation, Eclipse Java crash - c

Question

What I have done is awfully heavy on the preprocessor. MinGW takes a minute or 2 to compile it, but it does pass unit tests; Eclipse is struggling and pops up a Java heap low, or eventually overflow. My question is there a way to make this easier for the preprocessor? Shall I just increase my Java heap? Or is there a better way to populate a table at compile time
Here it is:
I have created a CRC look up table and decided to populate it at compile time (key word: compile time), and didn't want to hard code any numbers. So I came up with a macro to calculate CRC, only hard coding the polynomial. (perhaps slightly hard to read, but it passes unit tests)
// Define CRC polynomial
#define POLYNOMIAL (0x8005)
#define CRC_1ITERATION(crc) ( \
(((crc)&0x7FFF)<<1)^( ((crc)&0x8000)?POLYNOMIAL:0 ) )
And then propagated it to 16 iterations... a re-invocation of the macro 16 iterations deep!
// Iterate the CRC polynomial
#define CRC_2ITERATIONS(crc) CRC_1ITERATION( CRC_1ITERATION(crc) )
#define CRC_4ITERATIONS(crc) CRC_2ITERATIONS( CRC_2ITERATIONS(crc))
#define CRC_8ITERATIONS(crc) CRC_4ITERATIONS( CRC_4ITERATIONS(crc))
#define CRC_16ITERATIONS(crc) CRC_8ITERATIONS( CRC_8ITERATIONS(crc))
CRC_16ITERATIONS() is now something I can invoke to transition an input CRC to it's output 16 iterations later. I use this to populated my table. Actually, I made even more nested macros to populate the table, but to keep things simple this code is enough to make Eclipse struggle:
// Populate the table (EDIT: corrected spelling)
CRC_16ITERATIONS(0), CRC_16ITERATIONS(1), CRC_16ITERATIONS(2), CRC_16ITERATIONS(3),
CRC_16ITERATIONS(4), CRC_16ITERATIONS(5), CRC_16ITERATIONS(6), CRC_16ITERATIONS(7),
CRC_16ITERATIONS(8), CRC_16ITERATIONS(9), CRC_16ITERATIONS(10), CRC_16ITERATIONS(11),
CRC_16ITERATIONS(12), CRC_16ITERATIONS(13), CRC_16ITERATIONS(14), CRC_16ITERATIONS(15)
It worked in MinGW including passing unit tests but like I said, I think I'm blowing some sort of parenthesis or macro expansion stack in Java/Eclipse. I was hoping to scale this up to a 256 entry table but I suspect MinGW will take a half-hour to compile it.

Answer 1

The first eight iterations just shift the byte up eight places. You can do that in the argument, and use CRC_8ITERATIONS instead of CRC_16ITERATIONS (which by the way you misspelled it CRC_16ITERATION several times).
I.e.:
CRC_8ITERATIONS(0), CRC_8ITERATIONS(1 << 8), CRC_8ITERATIONS(2 << 8), CRC_8ITERATIONS(3 << 8),
CRC_8ITERATIONS(4 << 8), CRC_8ITERATIONS(5 << 8), CRC_8ITERATIONS(6 << 8), CRC_8ITERATIONS(7 << 8),
CRC_8ITERATIONS(8 << 8), CRC_8ITERATIONS(9 << 8), CRC_8ITERATIONS(10 << 8), CRC_8ITERATIONS(11 << 8),
CRC_8ITERATIONS(12 << 8), CRC_8ITERATIONS(13 << 8), CRC_8ITERATIONS(14 << 8), CRC_8ITERATIONS(15 << 8)
That compiles about 256 times faster for me than using CRC_16ITERATIONS.
For just that particular set, I can go faster still by initially shifting up those four zeros at the top, and using CRC_4ITERATIONS. I.e.:
CRC_4ITERATIONS(0), CRC_4ITERATIONS(1 << 12), CRC_4ITERATIONS(2 << 12), CRC_4ITERATIONS(3 << 12),
CRC_4ITERATIONS(4 << 12), CRC_4ITERATIONS(5 << 12), CRC_4ITERATIONS(6 << 12), CRC_4ITERATIONS(7 << 12),
CRC_4ITERATIONS(8 << 12), CRC_4ITERATIONS(9 << 12), CRC_4ITERATIONS(10 << 12), CRC_4ITERATIONS(11 << 12),
CRC_4ITERATIONS(12 << 12), CRC_4ITERATIONS(13 << 12), CRC_4ITERATIONS(14 << 12), CRC_4ITERATIONS(15 << 12)
That compile time was too fast for me to measure.
I can take it further, add a CRC_3ITERATIONS, and do this:
0, CRC_1ITERATION(1 << 15), CRC_2ITERATIONS(2 << 14), CRC_2ITERATIONS(3 << 14),
CRC_3ITERATIONS(4 << 13), CRC_3ITERATIONS(5 << 13), CRC_3ITERATIONS(6 << 13), CRC_3ITERATIONS(7 << 13),
CRC_4ITERATIONS(8 << 12), CRC_4ITERATIONS(9 << 12), CRC_4ITERATIONS(10 << 12), CRC_4ITERATIONS(11 << 12),
CRC_4ITERATIONS(12 << 12), CRC_4ITERATIONS(13 << 12), CRC_4ITERATIONS(14 << 12), CRC_4ITERATIONS(15 << 12)
You could use this trick on the first 128 bytes to only iterate as many times as needed with CRC_7ITERATIONS, CRC_6ITERATIONS, etc. The last 128 bytes will all need to use CRC_8ITERATIONS, which is still pretty fast. At least for me using clang llvm 3.5.
Though I prefer just running a separate program to generate a file to include that has the table in it.