3 ms·
Yeah. I wonder if its a classic VLIW or if the pipeline is exposed and/or skewed. exposed: The results of operations that take more than one clock cycle don't
by Symmetry 4y ago
Yeah. I wonder if its a classic VLIW or if the pipeline is exposed and/or skewed.
exposed: The results of operations that take more than one clock cycle don't necessarily appear at their destination the cycle after the instruction is executed. Think branch delay slots but potentially for multiplies and loads too.
skewed: Loads, processing, and stores can happen on subsequent clock ticks so simple loops don't necessarily need prologues and epilogues.
A compiler can handle either of these for a particular CPU pretty easily but they tend to eliminate binary compatibility. Code morphing as in the Transmeta lineage like to use both of these. Other VLIWs with barrel multithreading, like the Hexagons DSPs in Snapdragon SOICs, don't need them.
EDIT: The Mill guys have a video on how this works on their system. They've got their own names for things for some reason but they do a good job of explaining how this all works: https://millcomputing.com/docs/execution/ https://millcomputing.com/docs/execution/
- pclmulqdq 4y agoIn my time as an FPGA developer, I wrote a lot of tiny processing cores that were exposed and skewed VLIW designs for specific applications. If the code isn't changing much, they work extremely well in a very small silicon area and power footprint. However, they are awful to program. In supercomputing, this sort of thing sometimes appears and works well (like the Pezy-SC2 chips that recently came out). However, they usually fail on general purpose computing tasks.
- Symmetry 4y agoYeah. Normally sophisticated software scheduling works great on DSP-like tasks where the memory access patterns are very predictable but suffer a lot where you tend to have unexpected cache misses that a deep OoO system could just paper over.
- londons_explore 4y agoI think the benefits of both could be had with "software assisted branch prediction/caching". Ie. you transpile your x86 code to native code for your VLIW machine. Then you run that code for a few hundred clock cycles till bam "cache not ready on time exception" which fires when you try to execute an instruction that is expecting to read memory from the cache, but the cache isn't yet populated with that value. Then you re-run your transpiler which will produce new code which either does a better job of reading the data into the cache ahead of time, or issues different instructions which take more time and read data direct from RAM. Remember a software transpiler sometimes has more information than a typical deep OoO CPU, because it can use a lot more memory for state (eg. remembering that a particular branch or memory access won't be cached), and it can even persist state across system reboots. It can also do far more expensive optimizations and save the results, something a deep OoO CPU can't do because all the optimizations need to be doable in hardware.
- rayiner 4y agoI would be curious to learn what makes the “skewed” approach work. Googling fails me since this turns up a lot of articles on clock skew.