Adrian (a.delete@this.acm.org) on July 20, 2020 11:03 pm wrote:
> Heikki Kultala (heikk.i.kultala.a.delete@this.gmail.com) on July 20, 2020 2:27 pm wrote:
> >
> > > VLIW is static (compile-time/assembly writing time) scheduling,
> > > and combines several independent ops into a single instruction.
> >
> > Yep.
> >
> > But EPIC ...
> > 1) can combine dependent ops into same instruction word. However, fetch bundles and execution
> > bundles are totally different things, stop bits can be positioned at middle of an instruction
> > word, and do not have to be positioned at the end of an instruction word.
> >
> > https://player.slideplayer.com/90/14672257/slides/slide_20.jpg
> >
> > 2) Is not statically scheduled.
> >
> >
> > Poulson is not VLIW. Puolson is an EPIC, and EPIC is closer to RISC
> > than VLIW, EPIC can be considered to be just a RISC, where
> >
> > 1) There are always 3 instructions in a 128-bit fetch block.
> > 2) There is a way of saying that some instructions cannot have data dependencies between them.
> >
>
>
> It is true that EPIC is not VLIW but it is somewhere half-way between a VLIW and
> a superscalar RISC, in the hope of obtaining some of the advantages of both.
>
> Unfortunately for them, EPIC only had the disadvantages of both.
>
> Unlike a VLIW, which can have very high performance for special purposes, EPIC was constrained
> by binary backward compatibility of the ISA, so the only path for increasing the performance
> in later generations was to become more and more like a normal superscalar, but in that case
> it was stuck with a very non-efficient low-density instruction encoding, which resulted in much
> larger program sizes than for any other common ISA, with the associated disadvantages.

Yes, I agree on this.

The code density is terrible which is a true hindurance for CPUs, and the instruction set is too fixed for ASIPs.

But you even forgot out some of the disadvantages:

It had some complicated things to make static scheduling for it more efficient. But these then were just extra clutter and trouble when the schedule got even more dynamic

For example the register windows. They are not needed in a dynamic superscalar RISC; and just make register renaming harder.

Speculative load could also be considered as this kind of feature, though it could also have SOME reasonable use also in out-of-order processor; For example in tree search where the branches are very unpredictable, speculatively load both child pointers immediately after loading the parent. The checks whether we have found the node we want or if the pointer we want to continue to is null (not found) can then be checked while speculatively loading the pointers.

But after the Pandoras box opened for Spectre, this kind of optimizations might not be favoured.



But there might still be something good left in the main idea of EPIC, if we would leave out all the quicks Itanium had. On OoOE core the parallel bundles do not help much because we want to schedule any instructions from windows of ~100 instructions so knowing 3 of them are parallel still leaves 98 to check against.

But for example if we would only use the execution bundles with instructions that use the same register inputs(but could have different immediate inputs). Then the whole bundle would be waiting for the same value, and when that value arrives, only one dependence check is needed to execute all the instructions in it.

Of course, most instructions do not have operands of type R,I so that there are two R,I instructions nearby using the same R, so our average bundle size would probably be less than 1.5 instructions, but this would still save SOME dependence checks.