According to quadibloc <[email protected]>:

If the same benefits could be obtained through VLIW techniques without
those costs - but with an overhead cost of extra bits in the
instructions - that would be a very promising technology. So their
problem wasn't that they forgot what they knew about OoO, but rather
perhaps that their knowledge of the limitations of VLIW was
insufficient.

I knew the people at Multiflow pretty well, might have worked there if I hadn't already made other plans.

They failed for two reasons. One was organizational, management was overstressed
and burned out. But the other was technical. VLIW works great when the code is regular enough that it can schedule memory operations and know that they won't conflict. But when the memory access patterns are data dependent, it has to schedule conservatively and performance suffers. OoO may be expensive in hardware, but it can schedule those data dependent accesses.

I suppose that's why the surviving VLIWs are mostly in media processors where the data accesses are very regular.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)