[Info-vax] Poulson at hot-chips 2011

[Neil Rieck]

On Aug 23, 11:18 pm, David Kanter <dkan... at gmail.com> wrote:
> On Aug 23, 10:36 am, JF Mezei <jfmezei.spam... at vaxination.ca> wrote:
>
> > IanMiller wrote:
> > > there is this
>
> > >http://communities.intel.com/community/openportit/server/blog/2011/08...
>
> > I am puzzled by the "instruction replay".  They say it is to try
> > instructions again if an error is detected.
>
> > Does this mean that there is a significant enough number of errors in
> > cache to warrant a CPU having such logic to "retry" instructions ?
> > Wouldn't it be easier to fix the cache so there are no errors ?
>
> > Or is this just marketing gobbledeegook to make it look like they are
> > adding new features even though they may be useless in practice ?
>
> Hi, glad to see that some folks out there enjoyed my Poulson article.
>
> I can clarify this pretty easily.
>
> Replay is a technique to ensure correct execution of instructions in
> an in-order CPU design.  It's also used in IBM's z10 CPU.
>
> Basically, if the older Itanium design encountered an instruction that
> it wasn't ready for (e.g. waiting for a load to get an input operand),
> it would stall everything.  Basically, the entire CPU stops making any
> forward progress until the instruction is ready (e.g. the load finally
> comes back from cache or memory).  This is a problem since as soon as
> you have a stall, you have to let every part of the chip know to stop.
>
> With replay, it works differently.  The instructions are issued -
> whether or not all the inputs are ready.  If there was a problem (e.g.
> an input wasn't ready), the instruction basically gets sent back to
> the front of the line for issue (or replayed).  This is nice, since
> you can detect problems later in the pipeline - moreover, you don't
> need to let every part of the CPU know there's a problem.
>
> It's generally a much more power efficient approach than global stall
> (i.e. McKinley/Montecito/Tukwila).
>
> Either way, Poulson isn't really an out-of-order chip - at best it
> might issue one or two instructions in slightly different order.
> However, it's still very fundamentally in-order...just a much more
> efficient approach.
>
> David

I, for one, enjoyed your article as well as this explanation.

Comment: While I am still pissed that HPQ killed Alpha in favor of
Itanium, I have come to the realization that we will never see OpenVMS
on x86-64. This means that Itanium (especially, Tukwila now, and
Poulson in 2012) is the only hope to save our favorite OS from
irrelevance. If Itanium chips continue to get faster while cheaper,
"the board" at Oracle will come to realize that not supporting Oracle-
DB on Itanium (just to save the SUN hardware line) was a big mistake.
Larry Ellison won't be the CEO forever. (he's already 67)

Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/