On Friday, March 18, 2022 at 2:16:36 PM UTC-6, Quadibloc wrote:

> There is cost, and then there is value.

And on reading up a bit more about this, I can see now what
the big problem with imprecise interrupts is.

Once your computer has a swap file - virtual memory - you
have to be able to recover from a page fault. So that interrupt
has to be precise.

Maybe there is an alternative. Instead of retrying the failed
instruction after the interrupt is serviced, the interrupt service
routine could use a special instruction to feed the memory access
into the saved complicated pipeline state. That would avoid the
2% - 3% performance cost of having precise interrupts given by
the paper I saw this in.

John Savard

On Friday, March 18, 2022 at 3:16:36 PM UTC-5, Quadibloc wrote:
> On Friday, March 18, 2022 at 12:43:53 PM UTC-6, MitchAlsup wrote:
>
> > It costs far less to satisfy the denorm problem in the FPU than it cost to solve
> > the precise exception problem when taking exceptions. Far far less. Yet you
> > would never accept the later.
> There is cost, and then there is value.
>
> People mistakenly believe that solving the denomals problem in
> IEEE 754 floating-point has a significant cost, and so they're
> against bothering because computers got along fine for years
> without denormals.
>
> But exceptions were always precise before IBM came up with
> the Tomasulo algorithm and the Model 91. (Actually, not quite:
> the 6600 had imprecise interrupts too.) So this was a _change_
> that deprived people of something they were used to, and didn't
> have any idea of how to do without.
<
CDC 6600 had NO exceptions other than touching memory outside
of base and bounds. Calculation exceptions created results much
like IEEE overflowing to infinities, underflowing to zeros, integer
wrapping (1-s complement),...
<
Also note the CDC 6600 did not respond to interrupts. The peripheral
processors responded to interrupts, performed I/O data movement,
did CPU scheduling, and when they new what was next to run, the PPs
kicked the CPU in the shin and made it execute an exchange jump
instruction. 10-cycles later you were running a new thread in a new
context.
<
Moral: the CPU does not have to be the one that responds to
interrupts.
>
> Initially, the Model 91 didn't have precise exceptions; the manual
> explained that there was this limitation of the machine compared
> to others.
>
> Incidentally, on a page about the history of this computer, I saw
> this quote from a memo at SLAC: "The Model 91 designers have
> provided a switch that puts the machine into non-overlapped
> mode, in which it runs at about Model 75 speed but with precise
> interrupts. This switch will be important for program debugging,
> and it can be set and reset by programming."
<
I thought that was the /195
>
> This was cheaper than providing precise interrupts and out-of-order
> operation at the same time; a similar feature on modern machines
> might be useful as a Spectre mitigation - let only the untrusted
> code run slower, trusted code doesn't need it.
<
Trusted code does not need it only if you can prevent RoP attacks.
>
> But the Model 91 was a usable computer as it was. So it is
> possible to have a computer capable of doing useful work, with
> I/O done by interrupts, even if the interrupts are imprecise.
>
> Actually, _that_ makes sense. Interrupts to service I/O should be
> totally invisible to the programs that are running concurrently.
<
Even if you interrupt it early, or let the whole pipeline drain, interrupts
are still precise.
<
It always amused me that CPU designers would go to great lengths
to transfer control to SW on an interrupt in as few cycles as possible
(as low as 5-cycles on some RISC machines) and then spend 50-100
cycles saving state before SW could get to the code to fix why control
arrived here.
<
> So they shouldn't mess with them in any way. So it doesn't matter
> if the interrupt happens after an instruction, or in the middle of
> a complicated pipeline state, since as far as the running user mode
> programs are concerned, the interrupt could have been serviced by
> another core.
>
> It's when _traps_ are imprecise, like a divide by zero error, that it's
> a pain; now, the program has no choice but to fail, while with
> precise traps, the interrupt handler could include a customized
> fixup, and set the program to running again.
<
OK
<
You have used the words "exception", "interrupt" and "trap" almost interchangeably.
They are not (and they are) depending on where inside the machine you look.
<
Exception is caused by an instruction which cannot be completed.
Trap is caused by an instruction doing exactly what it is supposed to do.
Interrupt is a call for help asynchronous to the program at hand.
<
Mc 88100 had imprecise precise exceptions. When an exception occurred
enough state was latched to unload the machine, figure out what was going
on, fix the issues, and continue. But it did not have the 1 PC pointing at the
1 instruction which caused the 1 exception, it had the PC pointing at the next
instruction to execute after you fixed everything.
<
When control arrived at exception handler, it could unload up to 5 problems.
It would them go about fixing all pending problems, and then it could get on
with running code.
<
EVEN without the 1 PC pointing at the 1 instruction which ultimately caused
1 exception control transfer, or backing up the machine to become precise.
It ran DG UNIX "just fine".
<
The only applications which had issues were those that assumed that there
was 1 PC, 1 instruction, 1 exception, and long jumped out of signal handler
instead of returning to OS to see if there was another exception pending.
>
> John Savard

On Friday, March 18, 2022 at 3:33:33 PM UTC-5, Quadibloc wrote:
> On Friday, March 18, 2022 at 2:16:36 PM UTC-6, Quadibloc wrote:
>
> > There is cost, and then there is value.
> And on reading up a bit more about this, I can see now what
> the big problem with imprecise interrupts is.
>
> Once your computer has a swap file - virtual memory - you
> have to be able to recover from a page fault. So that interrupt
> has to be precise.
<
Not the kind of precision you think it needs; much less.
>
> Maybe there is an alternative. Instead of retrying the failed
> instruction after the interrupt is serviced, the interrupt service
> routine could use a special instruction to feed the memory access
> into the saved complicated pipeline state. That would avoid the
> 2% - 3% performance cost of having precise interrupts given by
> the paper I saw this in.
<
You can use the "completion" model or the "retry" model.
<
In the completion model, the exception handler performs the instruction
updates state of thread (registers and memory) and returns after the
excepting instruction.
<
In the retry model, you fix one thing, try again, take another exception, fix
that , try again, until you have fixed everything about the instruction
and make forward progress again.
<
Both models work, the completion model does not need the precision
that people think they need, and can deal with k exceptions, interrupts,
traps rather than just 1. This is a lot like a file system that sends out
disk requests and gets sectors returned in a different order than their
requests went out.
>
> John Savard

On 18 Mar 2022, Quadibloc wrote
(in article<3d95c40a-41c8-48db-a983-98a2fc066023n@googlegroups.com>):

> But exceptions were always precise before IBM came up with
> the Tomasulo algorithm and the Model 91. (Actually, not quite:
> the 6600 had imprecise interrupts too.)
The KDF9 beat the 6600 by about 6 months.

--
Bill Findlay

According to Quadibloc <jsavard@ecn.ab.ca>:
>Initially, the Model 91 didn't have precise exceptions; the manual
>explained that there was this limitation of the machine compared
>to others.
>
>Incidentally, on a page about the history of this computer, I saw
>this quote from a memo at SLAC: "The Model 91 designers have
>provided a switch that puts the machine into non-overlapped
>mode, in which it runs at about Model 75 speed but with precise
>interrupts. This switch will be important for program debugging,
>and it can be set and reset by programming."

There was no such switch on the /91 although the manual says there
was one on the /195. You had to restart the machine to turn it on
or off so I doubt it was used much.

On both machines there was a variety of no-op that waited for all
previous instructions to finish that you could use to get the effect
of a precise interrupt. I believe there was an option in the PL/I
compiler to generate them.

Having spent a summer working on Fortran programs on a 360/91 I
can say that the imprecise interrupts were annoying but not all
that hard to deal with. You'd look at the dump, figure out
what failed, and adjust the program either to check the data
or rearrange it so the fault wouldn't happen.

--
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 Friday, March 18, 2022 at 7:27:33 PM UTC-6, John Levine wrote:

> On both machines there was a variety of no-op that waited for all
> previous instructions to finish

Yes, there was, I saw that in my search to confirm the 91's interrupts
were imprecise.

> that you could use to get the effect
> of a precise interrupt.

No. Because while you could indeed use that instruction to get
an interrupt after an instruction, instead of an interrupt in the middle
of a complicated pipeline state with many instructions in flight, the
instruction you interrupted at wouldn't be the _right_ instruction.

If there was an interrupt because of a memory access instruction
having a page fault, you need *that instruction* to be pointed to by
the return address. The no-op would flush all instructions in the
pipeline when the interrupt happened, so your return address would
be several instructions later.

The same problem arises if you want to fix an arithmetic underflow,
or simulate an additional instruction when an unimplemented opcode
is hit.

John Savard

On Friday, March 18, 2022 at 3:09:33 PM UTC-6, MitchAlsup wrote:
> On Friday, March 18, 2022 at 3:16:36 PM UTC-5, Quadibloc wrote:

> > This was cheaper than providing precise interrupts and out-of-order
> > operation at the same time; a similar feature on modern machines
> > might be useful as a Spectre mitigation - let only the untrusted
> > code run slower, trusted code doesn't need it.

> Trusted code does not need it only if you can prevent RoP attacks.

It is true that if one wishes to be serious about security, on a system
where all kinds of attacks are possible against the operating system,
it's better to mitigate Spectre everywhere you can.

Basically, though, if your operating system _were_ so good that
Spectre was the *only thing* that let anyone attack it, then if you
prevented untrusted code from making use of Spectre, then there
would be no attack vectors with which untrusted code could
masquerade as trusted code.

But in the real world, surely that's never true?

That may be. But if the required mitigations come with a _heavy
performance cost_ and the system is performance-critical and
cost-critical, this lower level of security, combined with a better-quality
operating system and alert and trained users, may be appropriate.

Also, another possibility is: use the best mitigations possible that
come with a "reasonable" performance cost all the time - but use
a 'perfect' mitigation - running the system in 486 mode - that has
a heavy performance cost for untrusted code only. If Spectre _is_
the major security hole in the system, and attackers _are_ exploiting
forms of the attack that can't be mitigated without excessive performance
cost, what other choice is there?

John Savard

On Friday, March 18, 2022 at 11:17:16 PM UTC-5, Quadibloc wrote:
> On Friday, March 18, 2022 at 3:09:33 PM UTC-6, MitchAlsup wrote:
> > On Friday, March 18, 2022 at 3:16:36 PM UTC-5, Quadibloc wrote:
>
> > > This was cheaper than providing precise interrupts and out-of-order
> > > operation at the same time; a similar feature on modern machines
> > > might be useful as a Spectre mitigation - let only the untrusted
> > > code run slower, trusted code doesn't need it.
>
> > Trusted code does not need it only if you can prevent RoP attacks.
> It is true that if one wishes to be serious about security, on a system
> where all kinds of attacks are possible against the operating system,
> it's better to mitigate Spectre everywhere you can.
<
Yes,
>
> Basically, though, if your operating system _were_ so good that
> Spectre was the *only thing* that let anyone attack it, then if you
> prevented untrusted code from making use of Spectre, then there
> would be no attack vectors with which untrusted code could
> masquerade as trusted code.
>
> But in the real world, surely that's never true?
>
> That may be. But if the required mitigations come with a _heavy
> performance cost_ and the system is performance-critical and
> cost-critical, this lower level of security, combined with a better-quality
> operating system and alert and trained users, may be appropriate.
<
What if the mitigations do not bear such a heavy cost; say on the
order of 1%.......
>
> Also, another possibility is: use the best mitigations possible that
> come with a "reasonable" performance cost all the time - but use
> a 'perfect' mitigation - running the system in 486 mode - that has
> a heavy performance cost for untrusted code only. If Spectre _is_
> the major security hole in the system, and attackers _are_ exploiting
> forms of the attack that can't be mitigated without excessive performance
> cost, what other choice is there?
<
Build machines that are immune from Spectré.
>
> John Savard

MitchAlsup <MitchAlsup@aol.com> wrote:
> On Thursday, March 17, 2022 at 8:24:14 PM UTC-5, anti...@math.uni.wroc.pl wrote:
> > Quadibloc <jsa...@ecn.ab.ca> wrote:
> > > On Wednesday, January 26, 2022 at 12:05:13 AM UTC-7, Thomas Koenig wrote:
> > >
> > > > I especially like the sentence
> > > >
> > > > DEC?s main advocate on the IEEE p754 Committee was a Mathematician
> > > > and Numerical Analyst Dr. Mary H. Payne. She was experienced,
> > > > fully competent,
> > > >
> > > > and misled by DEC?s hardware engineers
> > > >
> > > > when they assured her that Gradual Underflow was unimplementable
> > > > as the default (no trap) of any computer arithmetic aspiring to
> > > > high performance.
> > >
> > > That is true, but, although I may be mistaken, it appeared to me that
> > > while one certainly _could_ have a high-performance floating-point
> > > implementation which fully supported IEEE 754 gradual underflow,
> > >
> > > one would have to do it by representing floating-point numbers in an
> > > "internal form" when they're in registers, like the way the 8087 did it,
> > > where the internal form was like an old-style plain floating-point format,
> > > but with a range larger than the architectural floating-point format, so
> > > that it covered all the gradual underflow territory.
> > >
> > > And, of course, if you do it that way, you can't properly and accurately
> > > trap when a register-to-register calculation underflows, because that isn't
> > > easily visible any longer. Instead, you find out when you store the result
> > > in memory.
> >
> > Well, "internal format" really means one extra exponent bit.
> > Detecting underflow with such format does not present extra
> > difficulty. Real problem is that one has to properly round
> > result so that it does not have more accuracy than allowed
> > by denormal representation. AFAICS rounding after addition
> > does not present problem. But rounding after multiplication
> > of division may be problematic, basically instead of rounding
> > in fixed binary position one need rounding at variable position.
> >
> > > So if you _exclude_ the idea of doing calculations on an internal form
> > > of numbers, because it's problematic, then indeed gradual underflow will
> > > obstruct high performance.
> >
> > Well, there is need for extra hardware in data path. Depending
> > on organization of FPU almost all hardware needed for denormals
> > may be already there. Probably worst case is FPU with separate
> > load/store unit, adder and multiplier. When operating internally
> > on normalized numbers such FPU needs extra exponenent bit,
> > shifter in load/store unit (not needed otherwise), and extra
> > rounding circuitry after multiplication.
> <
> Once your FPU design is centered around FMAC, the added circuitry
> is about 1.2-gates per bit of accumulator width and 1 gate delay of
> added latency.
> <
> The FMUL unit in Opteron was ~60-gates of delay
> The FADD unit of Opteron was ~50-gates of delay
> With a cycle time of 16-gates of logic per cycle.

Ok, using your numbers cost is about 1.6% of latency. Now look
at gain (for simplicity only for single precision, for double
precision relative gain is smaller): extra representable numbers
are less than 0.13 extra exponent bits, that is 0.4% improvement.
And _everyone_ must pay latency cost, while denormals gain you
this 0.4% only if you use them.

> <
> <
> < This may increase
> > load/store latency and multiplication latency. AFAICS allowing
> > denormals internaly means slightly modified arithemtic units
> > to avoid inserting hideden bit for denormals. For multiplication
> > and division again there is problem of rounding plus need to
> > shift (to get denormal representation).
> >
> > Either case does not look like a very bing problem. OTOH
> > extra gates may lower clock frequentcy by few percent or
> > add extra clock of latency.
> >
> > I find denormals of almost no use, so even low extra cost
> > seem too high. But other folks may prefer different
> > tradeof.
> <
> That was my position n 1985, I have been edumacated to the
> facts that denorms are not "expensive" and it is easier to obey
> the std than to hand wave around not needing to fully comply.

You write "obey the std". IMO standard is bad here (well,
this looks like typical mistake made when decision are made
by committee). I understand that some programs may depend
on denormals. Using traps and software emulation is probably
the best way for handling such programs. If authors care
about speed they will fix programs to avoid denormals. If
authors do not care, then presumably emulation is fast
enough.

--
Waldek Hebisch

On 3/19/2022 10:42 AM, antispam@math.uni.wroc.pl wrote:
> MitchAlsup <MitchAlsup@aol.com> wrote:
>> On Thursday, March 17, 2022 at 8:24:14 PM UTC-5, anti...@math.uni.wroc.pl wrote:
>>> Quadibloc <jsa...@ecn.ab.ca> wrote:
>>>> On Wednesday, January 26, 2022 at 12:05:13 AM UTC-7, Thomas Koenig wrote:
>>>>
>>>>> I especially like the sentence
>>>>>
>>>>> DEC?s main advocate on the IEEE p754 Committee was a Mathematician
>>>>> and Numerical Analyst Dr. Mary H. Payne. She was experienced,
>>>>> fully competent,
>>>>>
>>>>> and misled by DEC?s hardware engineers
>>>>>
>>>>> when they assured her that Gradual Underflow was unimplementable
>>>>> as the default (no trap) of any computer arithmetic aspiring to
>>>>> high performance.
>>>>
>>>> That is true, but, although I may be mistaken, it appeared to me that
>>>> while one certainly _could_ have a high-performance floating-point
>>>> implementation which fully supported IEEE 754 gradual underflow,
>>>>
>>>> one would have to do it by representing floating-point numbers in an
>>>> "internal form" when they're in registers, like the way the 8087 did it,
>>>> where the internal form was like an old-style plain floating-point format,
>>>> but with a range larger than the architectural floating-point format, so
>>>> that it covered all the gradual underflow territory.
>>>>
>>>> And, of course, if you do it that way, you can't properly and accurately
>>>> trap when a register-to-register calculation underflows, because that isn't
>>>> easily visible any longer. Instead, you find out when you store the result
>>>> in memory.
>>>
>>> Well, "internal format" really means one extra exponent bit.
>>> Detecting underflow with such format does not present extra
>>> difficulty. Real problem is that one has to properly round
>>> result so that it does not have more accuracy than allowed
>>> by denormal representation. AFAICS rounding after addition
>>> does not present problem. But rounding after multiplication
>>> of division may be problematic, basically instead of rounding
>>> in fixed binary position one need rounding at variable position.
>>>
>>>> So if you _exclude_ the idea of doing calculations on an internal form
>>>> of numbers, because it's problematic, then indeed gradual underflow will
>>>> obstruct high performance.
>>>
>>> Well, there is need for extra hardware in data path. Depending
>>> on organization of FPU almost all hardware needed for denormals
>>> may be already there. Probably worst case is FPU with separate
>>> load/store unit, adder and multiplier. When operating internally
>>> on normalized numbers such FPU needs extra exponenent bit,
>>> shifter in load/store unit (not needed otherwise), and extra
>>> rounding circuitry after multiplication.
>> <
>> Once your FPU design is centered around FMAC, the added circuitry
>> is about 1.2-gates per bit of accumulator width and 1 gate delay of
>> added latency.
>> <
>> The FMUL unit in Opteron was ~60-gates of delay
>> The FADD unit of Opteron was ~50-gates of delay
>> With a cycle time of 16-gates of logic per cycle.
>
> Ok, using your numbers cost is about 1.6% of latency. Now look
> at gain (for simplicity only for single precision, for double
> precision relative gain is smaller): extra representable numbers
> are less than 0.13 extra exponent bits, that is 0.4% improvement.
> And _everyone_ must pay latency cost, while denormals gain you
> this 0.4% only if you use them.
>
>> <
>> <
>> < This may increase
>>> load/store latency and multiplication latency. AFAICS allowing
>>> denormals internaly means slightly modified arithemtic units
>>> to avoid inserting hideden bit for denormals. For multiplication
>>> and division again there is problem of rounding plus need to
>>> shift (to get denormal representation).
>>>
>>> Either case does not look like a very bing problem. OTOH
>>> extra gates may lower clock frequentcy by few percent or
>>> add extra clock of latency.
>>>
>>> I find denormals of almost no use, so even low extra cost
>>> seem too high. But other folks may prefer different
>>> tradeof.
>> <
>> That was my position n 1985, I have been edumacated to the
>> facts that denorms are not "expensive" and it is easier to obey
>> the std than to hand wave around not needing to fully comply.
>
> You write "obey the std". IMO standard is bad here (well,
> this looks like typical mistake made when decision are made
> by committee). I understand that some programs may depend
> on denormals. Using traps and software emulation is probably
> the best way for handling such programs. If authors care
> about speed they will fix programs to avoid denormals. If
> authors do not care, then presumably emulation is fast
> enough.

Not all increases in gate count lead to increases in cycle count.
Digital circuits have a gate-count granularity; if the increase in gates
just utilizes gates that would be otherwise wasted in the final cycle
then the actual cost of denormal support is zero.

And the designer has some control over granularity. If it happens that
denormals push a performance-critical instruction over a cycle boundary,
then the size of a cycle can be adjusted with, if necessary, a balance
in the clock rate. However, it is extremely unlikely that any FP
instruction is so critical in the market - far more likely is that the
time to the D$1 is what chooses the cycle gate-width.

On Saturday, March 19, 2022 at 12:42:47 PM UTC-5, anti...@math.uni.wroc.pl wrote:
> MitchAlsup <Mitch...@aol.com> wrote:
> > On Thursday, March 17, 2022 at 8:24:14 PM UTC-5, anti...@math.uni.wroc.pl wrote:
> > > Quadibloc <jsa...@ecn.ab.ca> wrote:
> > > > On Wednesday, January 26, 2022 at 12:05:13 AM UTC-7, Thomas Koenig wrote:
> > > >
> > > > > I especially like the sentence
> > > > >
> > > > > DEC?s main advocate on the IEEE p754 Committee was a Mathematician
> > > > > and Numerical Analyst Dr. Mary H. Payne. She was experienced,
> > > > > fully competent,
> > > > >
> > > > > and misled by DEC?s hardware engineers
> > > > >
> > > > > when they assured her that Gradual Underflow was unimplementable
> > > > > as the default (no trap) of any computer arithmetic aspiring to
> > > > > high performance.
> > > >
> > > > That is true, but, although I may be mistaken, it appeared to me that
> > > > while one certainly _could_ have a high-performance floating-point
> > > > implementation which fully supported IEEE 754 gradual underflow,
> > > >
> > > > one would have to do it by representing floating-point numbers in an
> > > > "internal form" when they're in registers, like the way the 8087 did it,
> > > > where the internal form was like an old-style plain floating-point format,
> > > > but with a range larger than the architectural floating-point format, so
> > > > that it covered all the gradual underflow territory.
> > > >
> > > > And, of course, if you do it that way, you can't properly and accurately
> > > > trap when a register-to-register calculation underflows, because that isn't
> > > > easily visible any longer. Instead, you find out when you store the result
> > > > in memory.
> > >
> > > Well, "internal format" really means one extra exponent bit.
> > > Detecting underflow with such format does not present extra
> > > difficulty. Real problem is that one has to properly round
> > > result so that it does not have more accuracy than allowed
> > > by denormal representation. AFAICS rounding after addition
> > > does not present problem. But rounding after multiplication
> > > of division may be problematic, basically instead of rounding
> > > in fixed binary position one need rounding at variable position.
> > >
> > > > So if you _exclude_ the idea of doing calculations on an internal form
> > > > of numbers, because it's problematic, then indeed gradual underflow will
> > > > obstruct high performance.
> > >
> > > Well, there is need for extra hardware in data path. Depending
> > > on organization of FPU almost all hardware needed for denormals
> > > may be already there. Probably worst case is FPU with separate
> > > load/store unit, adder and multiplier. When operating internally
> > > on normalized numbers such FPU needs extra exponenent bit,
> > > shifter in load/store unit (not needed otherwise), and extra
> > > rounding circuitry after multiplication.
> > <
> > Once your FPU design is centered around FMAC, the added circuitry
> > is about 1.2-gates per bit of accumulator width and 1 gate delay of
> > added latency.
> > <
> > The FMUL unit in Opteron was ~60-gates of delay
> > The FADD unit of Opteron was ~50-gates of delay
> > With a cycle time of 16-gates of logic per cycle.
> Ok, using your numbers cost is about 1.6% of latency. Now look
<
That is not how it works.
<
With a 16-gate machine, you have 16-gates, 32-gates, 48-gates,
64-gates as design targets. It would take a lot of pounding to get
FADD down to 48-gates and thereby 3-cycles, it is impossible to
get FMUL down to 3-cycles, so you have 4-more gates of logic
where you can do stuff. Thus, 4-easy cycles for FADD, 4-not-so
hard cycles for FMUL, and the FP pipeline is uniformly 4-cycles
long making the overall FPU easier to design.
<
You can do the same analysis with any gates of delay you like.
<
I should also add that an FMAC is 62 gates of delay. This limits
some of the gates-per-cycle decisions that are viable.
<
> at gain (for simplicity only for single precision, for double
> precision relative gain is smaller): extra representable numbers
> are less than 0.13 extra exponent bits, that is 0.4% improvement.
> And _everyone_ must pay latency cost, while denormals gain you
> this 0.4% only if you use them.
> > <
> > <
> > < This may increase
> > > load/store latency and multiplication latency. AFAICS allowing
> > > denormals internaly means slightly modified arithemtic units
> > > to avoid inserting hideden bit for denormals. For multiplication
> > > and division again there is problem of rounding plus need to
> > > shift (to get denormal representation).
> > >
> > > Either case does not look like a very bing problem. OTOH
> > > extra gates may lower clock frequentcy by few percent or
> > > add extra clock of latency.
> > >
> > > I find denormals of almost no use, so even low extra cost
> > > seem too high. But other folks may prefer different
> > > tradeof.
> > <
> > That was my position n 1985, I have been edumacated to the
> > facts that denorms are not "expensive" and it is easier to obey
> > the std than to hand wave around not needing to fully comply.
<
> You write "obey the std". IMO standard is bad here (well,
> this looks like typical mistake made when decision are made
> by committee). I understand that some programs may depend
> on denormals. Using traps and software emulation is probably
> the best way for handling such programs. If authors care
> about speed they will fix programs to avoid denormals. If
> authors do not care, then presumably emulation is fast
> enough.
<
a) I can agree that the std is baroque and has stuff in it that
should not be there. But it is there, and some people (i.e., fools)
are dependent upon those poor ideas being in the std.
b) therefore change the std, introduce a new std and have
people/applications migrate to the new std.
c) but do not argue that the current std is too hard to
implement. That part is not true.
>
> --
> Waldek Hebisch

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Friday, March 18, 2022 at 7:27:33 PM UTC-6, John Levine wrote:
>
>> On both machines there was a variety of no-op that waited for all
>> previous instructions to finish
>
>Yes, there was, I saw that in my search to confirm the 91's interrupts
>were imprecise.
>
>> that you could use to get the effect of a precise interrupt.
>
>No. Because while you could indeed use that instruction to get
>an interrupt after an instruction, instead of an interrupt in the middle
>of a complicated pipeline state with many instructions in flight, the
>instruction you interrupted at wouldn't be the _right_ instruction.

I said the effect of a precise interrupt, not an actual precise interrupt.
If you put the flushing no-op after each instruction that might fault, you
just subtract 2 to get the address of the faulting instruction. Nobody said
this would be fast.

>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.

On the /91 and /195, the imprecise interrupts you might want to
recover from were floating point overflow and underflow. Anything else
was either an addressing error which would mean a progrm bug, or a
zero divide or fixed point overflow which was easy to test for and
prevent the fault.

--
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 Friday, March 18, 2022 at 8:43:53 PM UTC+2, MitchAlsup wrote:
> On Friday, March 18, 2022 at 10:27:35 AM UTC-5, Michael S wrote:
> > On Friday, March 18, 2022 at 10:53:03 AM UTC+2, Terje Mathisen wrote:
> > > anti...@math.uni.wroc.pl wrote:
> > > > Quadibloc <jsa...@ecn.ab.ca> wrote:
> > > >> On Wednesday, January 26, 2022 at 12:05:13 AM UTC-7, Thomas Koenig wrote:
> > > >>
> > > >>> I especially like the sentence
> > > >>>
> > > >>> DEC?s main advocate on the IEEE p754 Committee was a Mathematician
> > > >>> and Numerical Analyst Dr. Mary H. Payne. She was experienced,
> > > >>> fully competent,
> > > >>>
> > > >>> and misled by DEC?s hardware engineers
> > > >>>
> > > >>> when they assured her that Gradual Underflow was unimplementable
> > > >>> as the default (no trap) of any computer arithmetic aspiring to
> > > >>> high performance.
> > > >>
> > > >> That is true, but, although I may be mistaken, it appeared to me that
> > > >> while one certainly _could_ have a high-performance floating-point
> > > >> implementation which fully supported IEEE 754 gradual underflow,
> > > >>
> > > >> one would have to do it by representing floating-point numbers in an
> > > >> "internal form" when they're in registers, like the way the 8087 did it,
> > > >> where the internal form was like an old-style plain floating-point format,
> > > >> but with a range larger than the architectural floating-point format, so
> > > >> that it covered all the gradual underflow territory.
> > > >>
> > > >> And, of course, if you do it that way, you can't properly and accurately
> > > >> trap when a register-to-register calculation underflows, because that isn't
> > > >> easily visible any longer. Instead, you find out when you store the result
> > > >> in memory.
> > > >
> > > > Well, "internal format" really means one extra exponent bit.
> > > > Detecting underflow with such format does not present extra
> > > > difficulty. Real problem is that one has to properly round
> > > > result so that it does not have more accuracy than allowed
> > > > by denormal representation. AFAICS rounding after addition
> > > > does not present problem. But rounding after multiplication
> > > > of division may be problematic, basically instead of rounding
> > > > in fixed binary position one need rounding at variable position.
> > > >
> > > >> So if you _exclude_ the idea of doing calculations on an internal form
> > > >> of numbers, because it's problematic, then indeed gradual underflow will
> > > >> obstruct high performance.
> > > >
> > > > Well, there is need for extra hardware in data path. Depending
> > > > on organization of FPU almost all hardware needed for denormals
> > > > may be already there. Probably worst case is FPU with separate
> > > > load/store unit, adder and multiplier. When operating internally
> > > > on normalized numbers such FPU needs extra exponenent bit,
> > > > shifter in load/store unit (not needed otherwise), and extra
> > > > rounding circuitry after multiplication. This may increase
> > > > load/store latency and multiplication latency. AFAICS allowing
> > > > denormals internaly means slightly modified arithemtic units
> > > > to avoid inserting hideden bit for denormals. For multiplication
> > > > and division again there is problem of rounding plus need to
> > > > shift (to get denormal representation).
> > > >
> > > > Either case does not look like a very bing problem. OTOH
> > > > extra gates may lower clock frequentcy by few percent or
> > > > add extra clock of latency.
> > > >
> > > > I find denormals of almost no use, so even low extra cost
> > > > seem too high. But other folks may prefer different
> > > > tradeof.
> > > I seldom _need_ subnormal myself, but I have been told that there exists
> > > solution solvers/zero finders that fail to stabilize (you end up
> > > flipping back & forth between two values) unless you have subnormals.
> > >
> > That's what I expect for "chord&tangent" solver, the one I was taught back in high school
> > even before we "officially" were taught derivatives in the math class.
> > Probably, the same applies to pure tangent (i.e. Newton) method, but here I'm less sure.
> > > That, plus the fact (which you mention above) that any FMAC-supporting
> > > fp unit already have all the required circuitry to allow you to skip
> > > input normalization, means that I like Mitch Alsup strongly believe all
> > > fp units should support subnormal values at zero cycle cost.
> <
> > There are different scenarios for one or more denormal input or output.
> > In some of them microtrap could be the best practical solution.
> > In particular, I am thinking about designs where latency of regular ("normal")
> > FADD is lower than latency of FMUL and of FMADD.
> <
> For both FADD and FMUL and FMAC and for the numerator of FDIV, a denorm
> as input simply does not have to generate the hidden bit::
> <
> if( operand.exponent = 0 )
> then 0.fraction;
> else 1.fraction;
> <
> For the output of FADD and FMUL and FMAC and FDIV, you inject a synthetic
> 1-bit at the position the hidden bit would have been in the largest possible denorm.
> This prevents the normalizer from shifting too many positions to the left and gives
> you the proper denormalized result.
> {Note: you insert the synthetic 1-bit only with the value going into the find-first
> circuit, not the value going into the shifter the find-first controls.}
> <
> > Mitch does not see a point in such designs, but I do see it.
> <
> Correction, Mitch sees no value in not fully obeying IEEE 754-2019 because
> the cost to do so is so small.

Implementation of corner cases via microtrap (as opposed to sw-visible trap) fully obey IEEE 754-2019.

> <
> 25 years ago I was in the same camp you seem to be in today. I was shown
> various circuitry tricks that made the denorm problem vanish into a cost so
> small I would be foolish not to do the complete package.
> <
> It costs far less to satisfy the denorm problem in the FPU than it cost to solve
> the precise exception problem when taking exceptions. Far far less. Yet you
> would never accept the later.
> <
> > > Terje
> > >
> > > --
> > > - <Terje.Mathisen at tmsw.no>
> > > "almost all programming can be viewed as an exercise in caching"

On Friday, March 18, 2022 at 6:04:37 PM UTC+2, Terje Mathisen wrote:
> Michael S wrote:
> > On Friday, March 18, 2022 at 10:53:03 AM UTC+2, Terje Mathisen wrote:
> >> I seldom _need_ subnormal myself, but I have been told that there exists
> >> solution solvers/zero finders that fail to stabilize (you end up
> >> flipping back & forth between two values) unless you have subnormals.
> >>
> >
> > That's what I expect for "chord&tangent" solver, the one I was taught back in high school
> > even before we "officially" were taught derivatives in the math class.
> > Probably, the same applies to pure tangent (i.e. Newton) method, but here I'm less sure.
> >
> >> That, plus the fact (which you mention above) that any FMAC-supporting
> >> fp unit already have all the required circuitry to allow you to skip
> >> input normalization, means that I like Mitch Alsup strongly believe all
> >> fp units should support subnormal values at zero cycle cost.
> >
> > There are different scenarios for one or more denormal input or output.
> > In some of them microtrap could be the best practical solution.
> > In particular, I am thinking about designs where latency of regular ("normal") FADD is lower than latency of FMUL and of FMADD.
> > Mitch does not see a point in such designs, but I do see it.
> After spending 2016-2019 on the ieee754 update working group I strongly
> support Mitch's viewpoint here: Just optimize the heck out of FMAC and
> make that the basic building block for all your operations, including
> FDIV/FSQRT and all the trancendentals.
>
> The possibility of getting a pure FADD one cycle faster, but only when
> none of potentially many parallel SIMD operations hit a subnormal input
> or output, fails to excite me.
> Terje
>
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

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.

On Saturday, March 19, 2022 at 3:26:21 PM UTC-5, Michael S wrote:
> On Friday, March 18, 2022 at 6:04:37 PM UTC+2, Terje Mathisen wrote:
> > Michael S wrote:
> > > On Friday, March 18, 2022 at 10:53:03 AM UTC+2, Terje Mathisen wrote:
> > >> I seldom _need_ subnormal myself, but I have been told that there exists
> > >> solution solvers/zero finders that fail to stabilize (you end up
> > >> flipping back & forth between two values) unless you have subnormals..
> > >>
> > >
> > > That's what I expect for "chord&tangent" solver, the one I was taught back in high school
> > > even before we "officially" were taught derivatives in the math class..
> > > Probably, the same applies to pure tangent (i.e. Newton) method, but here I'm less sure.
> > >
> > >> That, plus the fact (which you mention above) that any FMAC-supporting
> > >> fp unit already have all the required circuitry to allow you to skip
> > >> input normalization, means that I like Mitch Alsup strongly believe all
> > >> fp units should support subnormal values at zero cycle cost.
> > >
> > > There are different scenarios for one or more denormal input or output.
> > > In some of them microtrap could be the best practical solution.
> > > In particular, I am thinking about designs where latency of regular ("normal") FADD is lower than latency of FMUL and of FMADD.
> > > Mitch does not see a point in such designs, but I do see it.
> > After spending 2016-2019 on the ieee754 update working group I strongly
> > support Mitch's viewpoint here: Just optimize the heck out of FMAC and
> > make that the basic building block for all your operations, including
> > FDIV/FSQRT and all the trancendentals.
> >
> > The possibility of getting a pure FADD one cycle faster, but only when
> > none of potentially many parallel SIMD operations hit a subnormal input
> > or output, fails to excite me.
> > Terje
> >
> >
> > --
> > - <Terje.Mathisen at tmsw.no>
> > "almost all programming can be viewed as an exercise in caching"
> 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.
<
GPUs are not SIMD because each calculation belongs to a different thread, one which
can take different control flow,...
>
> 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.
<
FMAC is 62 gates of delay
FMUL is 60 gates of delay
FADD is 50 gates of delay
<
To get FADD into 3 cycles, you need 17 gates per cycle (2×17=51)
Thereby FMAC is CEIL(62/17) = CEIL(3.647) = 4 cycles with comfortable margin.
<
Thus, there is not a realistic scenario where FADD is 3 and FMAC is 5.

On Sunday, March 20, 2022 at 12:13:25 AM UTC+2, MitchAlsup wrote:
> On Saturday, March 19, 2022 at 3:26:21 PM UTC-5, Michael S wrote:
> > On Friday, March 18, 2022 at 6:04:37 PM UTC+2, Terje Mathisen wrote:
> > > Michael S wrote:
> > > > On Friday, March 18, 2022 at 10:53:03 AM UTC+2, Terje Mathisen wrote:
> > > >> I seldom _need_ subnormal myself, but I have been told that there exists
> > > >> solution solvers/zero finders that fail to stabilize (you end up
> > > >> flipping back & forth between two values) unless you have subnormals.
> > > >>
> > > >
> > > > That's what I expect for "chord&tangent" solver, the one I was taught back in high school
> > > > even before we "officially" were taught derivatives in the math class.
> > > > Probably, the same applies to pure tangent (i.e. Newton) method, but here I'm less sure.
> > > >
> > > >> That, plus the fact (which you mention above) that any FMAC-supporting
> > > >> fp unit already have all the required circuitry to allow you to skip
> > > >> input normalization, means that I like Mitch Alsup strongly believe all
> > > >> fp units should support subnormal values at zero cycle cost.
> > > >
> > > > There are different scenarios for one or more denormal input or output.
> > > > In some of them microtrap could be the best practical solution.
> > > > In particular, I am thinking about designs where latency of regular ("normal") FADD is lower than latency of FMUL and of FMADD.
> > > > Mitch does not see a point in such designs, but I do see it.
> > > After spending 2016-2019 on the ieee754 update working group I strongly
> > > support Mitch's viewpoint here: Just optimize the heck out of FMAC and
> > > make that the basic building block for all your operations, including
> > > FDIV/FSQRT and all the trancendentals.
> > >
> > > The possibility of getting a pure FADD one cycle faster, but only when
> > > none of potentially many parallel SIMD operations hit a subnormal input
> > > or output, fails to excite me.
> > > Terje
> > >
> > >
> > > --
> > > - <Terje.Mathisen at tmsw.no>
> > > "almost all programming can be viewed as an exercise in caching"
> > 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.
> <
> GPUs are not SIMD because each calculation belongs to a different thread, one which
> can take different control flow,...
> >
> > 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.
> <
> FMAC is 62 gates of delay
> FMUL is 60 gates of delay
> FADD is 50 gates of delay
> <
> To get FADD into 3 cycles, you need 17 gates per cycle (2×17=51)

Is it still a case when rare corner cases rise uTraps?

> Thereby FMAC is CEIL(62/17) = CEIL(3.647) = 4 cycles with comfortable margin.
> <
> Thus, there is not a realistic scenario where FADD is 3 and FMAC is 5.

On Saturday, March 19, 2022 at 5:40:46 PM UTC-5, Michael S wrote:
> On Sunday, March 20, 2022 at 12:13:25 AM UTC+2, MitchAlsup wrote:

> > > 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.
> > <
> > FMAC is 62 gates of delay
> > FMUL is 60 gates of delay
> > FADD is 50 gates of delay
> > <
> > To get FADD into 3 cycles, you need 17 gates per cycle (2×17=51)
<
> Is it still a case when rare corner cases rise uTraps?
<
Not the way most people build them these days, about the only corner case is when
denominator is denormalized and one is using Newton-Raphson or Goldschmidt
division. It does not mater if division is SRT.
<
> > Thereby FMAC is CEIL(62/17) = CEIL(3.647) = 4 cycles with comfortable margin.
> > <
> > Thus, there is not a realistic scenario where FADD is 3 and FMAC is 5.

On Sunday, March 20, 2022 at 2:34:42 AM UTC+2, MitchAlsup wrote:
> On Saturday, March 19, 2022 at 5:40:46 PM UTC-5, Michael S wrote:
> > On Sunday, March 20, 2022 at 12:13:25 AM UTC+2, MitchAlsup wrote:
>
> > > > 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.
> > > <
> > > FMAC is 62 gates of delay
> > > FMUL is 60 gates of delay
> > > FADD is 50 gates of delay
> > > <
> > > To get FADD into 3 cycles, you need 17 gates per cycle (2×17=51)
> <
> > Is it still a case when rare corner cases rise uTraps?
> <
> Not the way most people build them these days, about the only corner case is when
> denominator is denormalized and one is using Newton-Raphson or Goldschmidt
> division. It does not mater if division is SRT.

I was talking about class of designs where FADD unit is specialized for FADD and nothing else.
FDIV is done either by completely separate HW or by the same unit that does FMADD.

That's appears to be a design that Intel used before SKL and that AMD used in Zen1 and Zen2 for at least one of their pair FADD pipes.
May be, Zen3 too.

> <
> > > Thereby FMAC is CEIL(62/17) = CEIL(3.647) = 4 cycles with comfortable margin.
> > > <
> > > Thus, there is not a realistic scenario where FADD is 3 and FMAC is 5..

On Saturday, March 19, 2022 at 8:06:07 PM UTC-5, Michael S wrote:
> On Sunday, March 20, 2022 at 2:34:42 AM UTC+2, MitchAlsup wrote:
> > On Saturday, March 19, 2022 at 5:40:46 PM UTC-5, Michael S wrote:
> > > On Sunday, March 20, 2022 at 12:13:25 AM UTC+2, MitchAlsup wrote:
> >
> > > > > 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.
> > > > <
> > > > FMAC is 62 gates of delay
> > > > FMUL is 60 gates of delay
> > > > FADD is 50 gates of delay
> > > > <
> > > > To get FADD into 3 cycles, you need 17 gates per cycle (2×17=51)
> > <
> > > Is it still a case when rare corner cases rise uTraps?
> > <
> > Not the way most people build them these days, about the only corner case is when
> > denominator is denormalized and one is using Newton-Raphson or Goldschmidt
> > division. It does not mater if division is SRT.
<
> I was talking about class of designs where FADD unit is specialized for FADD and nothing else.
<
I was talking about the Opteron FADD unit. Which does FADD, FSUB, FCMP, but not
FMUL, FDIV, SQRT, or conversions.
<
> FDIV is done either by completely separate HW or by the same unit that does FMADD.
<
This does not change the delay of the FADD part.
>
> That's appears to be a design that Intel used before SKL and that AMD used in Zen1 and Zen2
> for at least one of their pair FADD pipes. May be, Zen3 too.
> > <
> > > > Thereby FMAC is CEIL(62/17) = CEIL(3.647) = 4 cycles with comfortable margin.
> > > > <
> > > > Thus, there is not a realistic scenario where FADD is 3 and FMAC is 5.

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.

John Savard

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.
>
> John Savard

On 3/19/2022 11:17 AM, John Levine wrote:
> According to Quadibloc <jsavard@ecn.ab.ca>:

snip

>> 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.

:-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Michael S <already5chosen@yahoo.com> writes:
>On Sunday, March 20, 2022 at 2:34:42 AM UTC+2, MitchAlsup wrote:
>> > > FMAC is 62 gates of delay=20
>> > > FMUL is 60 gates of delay=20
>> > > FADD is 50 gates of delay=20
....
>I was talking about class of designs where FADD unit is specialized for FAD=
>D and nothing else.
....
>That's appears to be a design that Intel used before SKL and that AMD used =
>in Zen1 and Zen2 for at least one of their pair FADD pipes.=20
>May be, Zen3 too.

Looking at <https://www.agner.org/optimize/instruction_tables.pdf>,
the latencies are:

ADDPD MULPD VFMADD132PD
3 4 5 Zen
3 3 5 Zen2
3 3 4 Zen3

The diagrams I remember show FADD and FMA units for all of these
cores.

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

Quadibloc <jsavard@ecn.ab.ca> writes:
>On Saturday, March 19, 2022 at 10:16:10 AM UTC-6, MitchAlsup wrote:
>> Build machines that are immune from Spectr=C3=A9.=20
>
>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.

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, or, in the case of Alder Lake, which may have been
early enough in the design process to make it immune without
significant schedule delays, where the CPU designers were told (or
told each other) not to worry about it and throw the problem over to
software. Because these CPUs are not immune to Spectre, they need
mitigations, and these mitigations cost.

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

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.

John Savard