One of the problems with VLIW architectures is lack of binary compatibility between CPU generations.
Suppose you had 4-way VLIW architecture and the next generation become 8-way. Even if new CPU will be able to run old 4-way code, it will twice as slower, I.e you need to recompile your software.
I imagine just-in-time compilation has a lot to offer there. Managed runtimes already have the advantage of being able to automatically tailor the machine code to the target CPU.
In a sense, they did. And they did famously fail to meet expectations.
But considering that nowadays other stacks which rely on jitting regularly achieve real-world performance that is competitive with much native-compiled software, it seems safe to presume that Transmeta's performance problems stemmed from reasons beyond the basic idea behind CMS.
