On 6/19/2021 11:57 AM, Michael S wrote:
> On Saturday, June 19, 2021 at 7:57:56 PM UTC+3, Anton Ertl wrote:
>> nedbrek <ned...@yahoo.com> writes:
>>> One of the interesting results of our research was that out-of-order machines are easier to ramp to high frequency. This is because an in-order machine suffers more as L1D latency increases (you need to get the compiler to extract more and more ILP).
>> The numbers I have seen posted here (in an IA-64 discussion) are that
>> one extra L1D cycles costs 10% on in-order and 5% on OoO. But I don't
>> see why this should make it hard to ramp up clock rates. Sure, you
>> don't see as much benefit from the higher clock rate because of that
>> effect, but you should still see a benefit, because ALU ops go faster
>> and because the compiler is able to fill some of the load latency with
>> useful work.
>>
>> My impression is that in-order designs are harder to clock fast
>> because they have less localized control recurrences than OoO; and
>> last time I wrote that, the people in the know did not really
>> contradict me, but discussed some techniques to work around that, such
>> as having a backup of the pipeline state and rolling back to that.
>> - anton
>> --
>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
>
> I never tried to think hard about it, but my uneducated impression always was that it applies to "normal" In-Order, the one that does interlocks in hardware.
> I don't see why it should apply to in-order designs with exposed pipeline, especially to those that also expose to software a banked structure of register files.
> Of course, even designs like those has to have a way to deal with variable-length latency of memory instructions... May be, if it's done by replay the control could remain distributed?

It can be done by splitting the load's request from the retire; it's
called "deferred load".

On Saturday, June 19, 2021 at 10:59:07 PM UTC+3, Ivan Godard wrote:
> On 6/19/2021 11:57 AM, Michael S wrote:
> > On Saturday, June 19, 2021 at 7:57:56 PM UTC+3, Anton Ertl wrote:
> >> nedbrek <ned...@yahoo.com> writes:
> >>> One of the interesting results of our research was that out-of-order machines are easier to ramp to high frequency. This is because an in-order machine suffers more as L1D latency increases (you need to get the compiler to extract more and more ILP).
> >> The numbers I have seen posted here (in an IA-64 discussion) are that
> >> one extra L1D cycles costs 10% on in-order and 5% on OoO. But I don't
> >> see why this should make it hard to ramp up clock rates. Sure, you
> >> don't see as much benefit from the higher clock rate because of that
> >> effect, but you should still see a benefit, because ALU ops go faster
> >> and because the compiler is able to fill some of the load latency with
> >> useful work.
> >>
> >> My impression is that in-order designs are harder to clock fast
> >> because they have less localized control recurrences than OoO; and
> >> last time I wrote that, the people in the know did not really
> >> contradict me, but discussed some techniques to work around that, such
> >> as having a backup of the pipeline state and rolling back to that.
> >> - anton
> >> --
> >> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> >> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
> >
> > I never tried to think hard about it, but my uneducated impression always was that it applies to "normal" In-Order, the one that does interlocks in hardware.
> > I don't see why it should apply to in-order designs with exposed pipeline, especially to those that also expose to software a banked structure of register files.
> > Of course, even designs like those has to have a way to deal with variable-length latency of memory instructions... May be, if it's done by replay the control could remain distributed?
> It can be done by splitting the load's request from the retire; it's
> called "deferred load".

Mill-style "deferred load" is a performance feature - you trade decode bandwidth for earlier issue of load.
On architecture with lots of visible registers it's not needed at all. Unlike Itanium-style advanced load that can be potentially useful even here.
Neither Mill's "deferred load" nor Itanium's "advanced load" do nothing to alleviate a need for global interlock HW .

On 6/19/2021 2:28 PM, Michael S wrote:
> On Saturday, June 19, 2021 at 10:59:07 PM UTC+3, Ivan Godard wrote:
>> On 6/19/2021 11:57 AM, Michael S wrote:

<snip>

>>> Of course, even designs like those has to have a way to deal with variable-length latency of memory instructions... May be, if it's done by replay the control could remain distributed?
>> It can be done by splitting the load's request from the retire; it's
>> called "deferred load".
>
> Mill-style "deferred load" is a performance feature - you trade decode bandwidth for earlier issue of load.

Perhaps you are thinking of "pickup load". Deferred load costs no extra
bandwidth.

On Sunday, June 20, 2021 at 12:41:03 AM UTC+3, Ivan Godard wrote:
> On 6/19/2021 2:28 PM, Michael S wrote:
> > On Saturday, June 19, 2021 at 10:59:07 PM UTC+3, Ivan Godard wrote:
> >> On 6/19/2021 11:57 AM, Michael S wrote:
> <snip>
> >>> Of course, even designs like those has to have a way to deal with variable-length latency of memory instructions... May be, if it's done by replay the control could remain distributed?
> >> It can be done by splitting the load's request from the retire; it's
> >> called "deferred load".
> >
> > Mill-style "deferred load" is a performance feature - you trade decode bandwidth for earlier issue of load.
> Perhaps you are thinking of "pickup load". Deferred load costs no extra
> bandwidth.

Yes, I was thinking of "pickup load".
But deferred load also has decode cost since you have to find place for delay specifier in "verb" word.