- If a function has no channel variables, but requires a stack (either because there are function calls, or too many local variables to fit into the register set) it is possible that the stack pointer eliminated even though it is required. (Discovered 2008-Oct-29)

- Bugzilla is not yet available. This is being deferred until our second major release in 2009-Q1.

- Worst Case Thread Length calculation & thread identification not being displayed in the Analyses File

- eTPU2 Feature Missing: Independent MRLE negation

- eTPU2 Feature Missing: access of engine-relative address space.

- Partial eTPU2 Support (missing engine base addressing and independent MRLE negation)

- Import of .COD file (for "dual" linking) is not well tested and will likely fail in some cases. (not to user's. This is not a big task, let us know if this is going to cause a problem and we will move it in)

- '\' line continuation/splicing fails for some installations when there is a conflict with other GNU cpp.exe installations. Avoid use of '\' in source code at the current time. ETEC is packaged with GNU cpp.exe for this initial release; for source code see here and here. This will be removed with the second major release Q1 2009. All ETEC interactions with GNU cpp.exe are at the file I/O level.

- Macro replacement is not done recursively (e.g. not done after replacing # and ##).

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

- The SET1 demo is using a non-latest version.

- Inline Assembly not yet supported, nor is the "official" BC-Compatible assembly syntax supported.

- initialized const identifiers are always allocating memory currently; in the future these identifiers will not use memory when it is not needed.

- 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 an (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)