WARE

Import of .COD file (for "dual" linking) is not well tested and will likely fail in some cases.

ONLY WHEN OPTIMIZATIONS ARE DISABLED: certain constructs which need to be atomic are not atomic

Message warning of a out-of-order link thread has been disabled. (It had been generating a spurious message in certain cases, and it was thought better to disable the warning altogether for the the time being. Note that in reality, the Link Service Request Event in the Alternate Entry table has the lowest priority, so don't place this thread earlier than the M1. M2, and HSR threads, because it DONT WORK DAT WAY!

Global data size calculation listed for each translation unit is just an approximation and does not correctly handle "holes." A future compile will assign "holes" (wasted memory) to translation units such that the sum of the memory listed for all translation units equals the total amount of global memory actually used. (right now these don't match, though the "total-used" number found in the auto-generate header file is correct.

The error case where two "C" files are linked together with different and clashing options is not well checked. (Note: for the time being, be carefull to use identical command line settings for ALL compiled code)

Stack size calculation returns (probably-invalid) 256 bytes when both analyzer and optimizer are disabled.

The function-by-function stack usage #define is not being generated. (only a single #define that represents the worst-case stack usage of ALL functions. In reality if (say) the worst-case-stack-usage function is not being used, a smaller stack could be calculated using the MAXIMUM of all the other functions)