Forum Replies Created
Could that be generalized to any arbitrary branch?
For example, consider this code:
int foo(int a) { // just whatever random code int b = a * a; int c = b * b; int d = a + b + c; // a branch that could be precalculated at the beginning of the function if (a) { return bar(d); } else { return baz(d); } }At the beginning of the function, we have enough information to know whether we will take that branch or not. A compiler could potentially introduce an instruction at the beginning to precalculate if the branch will be taken and notify the predictor, or there could be “delayed branch” instruction something like “branch in 4 cycles if a is non zero”.
This kind of code shows all the time in loops and precondition checking in functions.
So I have been taking a class on computer architecture (I am a software guy). The more I learn the more in awe I am with the beauty of the Mill instruction encoding and other features.
CISC sucks. It needs millions of transistors just to decode 6 instructions.
RISC is a clear improvement, but the superscalar OoO design is ridiculously complicated, as I learn about the Tomasulo algorithm, wide issue/decode, speculative execution, I can’t help but think “this is insane, there has to be a better way”. It feels like the wrong path.
VLIW seems like a more reasonable approach. I know binary compatibility problems and stalls have been a challenge for VLIW architectures.The Mill is just beautiful, it has a sane encoding and simplicity of a VLIW. But phasing and double instruction stream really take it to the next level.
The separate load issue and retire is in hindsight the obvious way to solve the stalls due to memory latency that is so common in VLIW.
The branch predictor is so cool too, you can predict the several EBB’s in advance, even before you start execution. Mainstream predictors have to wait until they get to the branch instruction.
The specializer is a neat solution to binary compatibility.I really hope to see this CPU make it to silicon.
Technical details are very sparse, but from their presentations, they say they are not VLIW.
They sometimes compare their stuff with Itanium (VLIW), but they claim they don’t stall as much as Itanium. Supposedly it has dynamic issue but it is not out of order. From what I gather, their compiler generates instruction bundles that encode dependencies between instructions. That sounds an awful lot like an EDGE architecture such as the TRIPS and Microsoft’s E2.
They recently discovered SplitSpectre, which is a spectre variant with a much simpler gadget.
With regular spectre, this was the gadget needed in the victim space:
if (x < array1_size) y = array2[array1[x] * 4096];Which is not that common.
With SplitSpectre, this is the gadget needed:
if (x < array1_size) y = array1[x];Which happens practically everywhere.
Access to array2 can be in the villan’s space if y is returned.
From your talk, I reckon the mill is still not affected.
These are pretty awesome and encouraging number Ivan.
” I suspect inlining and pipelining would make little difference to the counts when enabled because they improve cycle time and overall program latency”
Wouldn’t inlining help a lot in the instruction count? you eliminate the call operation, and if the inlined function is small, you might even be able to squeeze the operations into existing instructions, making the inlined function essentially free.
-
This reply was modified 5 years, 4 months ago by
goldbug.
-
This reply was modified 5 years, 4 months ago by
I asked the same thing a while ago.
They published a paper with the answer
https://millcomputing.com/blog/wp-content/uploads/2018/01/Spectre.03.pdfsee the section called “Software and compiler speculation”
Their answer seems to be a loadtr operation, that will only perform the load if the predicate is met, avoiding branching.
When I asked, they said they were still trying to decide if there was a better way.
-
This reply was modified 5 years, 12 months ago by
-
This reply was modified 5 years, 12 months ago by
