On Sunday, March 20, 2022 at 2:47:29 AM UTC-6, Anton Ertl wrote:

> We have not seen any CPU designed to be immune to Spectre. What we
> have seen are CPUs that have been designed before Spectre was known to
> the CPU designers,

Well, though, some of the CPUs in that latter category _are_ immune to
Spectre. The 80486, the IBM System/360 Model 75, to name a few.

According to Mitch Alsup, though, there _are_ CPU designs out there
that can be made immune to Spectre by means of mitigations at a
significantly smaller performance cost than either x86 or ARM CPUs
must bear. I have no idea what they are, but I _hope_ he doesn't
mean CPUs based on the CDC 6600 scoreboard.

Because _that_ costs performance compared to real OoO, so it's not
really a way to avoid mitigation cost. But surely he would have enough
sense to realize that.

John Savard

On Sunday, March 20, 2022 at 3:15:56 AM UTC-6, Quadibloc wrote:
> On Saturday, March 19, 2022 at 12:17:45 PM UTC-6, John Levine wrote:
> > According to Quadibloc <jsa...@ecn.ab.ca>:
> > >If there was an interrupt because of a memory access instruction
> > >having a page fault, ...
>
> > A what? What is a "page fault"? If you're looking for the 360/67, it's down the
> > hall on your right.
> Oh, you mean that when a program executes a memory access instruction
> to a location which... is in virtual memory, but not physical memory, as that
> location's data (in the case of a read) is only sitting on the swap file... some
> other name than "page fault" is used for the condition of that happening on
> modern computer architectures?
>
> I guess that's reasonable, given that modern architectures probably don't
> use fixed-size pages for this, the way the 360 and 370 did.

....ah, if only I could walk down a hall, and turn right, and be eighteen years
old once again...

John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:
>On Sunday, March 20, 2022 at 2:47:29 AM UTC-6, Anton Ertl wrote:
>
>> We have not seen any CPU designed to be immune to Spectre. What we
>> have seen are CPUs that have been designed before Spectre was known to
>> the CPU designers,
>
>Well, though, some of the CPUs in that latter category _are_ immune to
>Spectre. The 80486, the IBM System/360 Model 75, to name a few.

Sure, CPUs that do not perform speculative execution are immune to
Spectre, because Spectre is based on speculative execution.

>According to Mitch Alsup, though, there _are_ CPU designs out there
>that can be made immune to Spectre by means of mitigations at a
>significantly smaller performance cost than either x86 or ARM CPUs
>must bear. I have no idea what they are

That's disappointing, given that we have discussed this repeatedly
since Spectre was revealed in January 2018, e.g., the discussion
including <2018Jan10.133244@mips.complang.tuwien.ac.at>
(<http://al.howardknight.net/?ID=151559737200>). A recent discussion
has included e.g., <2022Jan23.002646@mips.complang.tuwien.ac.at>
<2022Jan24.144612@mips.complang.tuwien.ac.at>
(<https://news.novabbs.com/computers/article-flat.php?id=23055&group=comp.arch#23055>;
note that the tree overview does not show the postings on the subjects
"Avoiding Spectre" and "Fixing Spectre"; you could try Google Groups
for a better tree view). You even participated in the recent
discussion.

Given that such CPUs are designed to be immune, I would not call it a
mitigation.

As for the architecture (you seem to assume that the supposed
significant performance cost is inevitable for "x86" and ARM):
architecture does not matter, because the bug is a microarchitectural
bug. You fix it in the microarchitecture.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Saturday, March 19, 2022 at 9:33:44 PM UTC-5, Quadibloc wrote:
>> On Saturday, March 19, 2022 at 10:16:10 AM UTC-6, MitchAlsup wrote:
>>
>> > What if the mitigations do not bear such a heavy cost; say on the
>> > order of 1%.......
>> Then, as you say, the right choice _is_ to
>> > Build machines that are immune from Spectré.
><
>> What I've been reading, though, is that while costs of 2% to 3%
>> are associated with _some_ sets of mitigations for Spectre,
>> later versions of the attack have proven harder to deal with, and
>> so the figure for protecting against _all_ the variants of Spectre
>> and Meltdown is now at 25% and climbing.
><
> Just because x86 and ARM are having problems does not mean everyone is.

As does POWER, and zSystem...

Is there an OOO implementation of a CPU (existing, in large-scale
use) that does not suffer from Spectre, or experience slowdowns
from the fixes?

On Sunday, March 20, 2022 at 1:45:27 PM UTC+2, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Saturday, March 19, 2022 at 9:33:44 PM UTC-5, Quadibloc wrote:
> >> On Saturday, March 19, 2022 at 10:16:10 AM UTC-6, MitchAlsup wrote:
> >>
> >> > What if the mitigations do not bear such a heavy cost; say on the
> >> > order of 1%.......
> >> Then, as you say, the right choice _is_ to
> >> > Build machines that are immune from Spectré.
> ><
> >> What I've been reading, though, is that while costs of 2% to 3%
> >> are associated with _some_ sets of mitigations for Spectre,
> >> later versions of the attack have proven harder to deal with, and
> >> so the figure for protecting against _all_ the variants of Spectre
> >> and Meltdown is now at 25% and climbing.
> ><
> > Just because x86 and ARM are having problems does not mean everyone is.
>
> As does POWER, and zSystem...
>
> Is there an OOO implementation of a CPU (existing, in large-scale
> use) that does not suffer from Spectre, or experience slowdowns
> from the fixes?

Is there any high-performance CPU, either OoO or In-order, that does not suffer from SpectreV1 (bound check bypass) ?
I heard claims that both Itanium uArchs are not vulnerable, but don't remember if it came from authoritative source.
POWER6 is certainly vulnerable.
Even some low-performance in-order cores, in particular Arm Cortex-A8, are vulnerable.

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Saturday, March 19, 2022 at 12:17:45 PM UTC-6, John Levine wrote:
>> According to Quadibloc <jsa...@ecn.ab.ca>:
>
>> >If there was an interrupt because of a memory access instruction
>> >having a page fault, ...
>
>> A what? What is a "page fault"? If you're looking for the 360/67, it's down the
>> hall on your right.
>
>Oh, you mean that when a program executes a memory access instruction
>to a location which... is in virtual memory, ...

You keep using words that we 360/91 programmers don't recognize. A program
is either in core (and I mean core) or it isn't.

I think that everyone who designs computers with virtual memory understands
that it has to be possible to restart after a page fault. Usually the
state is synchronized in hardware but I've seen a few where the fault dumps
internal registers and the fault handler has to fix up the state. Intel 860
I think did that.

There have also been implementation bugs. e.g., on the VAX 11/750 you
couldn't recover from faults in read-only stack pages. The brute force
response to that was vfork(), although the sensible approach would have
been to do copy-on-touch rather than copy-on-write in the stack.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Sunday, March 20, 2022 at 5:38:26 PM UTC+2, John Levine wrote:
> According to Quadibloc <jsa...@ecn.ab.ca>:
> >On Saturday, March 19, 2022 at 12:17:45 PM UTC-6, John Levine wrote:
> >> According to Quadibloc <jsa...@ecn.ab.ca>:
> >
> >> >If there was an interrupt because of a memory access instruction
> >> >having a page fault, ...
> >
> >> A what? What is a "page fault"? If you're looking for the 360/67, it's down the
> >> hall on your right.
> >
> >Oh, you mean that when a program executes a memory access instruction
> >to a location which... is in virtual memory, ...
>
> You keep using words that we 360/91 programmers don't recognize. A program
> is either in core (and I mean core) or it isn't.
>
> I think that everyone who designs computers with virtual memory understands
> that it has to be possible to restart after a page fault. Usually the
> state is synchronized in hardware but I've seen a few where the fault dumps
> internal registers and the fault handler has to fix up the state. Intel 860
> I think did that.
>
> There have also been implementation bugs. e.g., on the VAX 11/750 you
> couldn't recover from faults in read-only stack pages. The brute force
> response to that was vfork(), although the sensible approach would have
> been to do copy-on-touch rather than copy-on-write in the stack.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

I think, you're trying to remind to John Savard that S/360, with possible exception of Model 67, had no thing that we now call MMU.
I also think that you can do it in more direct way.

Michael S <already5chosen@yahoo.com> writes:
>On Sunday, March 20, 2022 at 1:45:27 PM UTC+2, Thomas Koenig wrote:
>> Is there an OOO implementation of a CPU (existing, in large-scale=20
>> use) that does not suffer from Spectre, or experience slowdowns=20
>> from the fixes?

Not yet AFAIK.

>Is there any high-performance CPU, either OoO or In-order, that does not su=
>ffer from SpectreV1 (bound check bypass) ?
>I heard claims that both Itanium uArchs are not vulnerable, but don't remem=
>ber if it came from authoritative source.
>POWER6 is certainly vulnerable.=20
>Even some low-performance in-order cores, in particular Arm Cortex-A8, are =
>vulnerable.

References?

Given that Spectre V1 performs two speculatively executed loads, with
the second depending on the result of the first, I would expect that
your typical in-order core is immune to that, because while the
typical in-order core can predict the branch and do instruction
fetching, decoding, and maybe even the execute stage, it stops at the
commit stage because it cannot back out of that. Ok, the second load
could get the result through the forwarding path and continue
execution with that, but do actual in-order cores do that? When does
it stop?

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Anton Ertl wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Sunday, March 20, 2022 at 1:45:27 PM UTC+2, Thomas Koenig wrote:
>>> Is there an OOO implementation of a CPU (existing, in large-scale=20
>>> use) that does not suffer from Spectre, or experience slowdowns=20
>>> from the fixes?
>
> Not yet AFAIK.
>
>> Is there any high-performance CPU, either OoO or In-order, that does not su=
>> ffer from SpectreV1 (bound check bypass) ?
>> I heard claims that both Itanium uArchs are not vulnerable, but don't remem=
>> ber if it came from authoritative source.
>> POWER6 is certainly vulnerable.=20
>> Even some low-performance in-order cores, in particular Arm Cortex-A8, are =
>> vulnerable.
>
> References?
>
> Given that Spectre V1 performs two speculatively executed loads, with
> the second depending on the result of the first, I would expect that
> your typical in-order core is immune to that, because while the
> typical in-order core can predict the branch and do instruction
> fetching, decoding, and maybe even the execute stage, it stops at the
> commit stage because it cannot back out of that. Ok, the second load
> could get the result through the forwarding path and continue
> execution with that, but do actual in-order cores do that? When does
> it stop?
>
> - anton

The following page contains a table of which Spectre's affect which Arm's.
As you can see the in-order Cortex-A8 is vulnerable to V1 and V2.

https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability

Arm are slightly coy about disclosing exactly how this occurs on in-order
cores but I suspect stores values can be speculatively saved in the store
buffer (the secret byte), and used via store-load forwarding as an index
for an adjacent load, to touch a cache line and display the secret value.

This might also occur if the load-store pipeline is processed separately
from integer, and stores are performed at WB stage but loads are
performed at earlier EXE, and if store-load forwarding occurs.
The older store would not block the load from proceeding
allowing load to touch a cache line and display a secret value.

On Sunday, March 20, 2022 at 11:54:37 AM UTC-5, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >On Sunday, March 20, 2022 at 1:45:27 PM UTC+2, Thomas Koenig wrote:
> >> Is there an OOO implementation of a CPU (existing, in large-scale=20
> >> use) that does not suffer from Spectre, or experience slowdowns=20
> >> from the fixes?
>
> Not yet AFAIK.
>
> >Is there any high-performance CPU, either OoO or In-order, that does not su> >ffer from SpectreV1 (bound check bypass) ?
> >I heard claims that both Itanium uArchs are not vulnerable, but don't remem> >ber if it came from authoritative source.
> >POWER6 is certainly vulnerable.=20
> >Even some low-performance in-order cores, in particular Arm Cortex-A8, are =
> >vulnerable.
>
> References?
>
> Given that Spectre V1 performs two speculatively executed loads, with
> the second depending on the result of the first, I would expect that
> your typical in-order core is immune to that, because while the
> typical in-order core can predict the branch and do instruction
> fetching, decoding, and maybe even the execute stage, it stops at the
> commit stage because it cannot back out of that. Ok, the second load
> could get the result through the forwarding path and continue
> execution with that, but do actual in-order cores do that? When does
> it stop?
<
AMD machines were not sensitive to the double load version of Spectré
These all fit the usual definition of GBOoO machines.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Sunday, March 20, 2022 at 8:05:13 AM UTC-6, Michael S wrote:

> Is there any high-performance CPU, either OoO or In-order,

Well, an in-order CPU would definitely not suffer from Spectre.
But is there such a thing as a high-performance in-order CPU?

John Savard

On Sunday, March 20, 2022 at 10:36:03 AM UTC-6, Michael S wrote:

> I think, you're trying to remind to John Savard that S/360, with possible exception of Model 67, had no thing that we now call MMU.
> I also think that you can do it in more direct way.

And I was perfectly well aware that the 360/91 didn't have virtual memory.

Even the 360/195 which had cache didn't have virtual memory.

But since I was discussing out-of-order execution in general, and
not the 360/91 in particular, why on Earth would someone get
the impression that I had forgotten that by my mention of page
faults?

This is now getting more confusing by the minute.

John Savard

On Sunday, March 20, 2022 at 7:58:34 PM UTC+2, MitchAlsup wrote:
> On Sunday, March 20, 2022 at 11:54:37 AM UTC-5, Anton Ertl wrote:
> > Michael S <already...@yahoo.com> writes:
> > >On Sunday, March 20, 2022 at 1:45:27 PM UTC+2, Thomas Koenig wrote:
> > >> Is there an OOO implementation of a CPU (existing, in large-scale=20
> > >> use) that does not suffer from Spectre, or experience slowdowns=20
> > >> from the fixes?
> >
> > Not yet AFAIK.
> >
> > >Is there any high-performance CPU, either OoO or In-order, that does not su=
> > >ffer from SpectreV1 (bound check bypass) ?
> > >I heard claims that both Itanium uArchs are not vulnerable, but don't remem=
> > >ber if it came from authoritative source.
> > >POWER6 is certainly vulnerable.=20
> > >Even some low-performance in-order cores, in particular Arm Cortex-A8, are =
> > >vulnerable.
> >
> > References?
> >
> > Given that Spectre V1 performs two speculatively executed loads, with
> > the second depending on the result of the first, I would expect that
> > your typical in-order core is immune to that, because while the
> > typical in-order core can predict the branch and do instruction
> > fetching, decoding, and maybe even the execute stage, it stops at the
> > commit stage because it cannot back out of that. Ok, the second load
> > could get the result through the forwarding path and continue
> > execution with that, but do actual in-order cores do that? When does
> > it stop?
> <
> AMD machines were not sensitive to the double load version of Spectré
> These all fit the usual definition of GBOoO machines.

AMD machines (Bulldozer derivatives and Zen) were not vulnerable to Spectre-V3, a.k.a. Meltdown.
They were, nevertheless, vulnerable to Spectre-V1, a.k.a. Bound Check Bypass.
Both V1 and V3 are double load exploits.

That's citation from AMD whitepapwer:
For all flavors of variant 1, the AMD mitigation recommendation is software only
solutions which need to be evaluated in a wide range of software including kernel
software, JITs, browsers, and other user applications

> <
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Monday, March 21, 2022 at 5:03:59 AM UTC+2, Quadibloc wrote:
> On Sunday, March 20, 2022 at 8:05:13 AM UTC-6, Michael S wrote:
>
> > Is there any high-performance CPU, either OoO or In-order,
> Well, an in-order CPU would definitely not suffer from Spectre.

No, they are not. Read the post, you are answering to.

> But is there such a thing as a high-performance in-order CPU?

Right now the closest thing to high-performance in-order CPU is Intel Paulson which is
quite significantly slower than the best OoO CPUs, but I wouldn't call it slow in absolute sense.

Back at time of introduction of POWER6 (2007) it was most definitely considered high-performance CPU.
It was approximately on par with the fastest competitor's offerings in single-threaded benchmarks
and was easily beating them in throughput per core metrics.
Yes, it was 15 years ago. Whether it's a lot of time or a little, depends on everyone's perspective.

>
> John Savard

Michael S wrote:
> Overwhelming majority of FP instructions, as measure by appearance in world's program code, is scalar.
> Quite possibly, it's not true for majority of *executed* FP instructions and esp. for majority of
> performed FLOPs, but I wouldn't bet even on that. There are quite a few Cortex-M4s out here per
> each A64FX.
>
> Well, considering that all GPU code is SIMD (even if they call it SIMT), may be not.
> But for GPUs I agree with you and Mitch about uniform latency as a way to go.
>
> BTW, in a post above I didn't mean *one* cycle faster.
> What I had in mind was heavily pipelined design where FMADD is 5 clocks and FADD is 3.

That's interesting: From Mitch's numbers FADD is ~= 48 gates, FMAC = 62,
leaving no possible gates/cycle value which makes the first 3 and the
second 5 cycles?

I.e. FMAC==5 means gates/clock must be between 13 (65 gates) and 15
(75), leaving 39 to 45 gates for a 3-cycles FADD, so I'll take 45 as the
limit.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Monday, March 21, 2022 at 1:46:07 PM UTC+2, Terje Mathisen wrote:
> Michael S wrote:
> > Overwhelming majority of FP instructions, as measure by appearance in world's program code, is scalar.
> > Quite possibly, it's not true for majority of *executed* FP instructions and esp. for majority of
> > performed FLOPs, but I wouldn't bet even on that. There are quite a few Cortex-M4s out here per
> > each A64FX.
> >
> > Well, considering that all GPU code is SIMD (even if they call it SIMT), may be not.
> > But for GPUs I agree with you and Mitch about uniform latency as a way to go.
> >
> > BTW, in a post above I didn't mean *one* cycle faster.
> > What I had in mind was heavily pipelined design where FMADD is 5 clocks and FADD is 3.
>
> That's interesting: From Mitch's numbers FADD is ~= 48 gates, FMAC = 62,
> leaving no possible gates/cycle value which makes the first 3 and the
> second 5 cycles?
>
> I.e. FMAC==5 means gates/clock must be between 13 (65 gates) and 15
> (75), leaving 39 to 45 gates for a 3-cycles FADD, so I'll take 45 as the
> limit.
>
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

I don't know which components of latency are included in figures of Mitch and which are omitted.
In particular, do they include muxes for selection of inputs between RF read ports and forwarding sources?
Such muxes can be more complicated for FMADD (3 inputs) vs FADD/FMUL (2 inputs).
Do figures include delays of pipeline latches?
Do they include wire delays to forwarding network and into input muxes?

What I do know is that, as mentioned in post of Anton Ertl, in recent years we had seen several
high-volume CPU cores that had sw-visible FADD latency = 3 and sw-visible FMADD=5.
FMUL latency of these designs varied (5 on HSWL, 4 on Zen1, 3 on BDWL and Zen2).
One of these designs (Zen2) is still shipping in significant volumes.

I don't know for sure what was FO4 per stage design target for each and every of these cores,
but if I had to guess I'd say that none of them was 16 or 17, more like 20 or 21.

On Monday, March 21, 2022 at 1:04:15 PM UTC-5, Michael S wrote:
> On Monday, March 21, 2022 at 1:46:07 PM UTC+2, Terje Mathisen wrote:
> > Michael S wrote:
> > > Overwhelming majority of FP instructions, as measure by appearance in world's program code, is scalar.
> > > Quite possibly, it's not true for majority of *executed* FP instructions and esp. for majority of
> > > performed FLOPs, but I wouldn't bet even on that. There are quite a few Cortex-M4s out here per
> > > each A64FX.
> > >
> > > Well, considering that all GPU code is SIMD (even if they call it SIMT), may be not.
> > > But for GPUs I agree with you and Mitch about uniform latency as a way to go.
> > >
> > > BTW, in a post above I didn't mean *one* cycle faster.
> > > What I had in mind was heavily pipelined design where FMADD is 5 clocks and FADD is 3.
> >
> > That's interesting: From Mitch's numbers FADD is ~= 48 gates, FMAC = 62,
> > leaving no possible gates/cycle value which makes the first 3 and the
> > second 5 cycles?
> >
> > I.e. FMAC==5 means gates/clock must be between 13 (65 gates) and 15
> > (75), leaving 39 to 45 gates for a 3-cycles FADD, so I'll take 45 as the
> > limit.
> >
> > Terje
> >
> > --
> > - <Terje.Mathisen at tmsw.no>
> > "almost all programming can be viewed as an exercise in caching"
<
> I don't know which components of latency are included in figures of Mitch and which are omitted.
> In particular, do they include muxes for selection of inputs between RF read ports and forwarding sources?
<
These are pipeline delays not FPU delays. FPU delay starts when operands arrive and
finish when FPU result is forwarded to become an operand of a subsequent instruction.
<
> Such muxes can be more complicated for FMADD (3 inputs) vs FADD/FMUL (2 inputs).
<
If you can route the wires to where they need to be, a 1:2 mux versus a 1:4 mux is
not that much different in the gates of delay proplem (both are 1 gate of delay).
<
> Do figures include delays of pipeline latches?
>
No flip-flops are part of the clocking of the pipeline, not part of the logic of calculation.
>
> Do they include wire delays to forwarding network and into input muxes?
<
Yes,
>
> What I do know is that, as mentioned in post of Anton Ertl, in recent years we had seen several
> high-volume CPU cores that had sw-visible FADD latency = 3 and sw-visible FMADD=5.
> FMUL latency of these designs varied (5 on HSWL, 4 on Zen1, 3 on BDWL and Zen2).
> One of these designs (Zen2) is still shipping in significant volumes.
>
> I don't know for sure what was FO4 per stage design target for each and every of these cores,
> but if I had to guess I'd say that none of them was 16 or 17, more like 20 or 21.
<
Athlon was 16 gates of logic per cycle
Opteron was 17 gates of logic per cycle
Bulldozer tried to be 12.....

On Monday, March 21, 2022 at 8:12:52 PM UTC+2, MitchAlsup wrote:
> On Monday, March 21, 2022 at 1:04:15 PM UTC-5, Michael S wrote:
> > On Monday, March 21, 2022 at 1:46:07 PM UTC+2, Terje Mathisen wrote:
> > > Michael S wrote:
> > > > Overwhelming majority of FP instructions, as measure by appearance in world's program code, is scalar.
> > > > Quite possibly, it's not true for majority of *executed* FP instructions and esp. for majority of
> > > > performed FLOPs, but I wouldn't bet even on that. There are quite a few Cortex-M4s out here per
> > > > each A64FX.
> > > >
> > > > Well, considering that all GPU code is SIMD (even if they call it SIMT), may be not.
> > > > But for GPUs I agree with you and Mitch about uniform latency as a way to go.
> > > >
> > > > BTW, in a post above I didn't mean *one* cycle faster.
> > > > What I had in mind was heavily pipelined design where FMADD is 5 clocks and FADD is 3.
> > >
> > > That's interesting: From Mitch's numbers FADD is ~= 48 gates, FMAC = 62,
> > > leaving no possible gates/cycle value which makes the first 3 and the
> > > second 5 cycles?
> > >
> > > I.e. FMAC==5 means gates/clock must be between 13 (65 gates) and 15
> > > (75), leaving 39 to 45 gates for a 3-cycles FADD, so I'll take 45 as the
> > > limit.
> > >
> > > Terje
> > >
> > > --
> > > - <Terje.Mathisen at tmsw.no>
> > > "almost all programming can be viewed as an exercise in caching"
> <
> > I don't know which components of latency are included in figures of Mitch and which are omitted.
> > In particular, do they include muxes for selection of inputs between RF read ports and forwarding sources?
> <
> These are pipeline delays not FPU delays. FPU delay starts when operands arrive and
> finish when FPU result is forwarded to become an operand of a subsequent instruction.
> <
> > Such muxes can be more complicated for FMADD (3 inputs) vs FADD/FMUL (2 inputs).
> <
> If you can route the wires to where they need to be, a 1:2 mux versus a 1:4 mux is
> not that much different in the gates of delay proplem (both are 1 gate of delay).
> <
> > Do figures include delays of pipeline latches?
> >
> No flip-flops are part of the clocking of the pipeline, not part of the logic of calculation.
> >
> > Do they include wire delays to forwarding network and into input muxes?
> <
> Yes,

Do you assume 2 FPUs that freely forward to each other and one or more non-FP ports that also can be sources to FPU ?
For example, in HSWL/BDWL each of two FPUs can be feed by 3 execution ports. I also think that during FP loads
results can be forwarded into FPUs bypassing RF, but I am not sure about it.
And that just HSWL/BDWL, Zen2 is significantly wider than that.

> >
> > What I do know is that, as mentioned in post of Anton Ertl, in recent years we had seen several
> > high-volume CPU cores that had sw-visible FADD latency = 3 and sw-visible FMADD=5.
> > FMUL latency of these designs varied (5 on HSWL, 4 on Zen1, 3 on BDWL and Zen2).
> > One of these designs (Zen2) is still shipping in significant volumes.
> >
> > I don't know for sure what was FO4 per stage design target for each and every of these cores,
> > but if I had to guess I'd say that none of them was 16 or 17, more like 20 or 21.
> <
> Athlon was 16 gates of logic per cycle
> Opteron was 17 gates of logic per cycle
> Bulldozer tried to be 12.....

Those CPU mentioned above are certainly much more conservative w.r.t. clocking than BD and probably more conservative than K8 too. Esp. Broadwell that has max. clock frequency = 3.8GHz which is quite low relatively to other Intel 14nm CPUs.
(Broadwell-E turbos to 4GHz, but it's a different die and likely does it only at quite high voltage).

On 2022-01-25, MitchAlsup wrote:
> On Tuesday, January 25, 2022 at 12:45:50 AM UTC-6, Thomas Koenig wrote:
>> Looking at Alpha, and also now at LoonArch, I find separate
>> instructions for 32-bit and 64-bit addition for a 64-bit
>> architecture. For example, Alpha has both addl (add longword)
>> and addq (add quadword).
>>
>> What is not quite clear to me is the rationale behind this - a
>> 64-bit addition is (blindlingly obviously) just a 32-bit addition
>> when ignoring the high bits.
> <
> For My 66000 architecture, arithmetic is only register size (except
> an accommodation for single precision floats).
> <
> On the integer side: if one wants a particular number of bits after
> arithmetic has been performed, I have both signed and unsigned
> versions of extract (any number of bits from 1..64) not just std
> sizes.

Have you got the statistics for how common this is?

It seems to me that "main stream" 64-bit ISA:s (x86-64 & ARMv8) have
fairly extensive support for 32-bit arithmetic on 64-bit registers.
RV64 also has reasonable 32-bit arithmetic support.

My assumption is that the decision was data driven: that too much
software is written with C type int rather than long long, and the
compiler ends up emitting lots of sign/zero-extension or truncation
operations.

I'm still not sure if this could be sorted out more efficiently at the
compiler level, to minimize the number of size conversions, or if that
is already a solved problem and the decision to support 32-bit
arithmetic is actually warranted.

> <
> On the floating pint side: There is a full complement (49) of insts
> that convert one {S, U, F, D} to the other with any of the rounding
> modes.

On Monday, March 21, 2022 at 1:48:29 PM UTC-5, Michael S wrote:
> On Monday, March 21, 2022 at 8:12:52 PM UTC+2, MitchAlsup wrote:
> > On Monday, March 21, 2022 at 1:04:15 PM UTC-5, Michael S wrote:
> > > On Monday, March 21, 2022 at 1:46:07 PM UTC+2, Terje Mathisen wrote:
> > > > Michael S wrote:
> > > > > Overwhelming majority of FP instructions, as measure by appearance in world's program code, is scalar.
> > > > > Quite possibly, it's not true for majority of *executed* FP instructions and esp. for majority of
> > > > > performed FLOPs, but I wouldn't bet even on that. There are quite a few Cortex-M4s out here per
> > > > > each A64FX.
> > > > >
> > > > > Well, considering that all GPU code is SIMD (even if they call it SIMT), may be not.
> > > > > But for GPUs I agree with you and Mitch about uniform latency as a way to go.
> > > > >
> > > > > BTW, in a post above I didn't mean *one* cycle faster.
> > > > > What I had in mind was heavily pipelined design where FMADD is 5 clocks and FADD is 3.
> > > >
> > > > That's interesting: From Mitch's numbers FADD is ~= 48 gates, FMAC = 62,
> > > > leaving no possible gates/cycle value which makes the first 3 and the
> > > > second 5 cycles?
> > > >
> > > > I.e. FMAC==5 means gates/clock must be between 13 (65 gates) and 15
> > > > (75), leaving 39 to 45 gates for a 3-cycles FADD, so I'll take 45 as the
> > > > limit.
> > > >
> > > > Terje
> > > >
> > > > --
> > > > - <Terje.Mathisen at tmsw.no>
> > > > "almost all programming can be viewed as an exercise in caching"
> > <
> > > I don't know which components of latency are included in figures of Mitch and which are omitted.
> > > In particular, do they include muxes for selection of inputs between RF read ports and forwarding sources?
> > <
> > These are pipeline delays not FPU delays. FPU delay starts when operands arrive and
> > finish when FPU result is forwarded to become an operand of a subsequent instruction.
> > <
> > > Such muxes can be more complicated for FMADD (3 inputs) vs FADD/FMUL (2 inputs).
> > <
> > If you can route the wires to where they need to be, a 1:2 mux versus a 1:4 mux is
> > not that much different in the gates of delay proplem (both are 1 gate of delay).
> > <
> > > Do figures include delays of pipeline latches?
> > >
> > No flip-flops are part of the clocking of the pipeline, not part of the logic of calculation.
> > >
> > > Do they include wire delays to forwarding network and into input muxes?
> > <
> > Yes,
<
> Do you assume 2 FPUs that freely forward to each other and one or more non-FP ports that also can be sources to FPU ?
<
You have to assume that the Reg File, any FPU, and any LD port can be feeding operands to any FPU.
So, if you have 2 FPUs, 3 memory units, each operand comes from 1 of 6 places. (1 RF, 2 FPU, 3 MEM).
<
> For example, in HSWL/BDWL each of two FPUs can be feed by 3 execution ports.
<
Can you say this again and use different words. Or at least define the words you are using.
<
> I also think that during FP loads
> results can be forwarded into FPUs bypassing RF, but I am not sure about it.
> And that just HSWL/BDWL, Zen2 is significantly wider than that.
<
Hard Starboard Won't List ?
Bowel Deflection Wasn't Liked ?
<
> > >
> > > What I do know is that, as mentioned in post of Anton Ertl, in recent years we had seen several
> > > high-volume CPU cores that had sw-visible FADD latency = 3 and sw-visible FMADD=5.
> > > FMUL latency of these designs varied (5 on HSWL, 4 on Zen1, 3 on BDWL and Zen2).
> > > One of these designs (Zen2) is still shipping in significant volumes.
> > >
> > > I don't know for sure what was FO4 per stage design target for each and every of these cores,
> > > but if I had to guess I'd say that none of them was 16 or 17, more like 20 or 21.
> > <
> > Athlon was 16 gates of logic per cycle
> > Opteron was 17 gates of logic per cycle
> > Bulldozer tried to be 12.....
> Those CPU mentioned above are certainly much more conservative w.r.t. clocking than BD and probably more conservative than K8 too. Esp. Broadwell that has max. clock frequency = 3.8GHz which is quite low relatively to other Intel 14nm CPUs.
> (Broadwell-E turbos to 4GHz, but it's a different die and likely does it only at quite high voltage).

On 2022-03-21, John Dallman wrote:
> In article <t1ahum$4rd$1@dont-email.me>, m.delete@this.bitsnbites.eu
> (Marcus) wrote:
>
>> My assumption is that the decision was data driven: that too much
>> software is written with C type int rather than long long, and the
>> compiler ends up emitting lots of sign/zero-extension or truncation
>> operations.
>
> Software that counts macroscopic physical objects, or their equivalents
> in modelling space, is usually happy with 32-bit ints. Switching to
> 64-bit ints for that won't be attractive until support for ILP32
> programming environments is /completely/ dead for any given type of
> applications.
>

There's also the issue of programming language bias. The utterly
dominant integer type in C/C++ is still "int", which maps to a 32-bit
integer for most architectures.

for (int i = 0; i < N; i++) { do_something(); }

....is still very common. And types are viral (you usually avoid mixing
different integer types in a segment of code).

And finally, there's the data size issue. For large data sets it's
perfectly valid to use 32-bit (or even 16-bit) integers to reduce memory
and D$ load. It's a common trick in 3D graphics, for instance (which is
what you were hinting at, I guess).

> The stuff I work on is all 64-bit, except that some customers still
> insist on 32-bit Windows support. This is usually because they use one or
> another commercial software component whose supplier is scared of 64-bit,
> or wants a great deal more money for it.

In my case it's 32-bit architectures for embedded platforms that set the
limit. E.g. many DSP:s are 32-bit, and ARMv7 is still common. But ARMv8
and x86-64 are also in the mix.

>
> John

On Monday, March 21, 2022 at 1:59:37 PM UTC-5, Marcus wrote:
> On 2022-01-25, MitchAlsup wrote:
> > On Tuesday, January 25, 2022 at 12:45:50 AM UTC-6, Thomas Koenig wrote:
> >> Looking at Alpha, and also now at LoonArch, I find separate
> >> instructions for 32-bit and 64-bit addition for a 64-bit
> >> architecture. For example, Alpha has both addl (add longword)
> >> and addq (add quadword).
> >>
> >> What is not quite clear to me is the rationale behind this - a
> >> 64-bit addition is (blindlingly obviously) just a 32-bit addition
> >> when ignoring the high bits.
> > <
> > For My 66000 architecture, arithmetic is only register size (except
> > an accommodation for single precision floats).
> > <
> > On the integer side: if one wants a particular number of bits after
> > arithmetic has been performed, I have both signed and unsigned
> > versions of extract (any number of bits from 1..64) not just std
> > sizes.
>
> Have you got the statistics for how common this is?
<
Page Fault handlers need 10-bit, 9-bit field extracts from VA.
<
Floating point needs 11-bits (8-bits) 1-bit down (33-down) from the top.
<
And once you start supporting random offsets and random lengths,
you don't need explicit support for 32-bits.
<
It occur often enough and costs so little beyond the shifter itself,
that it falls into the "why not" category. Note:, 64-bit Shift is 3 layers
of logic (4:1 Mux) with lots of wire delay. You have time to decode the
mask and amplify the sign bit and still fit in 16-gtes with ease.
<
Thus, adding masking capability to the shifter adds area but no real
delay.
>
> It seems to me that "main stream" 64-bit ISA:s (x86-64 & ARMv8) have
> fairly extensive support for 32-bit arithmetic on 64-bit registers.
> RV64 also has reasonable 32-bit arithmetic support.
<
Mostly because they started out as 32-bit machines (or smaller).
None of them has support for 24-bit arithmetic, or 37, or 49.....
<
And part of this is "if you don't provide X" programmers will not use
X and thus you were justified in leaving X out. A self fulfilling prophecy.
>
> My assumption is that the decision was data driven: that too much
> software is written with C type int rather than long long, and the
> compiler ends up emitting lots of sign/zero-extension or truncation
> operations.
<
Any compiler (hint LLVM) which compiles code such that the size of
the container never contains a value outside of what it is allowed
to contain will have plenty of these "smashes". This has low surprise
coefficient.
>
> I'm still not sure if this could be sorted out more efficiently at the
> compiler level, to minimize the number of size conversions, or if that
> is already a solved problem and the decision to support 32-bit
> arithmetic is actually warranted.
<
Where does it stop?
{8, 16, 32, 64} ?
{Right, middle, left}
{1,2,4,128,256,512}?
{2,3,5,7,11,13,17,19,23}?
In other words, they are your encoding, choose what delivers more to
your bottom line.
<
And if you want to know how it hurts your bottom line: jump in and
draw up the circuits to see if it fits !
>
> > <
> > On the floating pint side: There is a full complement (49) of insts
> > that convert one {S, U, F, D} to the other with any of the rounding
> > modes.
<
In the 1-operand subGroup, there are encodings for 2048 instructions
burning up 49 of these, which use almost identical circuitry, and with
only 8 other encodings, there is not an argument where you run out
of encodings, the argument switches around to what are useful to the
compiled code.

On Monday, March 21, 2022 at 9:04:57 PM UTC+2, MitchAlsup wrote:
> On Monday, March 21, 2022 at 1:48:29 PM UTC-5, Michael S wrote:
> > On Monday, March 21, 2022 at 8:12:52 PM UTC+2, MitchAlsup wrote:
> > > On Monday, March 21, 2022 at 1:04:15 PM UTC-5, Michael S wrote:
> > > > On Monday, March 21, 2022 at 1:46:07 PM UTC+2, Terje Mathisen wrote:
> > > > > Michael S wrote:
> > > > > > Overwhelming majority of FP instructions, as measure by appearance in world's program code, is scalar.
> > > > > > Quite possibly, it's not true for majority of *executed* FP instructions and esp. for majority of
> > > > > > performed FLOPs, but I wouldn't bet even on that. There are quite a few Cortex-M4s out here per
> > > > > > each A64FX.
> > > > > >
> > > > > > Well, considering that all GPU code is SIMD (even if they call it SIMT), may be not.
> > > > > > But for GPUs I agree with you and Mitch about uniform latency as a way to go.
> > > > > >
> > > > > > BTW, in a post above I didn't mean *one* cycle faster.
> > > > > > What I had in mind was heavily pipelined design where FMADD is 5 clocks and FADD is 3.
> > > > >
> > > > > That's interesting: From Mitch's numbers FADD is ~= 48 gates, FMAC = 62,
> > > > > leaving no possible gates/cycle value which makes the first 3 and the
> > > > > second 5 cycles?
> > > > >
> > > > > I.e. FMAC==5 means gates/clock must be between 13 (65 gates) and 15
> > > > > (75), leaving 39 to 45 gates for a 3-cycles FADD, so I'll take 45 as the
> > > > > limit.
> > > > >
> > > > > Terje
> > > > >
> > > > > --
> > > > > - <Terje.Mathisen at tmsw.no>
> > > > > "almost all programming can be viewed as an exercise in caching"
> > > <
> > > > I don't know which components of latency are included in figures of Mitch and which are omitted.
> > > > In particular, do they include muxes for selection of inputs between RF read ports and forwarding sources?
> > > <
> > > These are pipeline delays not FPU delays. FPU delay starts when operands arrive and
> > > finish when FPU result is forwarded to become an operand of a subsequent instruction.
> > > <
> > > > Such muxes can be more complicated for FMADD (3 inputs) vs FADD/FMUL (2 inputs).
> > > <
> > > If you can route the wires to where they need to be, a 1:2 mux versus a 1:4 mux is
> > > not that much different in the gates of delay proplem (both are 1 gate of delay).
> > > <
> > > > Do figures include delays of pipeline latches?
> > > >
> > > No flip-flops are part of the clocking of the pipeline, not part of the logic of calculation.
> > > >
> > > > Do they include wire delays to forwarding network and into input muxes?
> > > <
> > > Yes,
> <
> > Do you assume 2 FPUs that freely forward to each other and one or more non-FP ports that also can be sources to FPU ?
> <
> You have to assume that the Reg File, any FPU, and any LD port can be feeding operands to any FPU.
> So, if you have 2 FPUs, 3 memory units, each operand comes from 1 of 6 places. (1 RF, 2 FPU, 3 MEM).

Almost. In particular case of HSWL/BDWL 2 FPUs, 1 non-FP SIMD EU (int ops, logical ops, shifts, shuffles) and 2 MEM loads.

> <
> > For example, in HSWL/BDWL each of two FPUs can be feed by 3 execution ports.
> <
> Can you say this again and use different words. Or at least define the words you are using.

Execution ports are defined both in Intel's "Intel® 64 and IA-32 Architectures Optimization Reference Manual", e.g. 248966-042b
and in Agner Fog's microarchitecture tables.

> <
> > I also think that during FP loads
> > results can be forwarded into FPUs bypassing RF, but I am not sure about it.
> > And that just HSWL/BDWL, Zen2 is significantly wider than that.
> <
> Hard Starboard Won't List ?
> Bowel Deflection Wasn't Liked ?

Intel codename. Haswell and Broadwell. A pair of rather similar microarchitectures, but FP parts are not identical.

> <
> > > >
> > > > What I do know is that, as mentioned in post of Anton Ertl, in recent years we had seen several
> > > > high-volume CPU cores that had sw-visible FADD latency = 3 and sw-visible FMADD=5.
> > > > FMUL latency of these designs varied (5 on HSWL, 4 on Zen1, 3 on BDWL and Zen2).
> > > > One of these designs (Zen2) is still shipping in significant volumes.
> > > >
> > > > I don't know for sure what was FO4 per stage design target for each and every of these cores,
> > > > but if I had to guess I'd say that none of them was 16 or 17, more like 20 or 21.
> > > <
> > > Athlon was 16 gates of logic per cycle
> > > Opteron was 17 gates of logic per cycle
> > > Bulldozer tried to be 12.....
> > Those CPU mentioned above are certainly much more conservative w.r.t. clocking than BD and probably more conservative than K8 too. Esp. Broadwell that has max. clock frequency = 3.8GHz which is quite low relatively to other Intel 14nm CPUs.
> > (Broadwell-E turbos to 4GHz, but it's a different die and likely does it only at quite high voltage).

On Monday, March 21, 2022 at 5:25:38 AM UTC-6, Michael S wrote:

> Right now the closest thing to high-performance in-order CPU is Intel Paulson which is
> quite significantly slower than the best OoO CPUs, but I wouldn't call it slow in absolute sense.

If it isn't possible to make an in-order CPU that is as fast
as *the best there is*, then in-order CPUs are basically
eliminated from consideration - for doing the heavy lifting.

But that doesn't mean that they're useless. Even a 386 SX
could run Windows 3.1 with good responsiveness, therefore
a 486 CPU would be plenty fast enough for a core intended
to run untrusted code.

But just running untrusted code on a Spectre-proof CPU isn't
good enough unless all the rest of your security is perfect, and
that doesn't seem to be attainable. (But if this _were_ the only
practical alternative, then perhaps more effort might be made
to make operating systems genuinely secure. Yes, they're not
secure now, but this is largely for lack of trying, in my opinion.
_That's_ why I make this suggestion, though it may seem daft
to Mitch.)

John Savard

On Monday, March 21, 2022 at 5:25:38 AM UTC-6, Michael S wrote:
> On Monday, March 21, 2022 at 5:03:59 AM UTC+2, Quadibloc wrote:

> > But is there such a thing as a high-performance in-order CPU?

> Right now the closest thing to high-performance in-order CPU is Intel Paulson which is
> quite significantly slower than the best OoO CPUs, but I wouldn't call it slow in absolute sense.

I had to look it up to refresh my memory. Intel Poulson is an *Itanium*,
and this microarchitecture was even made a bit faster in Kittson by
using a newer process.

This certainly would offer a jump in performance over a 486 core.

But it doesn't address the issue of *running existing Windows software*
which is basically what a computer is *for* as far as the market is
concerned.

John Savard