TMTA will realize a greater improvement than in the typical hardware-only product cycle
because the CMS can handle a good deal more ILP than what has been achieved with
Crusoe’s 128-bit VLIW.
You really believe that? You should examine how much ILP IPF compilers are finding
in raw program code source. They still have lots of room for improvement even for a
6 way VLIW.
Despite the cute name CMS is just a JIT compiler. A compiler whose source code
is x86 object code and output is VLIW native code. The x86 source code already has
a lot of the ILP squeezed out of it compared to raw program source code due to
the serializing nature of few GPRs, a condition code based computational model,
and a lack of any aliasing information regarding program variables. At the same time
because CMS is in operation on the fly interleaved with program execution it has to be
very parsimonious in the types of profile information it can capture and examine and
the types of computationally intensive code optimizations it can employ compared to
a state of the art compiler for IPF or superscalar RISC.
In summary, getting a decent architectural performance improvement from going from a
4 way VLIW to an 8 way VLIW is a problem of first order difficulty even when your compiler
has full access to program source code information, extensive global run time profiling
information, and virtually unlimited compile time. But in the case of TMTA, CMS lacks all
three and as a result a really difficult problem is made much worse. So excuse my
extreme scepticism about your claim.
