VLIW Compiler problems:
- Different Chip Versions – every VLIW processor can have a different number of functional units. This means that potentially each VLIW processor will need its own version of a VLIW compiler.
- Compiler Complexity – traditionally when you think of computer architectures (CISC and RISC), you only need to translate higher-level languages into machine code. The VLIW compiler adds the scheduling process after it converts to machine code. Compared to CISC or RISC compilers, this makes the compiler code much denser and more difficult to write. For the VLIW compiler to use multiple functional units simultaneously (the true advantage to VLIW), it must first spot out the areas that can use parallel execution. If it cannot find an efficient way to do this, then the compiler must issue no-ops.
Lack of ILP (Instruction Level Parallelism):
In order to fully take advantage of a VLIW machine, you want to execute many things in parallel. If you are using something graphics intensive like a DVD, this works out fine for you. Each pixel must change color, and these colors can be changed in parallel, voila! If you are, however, running a word processor that doesn’t take advantage of this feature, you will find that a VLIW machine is much slower than a typical CISC-like Pentium machine. This very experiment was shown by the Transmeta Corporation. Their argument is that for most PC fans out there today, multimedia speed will win out over any noticeable difference in your word processor.
Reverse Compatibility:
Since the ISA for VLIW is a bit different from that of RISC or CISC systems, there may be a problem with using legacy code. Before VLIW can grow popular, software is in development to deal with this problem. It has been shown that the computer market doesn’t like to cater to just one minority in the field. Over the years many computer platforms have become remarkably similar. Even gaming consoles today use similar software. Many games coming out for the wondrous Microsoft X-Box are also coming out for the Playstation 2 and the Nintendo Game Cube. As you can see, you want your architecture to be compatible with whatever the competition has.
Memory:
Due to the compiler issues we discussed earlier, these no-ops created can be a burden on your memory. And branch predictions can double your memory load. In a branch prediction, all of the registers in your VLIW must be mirrored to prevent them from being corrupted.
Is there anything being done about these problems?
Through maturing technology, most of these problems are either currently being dealt with or have already been taken care of. First of all, any new architecture will have the opportunity to use the latest ILP (Instruction-Level Parallelism) enhancing techniques in their instruction set. Researchers today believe that ISA support for speculative execution and non-faulting operations will be the new wave. This will allow compilers to schedule parallel code easier and safer. Secondly, a more flexible instruction encoding scheme has paved the way to remove object code compatibility and code density problems.
As far as the memory issue goes, steps are also being taken to reduce the no-ops from wasting your time. Smarter VLIW compilers are filling these no-op fields with useful instructions that will have to be fetched later in the code anyways (somewhat of a pre-fetching technique). Also, memory today is not nearly as much of a concern as it was back in the 70’s or 80’s. Currently you can purchase 256 MB of DDR RAM (it can read and write to the memory at the same time, sort of how a full duplex modem communicates) for only $70. I don’t believe that memory will present that much of a problem to these new VLIW machines that will be introduced in the near future.