2 ms·

Wow, never heard of that ambitious CPU arch before. Looks like an early loser in the RISC wars that was recycled into later PA-RISC and Itanium. https://en.m.w

Wow, never heard of that ambitious CPU arch before. Looks like an early loser in the RISC wars that was recycled into later PA-RISC and Itanium. https://en.m.wikipedia.org/wiki/Apollo_PRISM https://en.m.wikipedia.org/wiki/Apollo_PRISM

justsomehnguy 2y ago
> In some respects, the VLIW design can be thought of as "super-RISCy", as it offloads the instruction selection process to the compiler as well. In the VLIW design, the compiler examines the code and selects instructions that are known to be "safe", and then packages them into longer instruction words. For instance, for a CPU with two functional units, like the PRISM, the compiler would find pairs of safe instructions and stuff them into a single larger word. Inside the CPU, the instructions are simply split apart again, and fed into the selected units. Wait a second. So while this is all fancy and gives a better performance (with a mature compiler chuckles in Itanium)... but it's totally incompatible with virtualisation (as we know it on x86 systems)? Cache trashing is surely always a way to throw out the performance, but this design would make it times worse, AFAIU?
- pinewurst 2y ago
  Nobody cared about virtualization when those systems were designed, other than IBM (and compatible) mainframe designers. None of that generation of workstation/server architecture - MIPS, SPARC, HP-PA, Alpha or for that matter 68k - had that as a consideration.
  - deleted 2y ago
    [deleted]
- zik 2y ago
  I don't think VLIW is incompatible with virtualisation. The amount of CPU state you need to load and save on context switches is a little higher than other architectures so it has a minor effect on the efficiency of virtualisation. But other than that there's no reason VLIW can't be virtualised. Not that the Apollos actually had hardware support for virtualisation features such as nested page tables. These machines were from the days before virtualisation was popular. Only IBM mainframes had it back then AFAIK.
- Taniwha 2y ago
  I've built VLIW hardware, virtualisation is not an issue, cache usage is not different than other CPUs - in fact modern superscalar, out-of-order CPUs effectively do what the compiler for VLIWs do dynamically on the fly. The big issue about VLIW hardware is that it tends to address a particular performance point - usually lets you squeeze out the last bit of performance without having to go to the complexity of dynamic instruction scheduling (and doubling the CPU size) - the problem comes when you want to do your next chip and the trade off ends up being different, you can't keep the same instruction set and so making an ARCHITECTURE is hard

justsomehnguy 2y ago

> In some respects, the VLIW design can be thought of as "super-RISCy", as it offloads the instruction selection process to the compiler as well. In the VLIW design, the compiler examines the code and selects instructions that are known to be "safe", and then packages them into longer instruction words. For instance, for a CPU with two functional units, like the PRISM, the compiler would find pairs of safe instructions and stuff them into a single larger word. Inside the CPU, the instructions are simply split apart again, and fed into the selected units. Wait a second. So while this is all fancy and gives a better performance (with a mature compiler chuckles in Itanium)... but it's totally incompatible with virtualisation (as we know it on x86 systems)? Cache trashing is surely always a way to throw out the performance, but this design would make it times worse, AFAIU?

pinewurst 2y ago
Nobody cared about virtualization when those systems were designed, other than IBM (and compatible) mainframe designers. None of that generation of workstation/server architecture - MIPS, SPARC, HP-PA, Alpha or for that matter 68k - had that as a consideration.
- deleted 2y ago
  [deleted]
zik 2y ago
I don't think VLIW is incompatible with virtualisation. The amount of CPU state you need to load and save on context switches is a little higher than other architectures so it has a minor effect on the efficiency of virtualisation. But other than that there's no reason VLIW can't be virtualised. Not that the Apollos actually had hardware support for virtualisation features such as nested page tables. These machines were from the days before virtualisation was popular. Only IBM mainframes had it back then AFAIK.
Taniwha 2y ago
I've built VLIW hardware, virtualisation is not an issue, cache usage is not different than other CPUs - in fact modern superscalar, out-of-order CPUs effectively do what the compiler for VLIWs do dynamically on the fly. The big issue about VLIW hardware is that it tends to address a particular performance point - usually lets you squeeze out the last bit of performance without having to go to the complexity of dynamic instruction scheduling (and doubling the CPU size) - the problem comes when you want to do your next chip and the trade off ends up being different, you can't keep the same instruction set and so making an ARCHITECTURE is hard