On Sunday, April 10, 2022 at 4:24:07 PM UTC+3, EricP wrote:
> Anton Ertl wrote:
> > Quadibloc <jsa...@ecn.ab.ca> writes:
> >> You have heard the crazy way *I* would have designed a processor. With separate
> >> pipelines for single precision and double precision and quad precision and one-and-a-half
> >> precision.
> >>
> >> But if one were to put a 60-bit floating-point number down the double precision pipeline,
> >> no, one would not have to drain it to change the mode. (The double precision pipeline
> >> would actually be designed for 72-bit floats, which would also use it. 80 bit temporary
> >> reals would go down the double precision pipeline, unless there was one for 96-bit
> >> floats.)
> >>
> >> So mixing precisions would make your programs go *faster*, because it would utilize
> >> the other pipelines that otherwise would not be used. The very opposite of Intel!
> >
> > In the last weeks I have noticed unusually many people posting
> > over-long lines (i.e., longer than 80 chars, and ideally you should
> > limit the lines to 70-72 chars to leave room for quoting). Is there
> > some new attack on Usenet conventions coming out from Google?
> >
> > Anyway, my guess for the reason for slow precision-setting is that
> > Intel and AMD microarchitects want the precision setting to be known
> > to the decoder, so it can deliver the precision as part of the uop.
> > This requires that when setting the precision, decoding of subsequent
> > instructions starts from scratch. An alternative would be to deliver
> > the precision as another input in the OoO engine, but that would
> > require additional resources in the OoO engine, an apparently they
> > thought that spending these resources elsewhere would buy more
> > performance.
> >
> > Concerning your separate-pipelines idea, in that setup it's even more
> > advantageous to know the precision early in instruction processing:
> > You can have separate queues/ports for the different precisions and
> > steer the instructions to these ports early, instead of having common
> > FP queues, and steering the instructions to the right pipelines only
> > when all the data (including precision) is in; ok, you could also have
> > two stages of queues, but that introduces additional complication,
> > area, and probably latency.
> >
> > Also, even if switching is fast, how frequent is code with mixed
> > precision? E.g., in DGEMM you only use double precision operations,
> > while in SGEMM you only use single-precision operations.
> >
> > Bottom line: There's a reason why Intel and AMD are designing their
> > CPUs the way they are.
> The x87 FP Control Word has flags to control
> Infinity, Rounding, Precision, and Exception masking.
>
> If you are changing some bits and not others then you have to
> store the current value, mask in your changes, and load it FLDCW.
> That store can either be synchronous FSTCW or asynchronous FNSTCW
> (remember x87 is a separate co-processor with long running
> transcendentals, and the FSTCW is actually an assembler macro
> instruction which emits FWAIT, FNSTCW).
>
> If any of the exception mask flags change then we may need to
> synchronize with current and pending exceptions status.
> So this ties changes in the control word into current
> and future state in the status register.
>
> Then there is the issue that the new CW is coming from the
> data path so to merge the CW bits into the uOp bits in the decoder
> implies some kind of front end delay between when the FLDCW decodes
> and when the new value propagates back to decode.
>
> An alternatively design merges the FPCW flags into the uOp in the
> FPU itself, but then we have to deal with the FP instructions are
> launching out-of-order and we have to make sure the right set
> of flags goes to the right uOp.
> For this I would have a small set physical FPCW registers,
> 4 should be sufficient, and a renamer for the one logical CW register.
> This makes the CW bits a uOp data dependency like other FP operands
> and it would require its own wake-up matrix and forwarding bus,
> but much simpler than the normal operand support logic.
> The then current (future) CW bits merge into the uOp when
> it is launched for execution.
>
> With this a write to the FPCW would only stall as long as it took
> the new CW value to arrive at its CW physical register or appear
> on its forwarding bus, so ideally allowing back-to-back execution.

According to my understanding, what you described as alternative design
is exactly what Intel did starting from Yonah and up to Nehalem (of course,
excluding Bonell).
In Sandy Bridge and later, it seems that limitation of 4 renaming registers gone.
Probably, by now x87 Control Word is stored in one of the big PRFs.

AMD Bulldozer and Zen are similar to Sandy Bridge derivatives.

AMD K7/K8/K10 does not rename Control Word, but somehow FLDCW is slow
only when the new value differs from the old one.

Pentium 4 went into opposite direction. x87 Control Word is not renamed, but
the value predicted to be the same as before a previous FLDCW . When prediction
fails then everything is flushed and CPU goes through very slow replay. Agner says
143 clocks, but this things are hard to measure. However in common scenario
[of late 90s and early 00s] software temporarily changes Control Word and
then restores the previous value, so this primitive prediction works well.

"Small" x86 cores (AMD Bobcat&Jaguar, Intel Silvermon and Goldmont) do not
rename x87 Control Word and don't try to be smart about it in any ways.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>The implied OR of the uOp status with the current status
>creates a serial dependency that we'd need to break up.

It's not really serial. OR is associative, so you can flatten the
evaluation sequence into an arbitrarily flat tree.

>It is not the same as the integer status flags because those
>flags overwrite the prior values so a rename can handle them.
>
>Whereas each FP exception bit has to OR with its prior state
>and then merge with that uOps exception mask bits to
>decide whether to throw and exception.
>So a simple renamer for the FPSW wouldn't suffice.

That's an interesting deviation from the usual OoO problems.

One thought is to maintain these bits in the in-order retirement unit.
If multiple FP instructions are retired in a cycle, it's relatively
easy to OR all their FP-exception bits and then or them with the bits
up to now. This is also where control-flow exceptions (traps) are
triggered; and if there are branch instructions that directly branch
on these bits, this is where the predictions are checked.

The only problem with this approach is an instruction that reads the
FPSW; such an instruction would have to wait until it is retired (and
therefore until all earlier instructions are retired) to produce its
result for the OoO engine. If the result is the only used for a
branch, that's not so bad, though: the branch prediction is also only
checked when the branch is retired.

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

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> The implied OR of the uOp status with the current status
>> creates a serial dependency that we'd need to break up.
>
> It's not really serial. OR is associative, so you can flatten the
> evaluation sequence into an arbitrarily flat tree.

The serialization comes in when FP instruction #1 has an
FP overflow but its uOp exception mask has overflow disabled,
and FP instruction #2 has no overflow but enables overflow exceptions.
So overflow from #1 is thrown at #2.

Ultimately there is no way to avoid this imposition of
program order on the update the the FP status word,
though there are oppotunities to optimize this.

>> It is not the same as the integer status flags because those
>> flags overwrite the prior values so a rename can handle them.
>>
>> Whereas each FP exception bit has to OR with its prior state
>> and then merge with that uOps exception mask bits to
>> decide whether to throw and exception.
>> So a simple renamer for the FPSW wouldn't suffice.
>
> That's an interesting deviation from the usual OoO problems.
>
> One thought is to maintain these bits in the in-order retirement unit.
> If multiple FP instructions are retired in a cycle, it's relatively
> easy to OR all their FP-exception bits and then or them with the bits
> up to now. This is also where control-flow exceptions (traps) are
> triggered; and if there are branch instructions that directly branch
> on these bits, this is where the predictions are checked.

The x87 FPSW also contains the 4 FP condition code bits
in addition to the pending exception status bits.
The condition bits are updated by overwrite however
and so amenable to renaming.

But ultimately they must merge with the overall FPSW in proper order.

>
> The only problem with this approach is an instruction that reads the
> FPSW; such an instruction would have to wait until it is retired (and
> therefore until all earlier instructions are retired) to produce its
> result for the OoO engine. If the result is the only used for a
> branch, that's not so bad, though: the branch prediction is also only
> checked when the branch is retired.
>
> - anton

Yes, doing this all at Retire is beating-it-with-a-blunt-object.
It works but its not very subtle as any FPSW register reads or writes
could have to drain the pipeline. Also delaying branch mispredict
detection until Retire wouldn't go over well.

It could have a separate circular buffer to which entries are added
in program order, that FP uOps output their status updates to,
and which drains at its own rate into a future copy of the
FPSW register might do the trick.

Kind of like a Load-Store Queue, this is an FP Status Queue.

This makes updates of the FPSW synchronous and in-order
but independent of the central instruction retire.
Branch mispredict rollback simply resets the queue head pointer
and essentially trims all mispredicted status updates.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> The implied OR of the uOp status with the current status
>>> creates a serial dependency that we'd need to break up.
>>
>> It's not really serial. OR is associative, so you can flatten the
>> evaluation sequence into an arbitrarily flat tree.
>
>The serialization comes in when FP instruction #1 has an
>FP overflow but its uOp exception mask has overflow disabled,
>and FP instruction #2 has no overflow but enables overflow exceptions.
>So overflow from #1 is thrown at #2.

You need to change the control word to change the exception mask, and
that may be a slow operation anyway. But ok, let's assume it is not
if you don't change the rounding mode. AFAIK what the masking bits do
is that they are ANDed with the actual exception bits before they are
ORed into the status word. No throwing going on, and no trapping
(control-flow exception), either. The naming of FP exceptions is
unfortunate; calling them flags would be more in line with computer
architecture terminology.

>> One thought is to maintain these bits in the in-order retirement unit.
>> If multiple FP instructions are retired in a cycle, it's relatively
>> easy to OR all their FP-exception bits and then or them with the bits
>> up to now. This is also where control-flow exceptions (traps) are
>> triggered; and if there are branch instructions that directly branch
>> on these bits, this is where the predictions are checked.
>
>The x87 FPSW also contains the 4 FP condition code bits
>in addition to the pending exception status bits.
>The condition bits are updated by overwrite however
>and so amenable to renaming.

Yes, or they could just be handled like the others.

>Yes, doing this all at Retire is beating-it-with-a-blunt-object.
>It works but its not very subtle as any FPSW register reads or writes
>could have to drain the pipeline.

Writes would just flow into the retirement unit and do their work
there, no draining necessary.

Reading would result in the user of the value waiting for the read-sw
instruction to retire, which may appear like a significant latency of
the read-sw instruction, but not as bad as draining.

>Also delaying branch mispredict
>detection until Retire wouldn't go over well.

I don't think that's a big problem.

1) Few branches depend on the FP status.

2) Branch predictors work very well these days.

3) How many cycles early can you resolve the branch misprediction
anyway?

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

On Sunday, April 10, 2022 at 11:58:05 AM UTC-5, EricP wrote:
> Anton Ertl wrote:
> > EricP <ThatWould...@thevillage.com> writes:
> >> The implied OR of the uOp status with the current status
> >> creates a serial dependency that we'd need to break up.
> >
> > It's not really serial. OR is associative, so you can flatten the
> > evaluation sequence into an arbitrarily flat tree.
> The serialization comes in when FP instruction #1 has an
> FP overflow but its uOp exception mask has overflow disabled,
> and FP instruction #2 has no overflow but enables overflow exceptions.
> So overflow from #1 is thrown at #2.
<
Exception IP points at instruction that did not cause FP exception
but at the instruction that re-enabled the acceptance of the already
raised exception. And thus is imprecise.
>
> Ultimately there is no way to avoid this imposition of
> program order on the update the the FP status word,
> though there are oppotunities to optimize this.
<
Such as an exception re-order-buffer--or a handful of bits in the
regular re-order buffer.
<
> >> It is not the same as the integer status flags because those
> >> flags overwrite the prior values so a rename can handle them.
> >>
> >> Whereas each FP exception bit has to OR with its prior state
> >> and then merge with that uOps exception mask bits to
> >> decide whether to throw and exception.
> >> So a simple renamer for the FPSW wouldn't suffice.
> >
> > That's an interesting deviation from the usual OoO problems.
> >
> > One thought is to maintain these bits in the in-order retirement unit.
> > If multiple FP instructions are retired in a cycle, it's relatively
> > easy to OR all their FP-exception bits and then or them with the bits
> > up to now. This is also where control-flow exceptions (traps) are
> > triggered; and if there are branch instructions that directly branch
> > on these bits, this is where the predictions are checked.
> The x87 FPSW also contains the 4 FP condition code bits
> in addition to the pending exception status bits.
> The condition bits are updated by overwrite however
> and so amenable to renaming.
<
The enabled flags are also amenable to renaming
And so are the accumulated flags--as long as they are updated in
program order as instructions retire. This causes a visible latency
effect when one reads the bits dependent upon retirement.
>
> But ultimately they must merge with the overall FPSW in proper order.
<
If one HAS a FPSW.
> >
> > The only problem with this approach is an instruction that reads the
> > FPSW; such an instruction would have to wait until it is retired (and
> > therefore until all earlier instructions are retired) to produce its
> > result for the OoO engine. If the result is the only used for a
> > branch, that's not so bad, though: the branch prediction is also only
> > checked when the branch is retired.
> >
> > - anton
> Yes, doing this all at Retire is beating-it-with-a-blunt-object.
<
That is how IEEE defined it. You take the good with the bad.
<
> It works but its not very subtle as any FPSW register reads or writes
> could have to drain the pipeline. Also delaying branch mispredict
> detection until Retire wouldn't go over well.
<
Prediction of the flags is rather easy, and one only has to be come
dependent when an instruction reads or writes the flags explicitly.
The vast majority of instructions do not, and so most codes do not
suffer.
>
> It could have a separate circular buffer to which entries are added
> in program order, that FP uOps output their status updates to,
> and which drains at its own rate into a future copy of the
> FPSW register might do the trick.
>
> Kind of like a Load-Store Queue, this is an FP Status Queue.
<
I always just lobbed this into the re-order buffer (or similar.)
>
> This makes updates of the FPSW synchronous and in-order
> but independent of the central instruction retire.
> Branch mispredict rollback simply resets the queue head pointer
> and essentially trims all mispredicted status updates.
<
Once again, brain dead easy to predict. Prediction may be dependent
on the current bit pattern in FPSW (if present).

On Sunday, April 10, 2022 at 2:53:32 AM UTC-6, Anton Ertl wrote:

> Anyway, my guess for the reason for slow precision-setting is that
> Intel and AMD microarchitects want the precision setting to be known
> to the decoder, so it can deliver the precision as part of the uop.

Well, of course they would want _that_.

So, clearly, it's my fault for being insufficiently familiar with x86
machine language... I knew that the x87 worked with a stack,
and it wasn't until much later that more sensible non-vector float
instructions were added to the architecture as part of a set of
vector extensions... but I did not realize that the x86 architecture
worked with generic floating-point instructions, and changed their
meaning by setting some precision register.

I had assumed, instead, that like all sensible machines, the x86
would have had a Multiply Floating instruction and a separate
Multiply Double instruction. And Multiply Quad and Multiply
Temporary Real too, if needed. So if we include integer math, we get
the following set of instructions: Add Byte, Add Halfword, Add,
Add Long, Add Floating, Add Double, Add Temporary Real, Add Quad.

But then, x86 isn't even big-endian, so I guess one can't really
expect it to closely hew to the standards set by the One
Sensible Architecture as was used in Incredibly Big
Machines.

John Savard

On Sunday, April 10, 2022 at 7:09:45 PM UTC-5, Quadibloc wrote:
> On Sunday, April 10, 2022 at 2:53:32 AM UTC-6, Anton Ertl wrote:
>
> > Anyway, my guess for the reason for slow precision-setting is that
> > Intel and AMD microarchitects want the precision setting to be known
> > to the decoder, so it can deliver the precision as part of the uop.
> Well, of course they would want _that_.
>
> So, clearly, it's my fault for being insufficiently familiar with x86
> machine language... I knew that the x87 worked with a stack,
> and it wasn't until much later that more sensible non-vector float
> instructions were added to the architecture as part of a set of
> vector extensions... but I did not realize that the x86 architecture
> worked with generic floating-point instructions, and changed their
> meaning by setting some precision register.
>
> I had assumed, instead, that like all sensible machines, the x86
> would have had a Multiply Floating instruction and a separate
> Multiply Double instruction. And Multiply Quad and Multiply
> Temporary Real too, if needed. So if we include integer math, we get
> the following set of instructions: Add Byte, Add Halfword, Add,
> Add Long, Add Floating, Add Double, Add Temporary Real, Add Quad.
>
> But then, x86 isn't even big-endian, so I guess one can't really
> expect it to closely hew to the standards set by the One
> Sensible Architecture as was used in Incredibly Big
> Machines.
<
I think this is the first time I have seen x86 and sensible in the same
sentence.
>
> John Savard

On Sunday, April 10, 2022 at 6:16:18 PM UTC-6, MitchAlsup wrote:
> On Sunday, April 10, 2022 at 7:09:45 PM UTC-5, Quadibloc wrote:

> > But then, x86 isn't even big-endian, so I guess one can't really
> > expect it to closely hew to the standards set by the One
> > Sensible Architecture as was used in Incredibly Big
> > Machines.

> I think this is the first time I have seen x86 and sensible in the same
> sentence.

Good one! But that would be in the direction of _agreement_ with my
point of view, with which you are no doubt *not* totally in agreement.
My point of view expressed here being: the x86 is _not_ sensible, but
the IBM System/360 not only _is_ sensible, but is the very paradigm
of a sensible computer architecture.

Or should we say, or sing, that it is the very _model_ of a...

John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:
>On Sunday, April 10, 2022 at 2:53:32 AM UTC-6, Anton Ertl wrote:
>
>> Anyway, my guess for the reason for slow precision-setting is that
>> Intel and AMD microarchitects want the precision setting to be known
>> to the decoder, so it can deliver the precision as part of the uop.
>
>Well, of course they would want _that_.
>
>So, clearly, it's my fault for being insufficiently familiar with x86
>machine language... I knew that the x87 worked with a stack,
>and it wasn't until much later that more sensible non-vector float
>instructions were added to the architecture as part of a set of
>vector extensions... but I did not realize that the x86 architecture
>worked with generic floating-point instructions, and changed their
>meaning by setting some precision register.

Concerning rounding modes, this approach has been standardized by
IEEE. For precision, the 8087 ff. took the same approach. I think
the idea was that you would use almost always use the 64-bit mantissa,
and only use precision control in exceptional circumstances.

>So if we include integer math, we get
>the following set of instructions: Add Byte, Add Halfword, Add,
>Add Long,

"Halfword" and "long" are terms with architecture-specific meanings
(if any), but I understand that you want to have add instructions for
different lengths. IA-32 and AMD64 have these, but the 8-bit and
16-bit variants require partial register updates, which cause
performance problems and require extra area for mitigating them.
AMD64 defined the 32-bit variant as zero-extending instruction (i.e.,
with a full-width result), which eliminated the partial-register
update problem. Load/Store architectures only have full-width ALU
operations. There is no advantage to partial-width operations and
little to extending variants. One issue is adding a sign- or
zero-extended 32-bit value to a 64-bit address (thanks to the I32LP64
(and IL32LLP64) brain-damage), and Aarch64 has addressing modes for
that; if you have sign- and zero-extending 32-bit adds, you don't need
these, but no architecture has both.

>But then, x86 isn't even big-endian, so I guess one can't really
>expect it to closely hew to the standards set by the One
>Sensible Architecture as was used in Incredibly Big
>Machines.

Maybe you should read about where the term "big-endian" comes from to
understand how ridiculous this statement is.

And given that we started with FP operations, you are probably the
only one (including everyone from IBM) who thinks that the S/360 is a
standard to be closely followed.

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

On 4/11/2022 12:02 AM, Anton Ertl wrote:
> Quadibloc <jsavard@ecn.ab.ca> writes:
>> On Sunday, April 10, 2022 at 2:53:32 AM UTC-6, Anton Ertl wrote:
>>
>>> Anyway, my guess for the reason for slow precision-setting is that
>>> Intel and AMD microarchitects want the precision setting to be known
>>> to the decoder, so it can deliver the precision as part of the uop.
>>
>> Well, of course they would want _that_.
>>
>> So, clearly, it's my fault for being insufficiently familiar with x86
>> machine language... I knew that the x87 worked with a stack,
>> and it wasn't until much later that more sensible non-vector float
>> instructions were added to the architecture as part of a set of
>> vector extensions... but I did not realize that the x86 architecture
>> worked with generic floating-point instructions, and changed their
>> meaning by setting some precision register.
>
> Concerning rounding modes, this approach has been standardized by
> IEEE. For precision, the 8087 ff. took the same approach. I think
> the idea was that you would use almost always use the 64-bit mantissa,
> and only use precision control in exceptional circumstances.
>
>> So if we include integer math, we get
>> the following set of instructions: Add Byte, Add Halfword, Add,
>> Add Long,
>
> "Halfword" and "long" are terms with architecture-specific meanings
> (if any), but I understand that you want to have add instructions for
> different lengths. IA-32 and AMD64 have these, but the 8-bit and
> 16-bit variants require partial register updates, which cause
> performance problems and require extra area for mitigating them.
> AMD64 defined the 32-bit variant as zero-extending instruction (i.e.,
> with a full-width result), which eliminated the partial-register
> update problem. Load/Store architectures only have full-width ALU
> operations. There is no advantage to partial-width operations and
> little to extending variants. One issue is adding a sign- or
> zero-extended 32-bit value to a 64-bit address (thanks to the I32LP64
> (and IL32LLP64) brain-damage), and Aarch64 has addressing modes for
> that; if you have sign- and zero-extending 32-bit adds, you don't need
> these, but no architecture has both.

While widening to a canonical integral width is widespread and is
blessed by C promotion rules, there are uses for exact-width integral
arithmetic: saturating arithmetic, excepting arithmetic that faults on
overflow, and wraparound semantics. Another issue is the disparity
between scalar (with widening semantics) and SIMD lane (with exact width
semantics) causing trouble in auto-vectorization.

These are admittedly specialized usages.

Quadibloc <jsavard@ecn.ab.ca> schrieb:

> My point of view expressed here being: the x86 is _not_ sensible, but
> the IBM System/360 not only _is_ sensible, but is the very paradigm
> of a sensible computer architecture.

Which is silly, unless your definition of sensible differs from
everybody else's. Floating point was a huge regression vs. the 704,
but there were also other criticsims. John Levine posted a list
recently, which I would have to dig up (using a register instead of
pc-relative adressing and the restriction to 4095 bytes for offsets
were among its faults).

They did groundbreaking work with the /360 design, but people
certainly have learned since then (and also from the mistakes they
made at the time).

Thomas Koenig wrote:
> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>
>> My point of view expressed here being: the x86 is _not_ sensible, but
>> the IBM System/360 not only _is_ sensible, but is the very paradigm
>> of a sensible computer architecture.
>
> Which is silly, unless your definition of sensible differs from
> everybody else's. Floating point was a huge regression vs. the 704,
> but there were also other criticsims. John Levine posted a list
> recently, which I would have to dig up (using a register instead of
> pc-relative adressing and the restriction to 4095 bytes for offsets
> were among its faults).
>
> They did groundbreaking work with the /360 design, but people
> certainly have learned since then (and also from the mistakes they
> made at the time).

It is realøatively easy to see the most major 360 mistakes:

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

Thomas Koenig wrote:
> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>
>> My point of view expressed here being: the x86 is _not_ sensible, but
>> the IBM System/360 not only _is_ sensible, but is the very paradigm
>> of a sensible computer architecture.
>
> Which is silly, unless your definition of sensible differs from
> everybody else's. Floating point was a huge regression vs. the 704,
> but there were also other criticsims. John Levine posted a list
> recently, which I would have to dig up (using a register instead of
> pc-relative adressing and the restriction to 4095 bytes for offsets
> were among its faults).
>
> They did groundbreaking work with the /360 design, but people
> certainly have learned since then (and also from the mistakes they
> made at the time).
>
It is easy to see that they did make several mistakes, not just the
12-bit max address offsets and the hex FP, just look at all the stuff
they have modified/added alternative options on later versions of the
architecture.

24-bit addressing which ignored the upper byte is probably the most
obvious of those, it caused a major flag day when they went to 31-bit.

OTOH, they have been extremely good at providing user program and mostly
also OS backwards compatibility, but 86 has been at least as good here.

Terje

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

On Monday, April 11, 2022 at 1:30:07 AM UTC-6, Anton Ertl wrote:

> And given that we started with FP operations, you are probably the
> only one (including everyone from IBM) who thinks that the S/360 is a
> standard to be closely followed.

Oh, it's true that not everything about it is perfect, and its floating-point
format is one of those things that is flawed. But having separate
instructions for each operand type, unless you're really tight for opcode
space, _is_ a very reasonable decision.

John Savard

On Monday, April 11, 2022 at 5:18:22 AM UTC-6, Terje Mathisen wrote:

> It is easy to see that they did make several mistakes, not just the
> 12-bit max address offsets and the hex FP, just look at all the stuff
> they have modified/added alternative options on later versions of the
> architecture.

Oh, yes. But I look at the half of the glass that is full, and find *that* to
be so far ahead of x86 that there is no comparison. I did not mean to
imply there was anything of value in the half of the glass that is empty.

John Savard

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Anton Ertl wrote:
>>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>>> The implied OR of the uOp status with the current status
>>>> creates a serial dependency that we'd need to break up.
>>> It's not really serial. OR is associative, so you can flatten the
>>> evaluation sequence into an arbitrarily flat tree.
>> The serialization comes in when FP instruction #1 has an
>> FP overflow but its uOp exception mask has overflow disabled,
>> and FP instruction #2 has no overflow but enables overflow exceptions.
>> So overflow from #1 is thrown at #2.
>
> You need to change the control word to change the exception mask, and
> that may be a slow operation anyway. But ok, let's assume it is not
> if you don't change the rounding mode.

The CW renaming allows all x87 control bits to change quickly.
Rounding bits would merge with the uOp on launch too.

SSE complicates its situation by putting the control bits and
status flags in the same MXCSR register rather than two.
The implication is that to change the rounding flags requires
reading MXCSR which requires syncing the the status flags.

> AFAIK what the masking bits do
> is that they are ANDed with the actual exception bits before they are
> ORed into the status word. No throwing going on, and no trapping
> (control-flow exception), either. The naming of FP exceptions is
> unfortunate; calling them flags would be more in line with computer
> architecture terminology.

The operation's status flags OR with the status register flags
and are written back to the status register.
Status register AND with the control word mask and if any
enabled bit is set then an exception generated at that point.

Note that unlike integer exceptions which do not modify the
destination register or integer status codes if they occur,
FP exceptions may or may not update the dest register with a
result or substitute a default alternative result,
and update the FP status word state before signalling
the exception at the point where it was detected,
depending on the condition detected.

>>> One thought is to maintain these bits in the in-order retirement unit.
>>> If multiple FP instructions are retired in a cycle, it's relatively
>>> easy to OR all their FP-exception bits and then or them with the bits
>>> up to now. This is also where control-flow exceptions (traps) are
>>> triggered; and if there are branch instructions that directly branch
>>> on these bits, this is where the predictions are checked.
>> The x87 FPSW also contains the 4 FP condition code bits
>> in addition to the pending exception status bits.
>> The condition bits are updated by overwrite however
>> and so amenable to renaming.
>
> Yes, or they could just be handled like the others.

If they are handled like others and the status word was updated
only at Retire it would cause FP conditional branch mispredict
detection to be delayed until Retire.

Which is why I'm singling then out as worthy of special handling.

>> Yes, doing this all at Retire is beating-it-with-a-blunt-object.
>> It works but its not very subtle as any FPSW register reads or writes
>> could have to drain the pipeline.
>
> Writes would just flow into the retirement unit and do their work
> there, no draining necessary.
>
> Reading would result in the user of the value waiting for the read-sw
> instruction to retire, which may appear like a significant latency of
> the read-sw instruction, but not as bad as draining.

Yes, and that's why I'm looking for ways to go faster than that.

Reading the status doesn't have to wait until retire if
it maintains a coherent "future" copy of the FPSW.
This future copy is coherent when all older FP instructions
have executed and applied their status to it.
Later Retire repeats the status updates to the Committed FPSW.

This allows the FP status word to be read or written ASAP
and not wait until older operations retire.

>> Also delaying branch mispredict
>> detection until Retire wouldn't go over well.
>
> I don't think that's a big problem.
>
> 1) Few branches depend on the FP status.
>
> 2) Branch predictors work very well these days.
>
> 3) How many cycles early can you resolve the branch misprediction
> anyway?

A large part of the branch mispredict handling, canceling of
younger in-flight instructions while keeping older ones,
and recovery of their resources.

This allows the wrong path to be trimmed and correct path
fetched, parsed and even executed long before the mispredicted
branch reaches Retire.

All that checkpoint and rollback logic is in place already for
integer branches so invoking it for FP is close to zero cost.

One question is whether it is worth doing similar optimization
for exceptions. I think that since exceptions are exceptional,
those can be left until Retire but with a prefetch of the handler
code into the Fetch buffer.
Note though that Mitch says the Motorola 88110 was doing this
optimization in 1992, 30 years ago.

MitchAlsup wrote:
> On Sunday, April 10, 2022 at 11:58:05 AM UTC-5, EricP wrote:
>> Anton Ertl wrote:
>>> EricP <ThatWould...@thevillage.com> writes:
>>>> The implied OR of the uOp status with the current status
>>>> creates a serial dependency that we'd need to break up.
>>> It's not really serial. OR is associative, so you can flatten the
>>> evaluation sequence into an arbitrarily flat tree.
>> The serialization comes in when FP instruction #1 has an
>> FP overflow but its uOp exception mask has overflow disabled,
>> and FP instruction #2 has no overflow but enables overflow exceptions.
>> So overflow from #1 is thrown at #2.
> <
> Exception IP points at instruction that did not cause FP exception
> but at the instruction that re-enabled the acceptance of the already
> raised exception. And thus is imprecise.

No, it is precise. The registers are updated for all instructions
before the exception point and none after. That is precise.

The difference for FP exceptions is that the definition of when they
are detected is different. Also, depending on the condition detected,
dest registers may or may not have been updated for the excepting operation.

Also x87 exceptions are signalled at the next WAIT/FWAIT.
The x87 "last instruction pointer" register is the faulting instruction.
The exception handler RIP is the FWAIT.

SSE exceptions are synchronous with the unmasked generating operation.

>> Ultimately there is no way to avoid this imposition of
>> program order on the update the the FP status word,
>> though there are oppotunities to optimize this.
> <
> Such as an exception re-order-buffer--or a handful of bits in the
> regular re-order buffer.
> <
>>>> It is not the same as the integer status flags because those
>>>> flags overwrite the prior values so a rename can handle them.
>>>>
>>>> Whereas each FP exception bit has to OR with its prior state
>>>> and then merge with that uOps exception mask bits to
>>>> decide whether to throw and exception.
>>>> So a simple renamer for the FPSW wouldn't suffice.
>>> That's an interesting deviation from the usual OoO problems.
>>>
>>> One thought is to maintain these bits in the in-order retirement unit.
>>> If multiple FP instructions are retired in a cycle, it's relatively
>>> easy to OR all their FP-exception bits and then or them with the bits
>>> up to now. This is also where control-flow exceptions (traps) are
>>> triggered; and if there are branch instructions that directly branch
>>> on these bits, this is where the predictions are checked.
>> The x87 FPSW also contains the 4 FP condition code bits
>> in addition to the pending exception status bits.
>> The condition bits are updated by overwrite however
>> and so amenable to renaming.
> <
> The enabled flags are also amenable to renaming
> And so are the accumulated flags--as long as they are updated in
> program order as instructions retire. This causes a visible latency
> effect when one reads the bits dependent upon retirement.

Yes, and since this is a "go as fast as possible" scenario
I am looking for ways to optimize that so the FPSW can be
calculated earlier than waiting until Retire.

>> But ultimately they must merge with the overall FPSW in proper order.
> <
> If one HAS a FPSW.

Doesn't IEEE-754 require the sticky exception flags?

>>> The only problem with this approach is an instruction that reads the
>>> FPSW; such an instruction would have to wait until it is retired (and
>>> therefore until all earlier instructions are retired) to produce its
>>> result for the OoO engine. If the result is the only used for a
>>> branch, that's not so bad, though: the branch prediction is also only
>>> checked when the branch is retired.
>>>
>>> - anton
>> Yes, doing this all at Retire is beating-it-with-a-blunt-object.
> <
> That is how IEEE defined it. You take the good with the bad.

Right, but the challenge here is to go as fast as possible.

Also looking at SSE they seem to make their situation worse by
having one combined control and status register instead of two.
That looks to my eye like a serious design error as it requires
a sync with the status flags in order to read the control bits,
causing a partial pipeline drain.

> <
>> It works but its not very subtle as any FPSW register reads or writes
>> could have to drain the pipeline. Also delaying branch mispredict
>> detection until Retire wouldn't go over well.
> <
> Prediction of the flags is rather easy, and one only has to be come
> dependent when an instruction reads or writes the flags explicitly.
> The vast majority of instructions do not, and so most codes do not
> suffer.
>> It could have a separate circular buffer to which entries are added
>> in program order, that FP uOps output their status updates to,
>> and which drains at its own rate into a future copy of the
>> FPSW register might do the trick.
>>
>> Kind of like a Load-Store Queue, this is an FP Status Queue.
> <
> I always just lobbed this into the re-order buffer (or similar.)

That too. This maintains a future FPSW for early reads and writes
of that register. A Committed FPSW is updated at Retire too.

>> This makes updates of the FPSW synchronous and in-order
>> but independent of the central instruction retire.
>> Branch mispredict rollback simply resets the queue head pointer
>> and essentially trims all mispredicted status updates.
> <
> Once again, brain dead easy to predict. Prediction may be dependent
> on the current bit pattern in FPSW (if present).

It doesn't need to predict the status flags
but it would be nice to read the FPSW ASAP.

On Monday, April 11, 2022 at 2:18:22 PM UTC+3, Terje Mathisen wrote:
> Thomas Koenig wrote:
> > Quadibloc <jsa...@ecn.ab.ca> schrieb:
> >
> >> My point of view expressed here being: the x86 is _not_ sensible, but
> >> the IBM System/360 not only _is_ sensible, but is the very paradigm
> >> of a sensible computer architecture.
> >
> > Which is silly, unless your definition of sensible differs from
> > everybody else's. Floating point was a huge regression vs. the 704,
> > but there were also other criticsims. John Levine posted a list
> > recently, which I would have to dig up (using a register instead of
> > pc-relative adressing and the restriction to 4095 bytes for offsets
> > were among its faults).
> >
> > They did groundbreaking work with the /360 design, but people
> > certainly have learned since then (and also from the mistakes they
> > made at the time).
> >
> It is easy to see that they did make several mistakes, not just the
> 12-bit max address offsets and the hex FP, just look at all the stuff
> they have modified/added alternative options on later versions of the
> architecture.
>
> 24-bit addressing which ignored the upper byte is probably the most
> obvious of those, it caused a major flag day when they went to 31-bit.
>
> OTOH, they have been extremely good at providing user program and mostly
> also OS backwards compatibility, but 86 has been at least as good here.
>
> Terje
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

IMHO, S/360 major mistake has nothing to do with details of the ISA.

The major mistake was a managerial decision to never enter a mass market.
Probably, at any given point in time it looked perfectly reasonable, because
at any given point entering a mass market would mean cannibalizing nearly
all mid-range sails and adversely affecting a high end. And at short time
scale a profit, gained at mass market, wouldn't fully compensate for the
profit lost at higher end.
But without entering a mass market it inevitably ended up where it ended up,
i.e. architecture exists and implementations are even pretty good and even
quite competitive if we ignore a price tag. But it is completely irrelevant in
the Grand Scheme of Things. And, given a circumstances it's still relatively
good outcome. It could have been worse, much worse.

From technical point of view, the most suitable point for expansion of
S/360 into mass market was in the 1994. 9672 family that was introduced
in this year was the first S/360-compatible CPU suitable for cheap
manufacturing and for a deskside and may be even desktop format.
For the first few years is sucked performance-wise, but considering
potential iternal opposition to such step, it was not necessarily a bad property.

I find it ironical that it happened (that is, it happened to not happen) during the
early stage of the reign of Lou Gerstner, who is commonly considered as one
of the best CEOs in the history of IBM.

Michael S <already5chosen@yahoo.com> schrieb:

> IMHO, S/360 major mistake has nothing to do with details of the ISA.
>
> The major mistake was a managerial decision to never enter a mass market.
> Probably, at any given point in time it looked perfectly reasonable, because
> at any given point entering a mass market would mean cannibalizing nearly
> all mid-range sails and adversely affecting a high end. And at short time
> scale a profit, gained at mass market, wouldn't fully compensate for the
> profit lost at higher end.

How could it have succeeded?

The mass market didn't need doing what the S/360 ff. architecture was
good at doing - doing established commercial applications for large
companies doing lots of I/O.

(German Wikipedia tells me of a 68000-360 which had S/360 microcode, I'm
not sure if I believe that).

> But without entering a mass market it inevitably ended up where it ended up,
> i.e. architecture exists and implementations are even pretty good and even
> quite competitive if we ignore a price tag. But it is completely irrelevant in
> the Grand Scheme of Things. And, given a circumstances it's still relatively
> good outcome. It could have been worse, much worse.
>
> From technical point of view, the most suitable point for expansion of
> S/360 into mass market was in the 1994. 9672 family that was introduced
> in this year was the first S/360-compatible CPU suitable for cheap
> manufacturing and for a deskside and may be even desktop format.
> For the first few years is sucked performance-wise, but considering
> potential iternal opposition to such step, it was not necessarily a bad property.

Look at what was already available in 1994. The minis were
almost dead, RISC ruled the workstation market, and the VAX 7000
vs Alpha comparison had shown that, given the technology of the
day, CISC was not the way to compete for raw computing power.
And Intel had already launched the Pentium. Plus, IBM was busy
selling high-performance RS/6000 workstations at the time.

All the people who were using PCs as a hobby, for gaming for for
business purposes had no IBM software to entice them to run
a /360 compatible computer.

Plus, the operating systems that IBM was offering were... arcane,
to say the least. Which private person or small company could
have administered an MVS system?

> I find it ironical that it happened (that is, it happened to not happen) during the
> early stage of the reign of Lou Gerstner, who is commonly considered as one
> of the best CEOs in the history of IBM.

If IBM would have wanted to push the /360, they should have done so
much easier - trying to go into the mini market. But I doubt they
could have compteded with the Data General Nova on price/performance
ratio with all that excess baggage they were carrying.

The 801, now...

In article <t31mgs$8s1$1@newsreader4.netcologne.de>,
tkoenig@netcologne.de (Thomas Koenig) wrote:

> (German Wikipedia tells me of a 68000-360 which had S/360
> microcode, I'm not sure if I believe that).

It existed, but was not generally available. It was the core of
<https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compatible_systems#P
ersonal_Computer_XT/370>

John

Thomas Koenig wrote:
> Michael S <already5chosen@yahoo.com> schrieb:
>
>> IMHO, S/360 major mistake has nothing to do with details of the ISA.
>>
>> The major mistake was a managerial decision to never enter a mass market.
>> Probably, at any given point in time it looked perfectly reasonable, because
>> at any given point entering a mass market would mean cannibalizing nearly
>> all mid-range sails and adversely affecting a high end. And at short time
>> scale a profit, gained at mass market, wouldn't fully compensate for the
>> profit lost at higher end.
>
> How could it have succeeded?
>
> The mass market didn't need doing what the S/360 ff. architecture was
> good at doing - doing established commercial applications for large
> companies doing lots of I/O.
>
> (German Wikipedia tells me of a 68000-360 which had S/360 microcode, I'm
> not sure if I believe that).

Why not?

It did in fact exist, afaik it delivered pretty bad performance but did
work for sw development.

Terje

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

On Sunday, April 10, 2022 at 11:53:32 AM UTC+3, Anton Ertl wrote:
> Quadibloc <jsa...@ecn.ab.ca> writes:
> >You have heard the crazy way *I* would have designed a processor. With separate
> >pipelines for single precision and double precision and quad precision and one-and-a-half
> >precision.
> >
> >But if one were to put a 60-bit floating-point number down the double precision pipeline,
> >no, one would not have to drain it to change the mode. (The double precision pipeline
> >would actually be designed for 72-bit floats, which would also use it. 80 bit temporary
> >reals would go down the double precision pipeline, unless there was one for 96-bit
> >floats.)
> >
> >So mixing precisions would make your programs go *faster*, because it would utilize
> >the other pipelines that otherwise would not be used. The very opposite of Intel!
> In the last weeks I have noticed unusually many people posting
> over-long lines (i.e., longer than 80 chars, and ideally you should
> limit the lines to 70-72 chars to leave room for quoting). Is there
> some new attack on Usenet conventions coming out from Google?
>
> Anyway, my guess for the reason for slow precision-setting

I want to add just a little bit of facts to the nice theoretical discussion
about horrible slowness of changing of x87 precision.

uint64_t t0 = __rdtsc();
for (int i = 0; i < nIter; ++i) {
#ifdef LDCW_SQRTQ
unsigned short cw;
_FPU_GETCW(cw);
unsigned short new_cw = cw | _FPU_EXTENDED;
_FPU_SETCW(new_cw);
#endif
xbuf[i] = sqrtq(xbuf[i]);
#ifdef LDCW_SQRTQ
_FPU_SETCW(cw);
#endif
}
uint64_t t1 = __rdtsc();

When LDCW_SQRTQ is undefined the loop runs at 587 base clocks per iteration.
When LDCW_SQRTQ is undefined it runs at 595 base clocks per iteration.

So 8 clocks for save/modify/restore in tight loop.
Probably, 5-6 clocks in less tight loops.

Processor: Zen3.

> is that
> Intel and AMD microarchitects want the precision setting to be known
> to the decoder, so it can deliver the precision as part of the uop.
> This requires that when setting the precision, decoding of subsequent
> instructions starts from scratch. An alternative would be to deliver
> the precision as another input in the OoO engine, but that would
> require additional resources in the OoO engine, an apparently they
> thought that spending these resources elsewhere would buy more
> performance.
>
> Concerning your separate-pipelines idea, in that setup it's even more
> advantageous to know the precision early in instruction processing:
> You can have separate queues/ports for the different precisions and
> steer the instructions to these ports early, instead of having common
> FP queues, and steering the instructions to the right pipelines only
> when all the data (including precision) is in; ok, you could also have
> two stages of queues, but that introduces additional complication,
> area, and probably latency.
>
> Also, even if switching is fast, how frequent is code with mixed
> precision? E.g., in DGEMM you only use double precision operations,
> while in SGEMM you only use single-precision operations.
>
> Bottom line: There's a reason why Intel and AMD are designing their
> CPUs the way they are.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Monday, April 11, 2022 at 9:30:56 PM UTC+3, Michael S wrote:
> On Sunday, April 10, 2022 at 11:53:32 AM UTC+3, Anton Ertl wrote:
> > Quadibloc <jsa...@ecn.ab.ca> writes:
> > >You have heard the crazy way *I* would have designed a processor. With separate
> > >pipelines for single precision and double precision and quad precision and one-and-a-half
> > >precision.
> > >
> > >But if one were to put a 60-bit floating-point number down the double precision pipeline,
> > >no, one would not have to drain it to change the mode. (The double precision pipeline
> > >would actually be designed for 72-bit floats, which would also use it. 80 bit temporary
> > >reals would go down the double precision pipeline, unless there was one for 96-bit
> > >floats.)
> > >
> > >So mixing precisions would make your programs go *faster*, because it would utilize
> > >the other pipelines that otherwise would not be used. The very opposite of Intel!
> > In the last weeks I have noticed unusually many people posting
> > over-long lines (i.e., longer than 80 chars, and ideally you should
> > limit the lines to 70-72 chars to leave room for quoting). Is there
> > some new attack on Usenet conventions coming out from Google?
> >
> > Anyway, my guess for the reason for slow precision-setting
> I want to add just a little bit of facts to the nice theoretical discussion
> about horrible slowness of changing of x87 precision.
>
> uint64_t t0 = __rdtsc();
> for (int i = 0; i < nIter; ++i) {
> #ifdef LDCW_SQRTQ
> unsigned short cw;
> _FPU_GETCW(cw);
> unsigned short new_cw = cw | _FPU_EXTENDED;
> _FPU_SETCW(new_cw);
> #endif
> xbuf[i] = sqrtq(xbuf[i]);
> #ifdef LDCW_SQRTQ
> _FPU_SETCW(cw);
> #endif
> }
> uint64_t t1 = __rdtsc();
>
>
> When LDCW_SQRTQ is undefined the loop runs at 587 base clocks per iteration.
> When LDCW_SQRTQ is undefined it runs at 595 base clocks per iteration.

Please read:
When LDCW_SQRTQ is defined it runs at 595 base clocks per iteration.

>
> So 8 clocks for save/modify/restore in tight loop.
> Probably, 5-6 clocks in less tight loops.
>
> Processor: Zen3.
> > is that
> > Intel and AMD microarchitects want the precision setting to be known
> > to the decoder, so it can deliver the precision as part of the uop.
> > This requires that when setting the precision, decoding of subsequent
> > instructions starts from scratch. An alternative would be to deliver
> > the precision as another input in the OoO engine, but that would
> > require additional resources in the OoO engine, an apparently they
> > thought that spending these resources elsewhere would buy more
> > performance.
> >
> > Concerning your separate-pipelines idea, in that setup it's even more
> > advantageous to know the precision early in instruction processing:
> > You can have separate queues/ports for the different precisions and
> > steer the instructions to these ports early, instead of having common
> > FP queues, and steering the instructions to the right pipelines only
> > when all the data (including precision) is in; ok, you could also have
> > two stages of queues, but that introduces additional complication,
> > area, and probably latency.
> >
> > Also, even if switching is fast, how frequent is code with mixed
> > precision? E.g., in DGEMM you only use double precision operations,
> > while in SGEMM you only use single-precision operations.
> >
> > Bottom line: There's a reason why Intel and AMD are designing their
> > CPUs the way they are.
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Monday, April 11, 2022 at 12:37:57 AM UTC-5, Quadibloc wrote:
> On Sunday, April 10, 2022 at 6:16:18 PM UTC-6, MitchAlsup wrote:
> > On Sunday, April 10, 2022 at 7:09:45 PM UTC-5, Quadibloc wrote:
>
> > > But then, x86 isn't even big-endian, so I guess one can't really
> > > expect it to closely hew to the standards set by the One
> > > Sensible Architecture as was used in Incredibly Big
> > > Machines.
>
> > I think this is the first time I have seen x86 and sensible in the same
> > sentence.
> Good one! But that would be in the direction of _agreement_ with my
> point of view, with which you are no doubt *not* totally in agreement.
> My point of view expressed here being: the x86 is _not_ sensible, but
> the IBM System/360 not only _is_ sensible, but is the very paradigm
> of a sensible computer architecture.
<
I would say IBM 360 was a sensible architecture at the time of its
creation. I am not so sure what it has morphed into remains so.
>
> Or should we say, or sing, that it is the very _model_ of a...
>
> John Savard

On Monday, April 11, 2022 at 2:30:07 AM UTC-5, Anton Ertl wrote:
> Quadibloc <jsa...@ecn.ab.ca> writes:
> >On Sunday, April 10, 2022 at 2:53:32 AM UTC-6, Anton Ertl wrote:
> >
> >> Anyway, my guess for the reason for slow precision-setting is that
> >> Intel and AMD microarchitects want the precision setting to be known
> >> to the decoder, so it can deliver the precision as part of the uop.
> >
> >Well, of course they would want _that_.
> >
> >So, clearly, it's my fault for being insufficiently familiar with x86
> >machine language... I knew that the x87 worked with a stack,
> >and it wasn't until much later that more sensible non-vector float
> >instructions were added to the architecture as part of a set of
> >vector extensions... but I did not realize that the x86 architecture
> >worked with generic floating-point instructions, and changed their
> >meaning by setting some precision register.
> Concerning rounding modes, this approach has been standardized by
> IEEE. For precision, the 8087 ff. took the same approach. I think
> the idea was that you would use almost always use the 64-bit mantissa,
> and only use precision control in exceptional circumstances.
> >So if we include integer math, we get
> >the following set of instructions: Add Byte, Add Halfword, Add,
> >Add Long,
<
> "Halfword" and "long" are terms with architecture-specific meanings
> (if any), but I understand that you want to have add instructions for
> different lengths. IA-32 and AMD64 have these, but the 8-bit and
> 16-bit variants require partial register updates, which cause
> performance problems and require extra area for mitigating them.
> AMD64 defined the 32-bit variant as zero-extending instruction (i.e.,
> with a full-width result), which eliminated the partial-register
> update problem. Load/Store architectures only have full-width ALU
> operations. There is no advantage to partial-width operations and
<
Partial width calculations--there will always remain the need for partial
width memory references (which are operations)
<
> little to extending variants. One issue is adding a sign- or
> zero-extended 32-bit value to a 64-bit address (thanks to the I32LP64
> (and IL32LLP64) brain-damage), and Aarch64 has addressing modes for
> that; if you have sign- and zero-extending 32-bit adds, you don't need
> these, but no architecture has both.
> >But then, x86 isn't even big-endian, so I guess one can't really
> >expect it to closely hew to the standards set by the One
> >Sensible Architecture as was used in Incredibly Big
> >Machines.
> Maybe you should read about where the term "big-endian" comes from to
> understand how ridiculous this statement is.
>
> And given that we started with FP operations, you are probably the
> only one (including everyone from IBM) who thinks that the S/360 is a
> standard to be closely followed.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>