On Wednesday, January 26, 2022 at 2:13:21 AM UTC-6, Quadibloc 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,
<
The amount of logic to "deal with" gradual underflow from a calculation
is on the order of a decoder and an vector of OR gates*. The decoder works
off the intermediate exponent and inserts a synthetic bit in the intermediate
result sent into the normalizer. This prevents over-normalization--if a result
is going to gradual underflow, stop shifting when the resulting exponent
will be zero.
{decoder of 11-bits is an AND gate on the upper 5-bits (can't be a denorm)
and a insert position decoder on the lower 6-bits (64+ln4(64) = 67) plus
the bit inserter 64-gates} that starts running immediately after the
intermediate exponent has been calculated (even before the fraction
field has begun to resolve) so it adds no delay.}
<
The amount of logic to deal with gradual underflow of operands is a decoder
that looks at the exponent and does not insert the hidden-bit. This is simply
an 11-bit in 1-bit out AND gate. 4 total gates per operand.
<
Total amount of delay added to the calculation: 1 gate of delay.
<
In this day an age, with what we know about 754 there is no particular
reason to treat denorms as "difficult".
<
>
> 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.
>
> 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.
>
> John Savard

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> Alpha didn't have SEXT/ZEXT sign/zero extend instructions
>>> so it would have required a pair of shifts.
>>
>> Alpha uses addl for sign extension and some zap instruction for zero
>> extension. If they had not added addl, they could have added an sext
>> instruction instead.
>
> There were lots of instructions they could have had, but they seemed
> almost obsessive that the R in RISC means reduced instruction _count_.
>
> They left out the byte and word load and stores, supposedly because
> that would require the byte shifter network on the critical path.

Alpha also had the highest frequencies at the time. This sort of
decision might have been taken to reduce gate delays.

On 2022-01-25 17:53, Anton Ertl wrote (in part):
> EricP <ThatWouldBeTelling@thevillage.com> writes (in part):
>> MIPS probably faced similar situation going from MIPS32 to MIPS64.
>
> MIPS already had a 32-bit software base, and AFAIK wanted (and
> succeeded) in having a modeless extension to 64 bits.

UNIX distributions, and resulting software, were based on ILP32.
Manufacturers that expanded to 64 bits (such as MIPS, SPARC, and others)
needed to support the existing base.

There was a paper on the X/Open website that explained this but I am
unable to find it since they became Opengroup.

N.

>
> - anton
>

On Wednesday, January 26, 2022 at 12:13:38 PM UTC-6, Thomas Koenig wrote:
> EricP <ThatWould...@thevillage.com> schrieb:
> > Anton Ertl wrote:
> >> EricP <ThatWould...@thevillage.com> writes:
> >>> Alpha didn't have SEXT/ZEXT sign/zero extend instructions
> >>> so it would have required a pair of shifts.
> >>
> >> Alpha uses addl for sign extension and some zap instruction for zero
> >> extension. If they had not added addl, they could have added an sext
> >> instruction instead.
> >
> > There were lots of instructions they could have had, but they seemed
> > almost obsessive that the R in RISC means reduced instruction _count_.
> >
> > They left out the byte and word load and stores, supposedly because
> > that would require the byte shifter network on the critical path.
<
> Alpha also had the highest frequencies at the time. This sort of
> decision might have been taken to reduce gate delays.
<
Squeezing DCache access into 2 cycles, Requiring tiny L1s.
<
Now, fast GBOoO machines have allowed Load latency to slip on out to 4
cycles as available technology only allows for SRAM macros that take
1 entire cycle from address (registered at the rising edge of clock) to
data (not visible until after the rising edge of the subsequent clock.
<
A long time ago we could get from address in to data out in ½ cycle. And
by making use of the fact that the lower address bits resolved before
the higher address bits, these lower bits could be routed to the SRAMs
while the higher bits resolved. Along with the ½ cycle SRAMs meant
that 2 cycle LDs were feasible. Alpha, pushing frequency, dropped the
2 gate-delay alignment shifter to fit LDs into 2 cycles. MIPS, not pushing
frequency as hard, got the aligner to fit. In both cases, Alpha and MIPS
performed hit detection while used the forwarded data.
<
Now, with Meltdown and Spectré, and with SRAMs no faster than "a bit
more than" 1 full cycle, and with wire delay a lot harder, and the need
for non-tiny L1 caches, designers cannot make the LD latency less than
3-cycles, and if we push frequency, these invariably become 4-cycles.
3-cycles is enough that you know at forwarding time if the LD is got a
hit--so you are not flying blind with data--the exact exploit meltdown
and Spectré abuse.

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>MIPS already had a 32-bit software base, and AFAIK wanted (and
>succeeded) in having a modeless extension to 64 bits. Which makes
>RISC-V's moded approach quite surprising.

Having seen a few modeless extensions to larger word sizes (remember Soul of a New Machine?)
I can see why RISC-V might have looked at them and said, naaah.

Software ends up being modal in practice since you still need glue code if
you want to call a 32-bit routine from code that is using 64 bit addresses.

--
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 Wednesday, January 26, 2022 at 2:34:28 PM UTC-6, John Levine wrote:
> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >MIPS already had a 32-bit software base, and AFAIK wanted (and
> >succeeded) in having a modeless extension to 64 bits. Which makes
> >RISC-V's moded approach quite surprising.
> Having seen a few modeless extensions to larger word sizes (remember Soul of a New Machine?)
> I can see why RISC-V might have looked at them and said, naaah.
>
> Software ends up being modal in practice since you still need glue code if
> you want to call a 32-bit routine from code that is using 64 bit addresses.
<
These are the expected outcomes when technology arrives at just the wrong
moment in time. Had Mc 88K been designed when 1μ was available instead
of 1.5μ, the 88K would have been 64-bit from the get-go. Yet the design world
was abuzz with RISC from just after the first tape-out capabilities of 2μ. This
timing is what lead to I32LP64 problems.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

According to Nemo <invalid@invalid.invalid>:
>On 2022-01-25 17:53, Anton Ertl wrote (in part):
>> EricP <ThatWouldBeTelling@thevillage.com> writes (in part):
>>> MIPS probably faced similar situation going from MIPS32 to MIPS64.
>>
>> MIPS already had a 32-bit software base, and AFAIK wanted (and
>> succeeded) in having a modeless extension to 64 bits.
>
>UNIX distributions, and resulting software, were based on ILP32.
>Manufacturers that expanded to 64 bits (such as MIPS, SPARC, and others)
>needed to support the existing base.

They still do. You can run 32 bit linux and BSD code on 64 bit i86 systems.
They have 32 bit versions of the libraries that the 32 bit programs need
and the O/S supports both the 32 and 64 bit modes. It is a minor pain
but not as much as you might think.

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

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Wednesday, January 26, 2022 at 2:34:28 PM UTC-6, John Levine wrote:
>> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
>> >MIPS already had a 32-bit software base, and AFAIK wanted (and
>> >succeeded) in having a modeless extension to 64 bits. Which makes
>> >RISC-V's moded approach quite surprising.
>> Having seen a few modeless extensions to larger word sizes (remember Soul of a New Machine?)
>> I can see why RISC-V might have looked at them and said, naaah.
>>
>> Software ends up being modal in practice since you still need glue code if
>> you want to call a 32-bit routine from code that is using 64 bit addresses.
><
> These are the expected outcomes when technology arrives at just the wrong
> moment in time. Had Mc 88K been designed when 1μ was available instead
> of 1.5μ, the 88K would have been 64-bit from the get-go. Yet the design world
> was abuzz with RISC from just after the first tape-out capabilities of 2μ. This
> timing is what lead to I32LP64 problems.

If a program is small enough to easily fit into a 32-bit address
space, there is often no advantage to using 64 bit pointers,
they use more memory and cache.

SPARC defaults to 32 bit-mode even on processors which have
64 bit registers, AFAIK for this reason (Jörg Schilling argued
this on de.comp.lang.c shortly before his untimely death).

There are a few applications where 64 bit data makes sense,
crypto being among them.

On Wednesday, January 26, 2022 at 3:14:39 PM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Wednesday, January 26, 2022 at 2:34:28 PM UTC-6, John Levine wrote:
> >> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >> >MIPS already had a 32-bit software base, and AFAIK wanted (and
> >> >succeeded) in having a modeless extension to 64 bits. Which makes
> >> >RISC-V's moded approach quite surprising.
> >> Having seen a few modeless extensions to larger word sizes (remember Soul of a New Machine?)
> >> I can see why RISC-V might have looked at them and said, naaah.
> >>
> >> Software ends up being modal in practice since you still need glue code if
> >> you want to call a 32-bit routine from code that is using 64 bit addresses.
> ><
> > These are the expected outcomes when technology arrives at just the wrong
> > moment in time. Had Mc 88K been designed when 1μ was available instead
> > of 1.5μ, the 88K would have been 64-bit from the get-go. Yet the design world
> > was abuzz with RISC from just after the first tape-out capabilities of 2μ. This
> > timing is what lead to I32LP64 problems.
<
> If a program is small enough to easily fit into a 32-bit address
> space, there is often no advantage to using 64 bit pointers,
> they use more memory and cache.
<
Having an application that can fit into a 32-bit memory model is a compiler
thing, not a requirement on HW. For example, a purely 64-bit machine like
My 66000 can leave pointers as 32-bits in memory should that be a reasonable
choice for that piece of SW. The SW ensemble just needs to arrange all of
the memory be addressable in 32-bits {stack, heap, code, data, bss, and library
load points.} The compiled code is then free to use 32-bit containers for pointers
and still use the std ABI.
<
>
> SPARC defaults to 32 bit-mode even on processors which have
> 64 bit registers, AFAIK for this reason (Jörg Schilling argued
> this on de.comp.lang.c shortly before his untimely death).
<
SPARC had modes, any RISC-done-Right® would not.
>
> There are a few applications where 64 bit data makes sense,
> crypto being among them.
<
data base,
galaxy modeling,
Quantum [electro,chroma]dynamics simulations
And strangely NOT
3D Navier-Stokes CFD

On 1/26/2022 1:41 PM, MitchAlsup wrote:
> On Wednesday, January 26, 2022 at 3:14:39 PM UTC-6, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>>> On Wednesday, January 26, 2022 at 2:34:28 PM UTC-6, John Levine wrote:
>>>> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
>>>>> MIPS already had a 32-bit software base, and AFAIK wanted (and
>>>>> succeeded) in having a modeless extension to 64 bits. Which makes
>>>>> RISC-V's moded approach quite surprising.
>>>> Having seen a few modeless extensions to larger word sizes (remember Soul of a New Machine?)
>>>> I can see why RISC-V might have looked at them and said, naaah.
>>>>
>>>> Software ends up being modal in practice since you still need glue code if
>>>> you want to call a 32-bit routine from code that is using 64 bit addresses.
>>> <
>>> These are the expected outcomes when technology arrives at just the wrong
>>> moment in time. Had Mc 88K been designed when 1μ was available instead
>>> of 1.5μ, the 88K would have been 64-bit from the get-go. Yet the design world
>>> was abuzz with RISC from just after the first tape-out capabilities of 2μ. This
>>> timing is what lead to I32LP64 problems.
> <
>> If a program is small enough to easily fit into a 32-bit address
>> space, there is often no advantage to using 64 bit pointers,
>> they use more memory and cache.
> <
> Having an application that can fit into a 32-bit memory model is a compiler
> thing, not a requirement on HW. For example, a purely 64-bit machine like
> My 66000 can leave pointers as 32-bits in memory should that be a reasonable
> choice for that piece of SW. The SW ensemble just needs to arrange all of
> the memory be addressable in 32-bits {stack, heap, code, data, bss, and library
> load points.} The compiled code is then free to use 32-bit containers for pointers
> and still use the std ABI.

We're I32LP64, and can't use your trick due to having a shared SAS,
which would overflow 32 bits. But as a compiler guy, I really wouldn't
like to have to use 32-bit pointers on a 64-bit address space - too much
nuisance with extending, and libraries, and software assumptions.

On Wednesday, January 26, 2022 at 3:58:57 PM UTC-6, Ivan Godard wrote:
> On 1/26/2022 1:41 PM, MitchAlsup wrote:
> > On Wednesday, January 26, 2022 at 3:14:39 PM UTC-6, Thomas Koenig wrote:
> >> MitchAlsup <Mitch...@aol.com> schrieb:
> >>> On Wednesday, January 26, 2022 at 2:34:28 PM UTC-6, John Levine wrote:
> >>>> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >>>>> MIPS already had a 32-bit software base, and AFAIK wanted (and
> >>>>> succeeded) in having a modeless extension to 64 bits. Which makes
> >>>>> RISC-V's moded approach quite surprising.
> >>>> Having seen a few modeless extensions to larger word sizes (remember Soul of a New Machine?)
> >>>> I can see why RISC-V might have looked at them and said, naaah.
> >>>>
> >>>> Software ends up being modal in practice since you still need glue code if
> >>>> you want to call a 32-bit routine from code that is using 64 bit addresses.
> >>> <
> >>> These are the expected outcomes when technology arrives at just the wrong
> >>> moment in time. Had Mc 88K been designed when 1μ was available instead
> >>> of 1.5μ, the 88K would have been 64-bit from the get-go. Yet the design world
> >>> was abuzz with RISC from just after the first tape-out capabilities of 2μ. This
> >>> timing is what lead to I32LP64 problems.
> > <
> >> If a program is small enough to easily fit into a 32-bit address
> >> space, there is often no advantage to using 64 bit pointers,
> >> they use more memory and cache.
> > <
> > Having an application that can fit into a 32-bit memory model is a compiler
> > thing, not a requirement on HW. For example, a purely 64-bit machine like
> > My 66000 can leave pointers as 32-bits in memory should that be a reasonable
> > choice for that piece of SW. The SW ensemble just needs to arrange all of
> > the memory be addressable in 32-bits {stack, heap, code, data, bss, and library
> > load points.} The compiled code is then free to use 32-bit containers for pointers
> > and still use the std ABI.
<
> We're I32LP64, and can't use your trick due to having a shared SAS,
> which would overflow 32 bits. But as a compiler guy, I really wouldn't
> like to have to use 32-bit pointers on a 64-bit address space - too much
> nuisance with extending, and libraries, and software assumptions.
<
Yes, SAS creates its own issues.
<
But this verifies that "its a SW problem".

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Wednesday, January 26, 2022 at 3:14:39 PM UTC-6, Thomas Koenig wrote:

>> There are a few applications where 64 bit data makes sense,
>> crypto being among them.
><
> data base,
> galaxy modeling,
> Quantum [electro,chroma]dynamics simulations
> And strangely NOT
> 3D Navier-Stokes CFD

I was talking about integer only :-)

32-bit floating point is woefully inadequate for what passes for
large-scale CFD these days.

> We're I32LP64, and can't use your trick due to having a shared SAS, which
> would overflow 32 bits. But as a compiler guy, I really wouldn't like to
> have to use 32-bit pointers on a 64-bit address space - too much nuisance
> with extending, and libraries, and software assumptions.

It can be a PITA, indeed. But it's probably OK in the case where your
machine is small enough that you can limit the total virtual memory
to 32bit.

Of course, if you want to play games like Mill's stacklets and its
fork-trick, which eat up into the bits of your address space, then
32bits-total will probably translate to less than 1GB of virtual memory.
Whether there are still systems in this corner of the world to justify
such a development, I don't know (seems unlikely: those applications
are probably not pointer heavy and would thus work just as well with
64bit pointers).

Stefan

On 1/26/2022 2:17 PM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Wednesday, January 26, 2022 at 3:14:39 PM UTC-6, Thomas Koenig wrote:
>
>>> There are a few applications where 64 bit data makes sense,
>>> crypto being among them.
>> <
>> data base,
>> galaxy modeling,
>> Quantum [electro,chroma]dynamics simulations
>> And strangely NOT
>> 3D Navier-Stokes CFD
>
> I was talking about integer only :-)
>
> 32-bit floating point is woefully inadequate for what passes for
> large-scale CFD these days.

FP seems to migrate in both directions these days: more precise physical
quantities, and less precise mesh weights.

On Wednesday, January 26, 2022 at 4:18:01 PM UTC-6, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Wednesday, January 26, 2022 at 3:14:39 PM UTC-6, Thomas Koenig wrote:
>
> >> There are a few applications where 64 bit data makes sense,
> >> crypto being among them.
> ><
> > data base,
> > galaxy modeling,
> > Quantum [electro,chroma]dynamics simulations
> > And strangely NOT
> > 3D Navier-Stokes CFD
> I was talking about integer only :-)
>
> 32-bit floating point is woefully inadequate for what passes for
> large-scale CFD these days.
<
I guess you missed my subtle point::
<
When the dataset being crunched in CFD becomes bigger than is easily
supported in 32-bit address space, the CPU time has already become longer
then the expected lifetime of the system doing the calculations.

EricP <ThatWouldBeTelling@thevillage.com> wrote:
> Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> Alpha didn't have SEXT/ZEXT sign/zero extend instructions
>>> so it would have required a pair of shifts.
>>
>> Alpha uses addl for sign extension and some zap instruction for zero
>> extension. If they had not added addl, they could have added an sext
>> instruction instead.
>
> There were lots of instructions they could have had, but they seemed
> almost obsessive that the R in RISC means reduced instruction _count_.
>
> They left out the byte and word load and stores, supposedly because
> that would require the byte shifter network on the critical path.
> I think that was a disastrous decision that contributed greatly
> to porting difficulties and lack of wide market acceptance.
> Once it established in peoples minds that it is difficult to work with
> or more trouble than its worth, it is tough to come back from.
> In effect, they created a market barrier to themselves.
>
> And when they finally did add byte and word load and store,
> load byte and word only did zero extend not sign extend
> supposedly because they did not want to put the sign extension
> logic into the load critical path. But still, WTF!

Loads are so variable that they should have bit the bullet and supported 2
cycle signed loads in addition to 1 cycle unsigned loads. RISC religion
stupidity.

> Anyway, SEXT and ZEXT to sign or zero extend a register from
> a bit position would not have affected the cycle time.

On Wednesday, January 26, 2022 at 7:38:07 PM UTC-6, gg...@yahoo.com wrote:
> EricP <ThatWould...@thevillage.com> wrote:
> > Anton Ertl wrote:
> >> EricP <ThatWould...@thevillage.com> writes:
> >>> Alpha didn't have SEXT/ZEXT sign/zero extend instructions
> >>> so it would have required a pair of shifts.
> >>
> >> Alpha uses addl for sign extension and some zap instruction for zero
> >> extension. If they had not added addl, they could have added an sext
> >> instruction instead.
> >
> > There were lots of instructions they could have had, but they seemed
> > almost obsessive that the R in RISC means reduced instruction _count_.
> >
> > They left out the byte and word load and stores, supposedly because
> > that would require the byte shifter network on the critical path.
> > I think that was a disastrous decision that contributed greatly
> > to porting difficulties and lack of wide market acceptance.
> > Once it established in peoples minds that it is difficult to work with
> > or more trouble than its worth, it is tough to come back from.
> > In effect, they created a market barrier to themselves.
> >
> > And when they finally did add byte and word load and store,
> > load byte and word only did zero extend not sign extend
> > supposedly because they did not want to put the sign extension
> > logic into the load critical path. But still, WTF!
<
> Loads are so variable that they should have bit the bullet and supported 2
> cycle signed loads in addition to 1 cycle unsigned loads. RISC religion
> stupidity.
<
How do you do this when an ADD takes 3/4 of a cycle and an SRAM
access takes 1+1/8 cycle, and the sign extension aligner takes 3/8 cycle ?
<
> > Anyway, SEXT and ZEXT to sign or zero extend a register from
> > a bit position would not have affected the cycle time.

> Please go back to the several rounds where primarily Mitch and I have
> discussed how zero-cycle handling of subnormal numbers can fall out of
> having the large normalization network needed to support FMAC, which you
> need to do anyway.

IIRC, FMAC wasn't part of IEEE back in the DEC days.

Stefan

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Wednesday, January 26, 2022 at 4:18:01 PM UTC-6, Thomas Koenig wrote:
>> MitchAlsup <Mitch...@aol.com> schrieb:
>> > On Wednesday, January 26, 2022 at 3:14:39 PM UTC-6, Thomas Koenig wrote:
>>
>> >> There are a few applications where 64 bit data makes sense,
>> >> crypto being among them.
>> ><
>> > data base,
>> > galaxy modeling,
>> > Quantum [electro,chroma]dynamics simulations
>> > And strangely NOT
>> > 3D Navier-Stokes CFD
>> I was talking about integer only :-)
>>
>> 32-bit floating point is woefully inadequate for what passes for
>> large-scale CFD these days.
><
> I guess you missed my subtle point::
><
> When the dataset being crunched in CFD becomes bigger than is easily
> supported in 32-bit address space, the CPU time has already become longer
> then the expected lifetime of the system doing the calculations.

Huh?

My CFD machine at work has 512 GB main memory. This may be a
bit excessive, 256 GB might have done. I have certainly have
run CFD jobs using 128 GB on occasion. (This rather high memory
requirements comes from using Finite Elements and sometimes direct
solvers, which are much more stable and use far more memory).

But even with iterative solvers and finite volume codes, 32 bits
stopped being enough for the kind industrial CFD done at the
company I worked for around 20 years ago.

These days, you will want around 8 GB per core of main memory
(rough rule of thumb) for CFD.

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> We're I32LP64, and can't use your trick due to having a shared SAS, which
>> would overflow 32 bits. But as a compiler guy, I really wouldn't like to
>> have to use 32-bit pointers on a 64-bit address space - too much nuisance
>> with extending, and libraries, and software assumptions.
>
> It can be a PITA, indeed. But it's probably OK in the case where your
> machine is small enough that you can limit the total virtual memory
> to 32bit.

Linux still has the x32 ABI, and a program which has a known memory
footprint can profit from that. A lot of system utilities fall into
that category - even given the recent tendency for software bloat,
I very much doubt that "cat" will use mutiple gigabytes of memory.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Wednesday, January 26, 2022 at 12:13:38 PM UTC-6, Thomas Koenig wrote:
>> EricP <ThatWould...@thevillage.com> schrieb:
>> > They left out the byte and word load and stores, supposedly because=20
>> > that would require the byte shifter network on the critical path.

The story I have heard is that they required ECC for write-back caches
(and parity for write-through caches); while the first implementations
had write-through D-caches, they designed the architecture for
implementations with write-back D-caches, and there byte stores would
have cost either ECC on the byte level (50% overhead compared to ~20%
for ECC on 32-bit units) or implementing stores by performing a
read-modify-write of a larger unit.

Funnily, they introduced byte stores before they introduced an
implementation with a write-back D-cache.

I guess that these days, with a relatively large write-combining store
buffer, the RMW cost is acceptable.

>> Alpha also had the highest frequencies at the time. This sort of=20
>> decision might have been taken to reduce gate delays.
><
>Squeezing DCache access into 2 cycles, Requiring tiny L1s.

The 21064 has 3 cycles of load latency, but they achieved two cycles
in the 21164. And then they added byte loads (and stores) in the
21164a without increasing the latency.

>Now, fast GBOoO machines have allowed Load latency to slip on out to 4
>cycles

Intel has been at 5 cycles load latency since Tiger Lake.

>Now, with Meltdown and Spectr=C3=A9, and with SRAMs no faster than "a bit
>more than" 1 full cycle, and with wire delay a lot harder, and the need=20
>for non-tiny L1 caches, designers cannot make the LD latency less than=20
>3-cycles, and if we push frequency, these invariably become 4-cycles.

Yes, Apple does 3 cycles at 3GHz (for IIRC a 128KB D-cache), Intel
does 5 cycles at 5GHz (for a 48KB D-cache), or 4 cycles at 5GHz for a
32KB D-cache. AFAIK ARM does 2 cycles at ~2GHz for the Cortex-A53.

>3-cycles is enough that you know at forwarding time if the LD is got a
>hit--so you are not flying blind with data--the exact exploit meltdown
>and Spectr=C3=A9 abuse.

It's Meltdown, not Spectre. Either vulnerability requires using the
result in another instruction to reveal the data through a side
channel, so you can fly blind if you cancel the followup before the
followup reveals the result through a side channel. With the Spectre
fix by not letting microarchitectural updates out of the speculative
part, canceling the followup always happens as far as
microarchitectural state is concerned; one still may want to squash
the resulting data early as defense in depth, if someone overlooked
some other side channel.

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

Ivan Godard <ivan@millcomputing.com> writes:
>We're I32LP64, and can't use your trick due to having a shared SAS,
>which would overflow 32 bits. But as a compiler guy, I really wouldn't
>like to have to use 32-bit pointers on a 64-bit address space - too much
>nuisance with extending, and libraries, and software assumptions.

No need to. There has been a lot of noise about how great 32-bit is
for efficiency of applications that fit into 4GB, and that has led to
the x32 ABI effort to get the real performance benefits of AMD64
(e.g., having more registers) together with the supposed performance
benefits of 32-bit stuff. But the reality is that it's so rare to see
significant benefits from 32 bits that x32 never really took off.

Ok, you might say, that's because Linux already has support for
running IA-32 (i386) binaries, so the critical mass for x32 was
missing. But nowadays Linux distributions are in the process of
dropping IA-32 support; there is still support for running old IA-32
binaries, but that's pretty much all; not really support for compiling
new binaries, so apparently nobody is keen to use the supposed 32-bit
advantage, neither with the x32 ABI, nor with i386 ABI.

So I think you don't need to worry about that for the Mill. Other
deviations from convention are more likely to become a problem.

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

Thomas Koenig <tkoenig@netcologne.de> writes:
>Linux still has the x32 ABI,

Not really.

>and a program which has a known memory
>footprint can profit from that.

That was the justification for x32, but the benefit/cost ratio was too
low for it to take off. And unlike the undefined-behaviour-based
"optimizations" that are justified with similar arguments, x32 was not
force-fed to the developers, and as a result, it did not gain
traction. Maybe it would have fared better if it had become the
default of all major compilers, requiring an obscure and ever-growing
list of options to avoid (like we need to avoid "optimizations").

>I very much doubt that "cat" will use mutiple gigabytes of memory.

Maybe (see below), but where is the supposed profit of avoiding 64-bit
pointers in cat?

As for not "using" multiple GBs of memory: If you cat a multi-GB file,
why not? mmap() the file into the address space, which avoids one
copy, and then write out the result. Of course, with
copy_file_range() on Linux, I guess you can do it with zero copies and
without using a lot of address space. That being said, a test of

strace cat bigfile >/dev/null

produces a sequence of 128KB read()s alternating with 128KB write()s
(cat (GNU coreutils) 8.32).

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

Stefan Monnier wrote:
>> Please go back to the several rounds where primarily Mitch and I have
>> discussed how zero-cycle handling of subnormal numbers can fall out of
>> having the large normalization network needed to support FMAC, which you
>> need to do anyway.
>
> IIRC, FMAC wasn't part of IEEE back in the DEC days.

That is correct, and I was hoping to slip one past you. :-)

More seriously: If you start with the assumption that you have to live
with a single shifter of up to 57/58/64 bits, and this one must handle
all fp normalization, then the only fast path is to keep all variables
normalized both before and after each operation.

I.e. you need to pre-normalize all subnormal inputs, each such will best
case cause a single-cycle stall, worst case a trap.

If otoh you have seen the great use you can get out of a double-wide
shifter (allowing things like arbitrarily aligned bit field extraction
from a pair of 64-bit registers), then you have already bit this
particular bullet and at this point the world is wide open:

You can handle all subnormal inputs without any pre-normalization step,
and you can also handle the near-catastrophic cancellations which are
typical whenever you use FMAC to provide better precision.

Terje

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

Anton Ertl wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> On Wednesday, January 26, 2022 at 12:13:38 PM UTC-6, Thomas Koenig wrote:
>>> EricP <ThatWould...@thevillage.com> schrieb:
>>>> They left out the byte and word load and stores, supposedly because=20
>>>> that would require the byte shifter network on the critical path.
>
> The story I have heard is that they required ECC for write-back caches
> (and parity for write-through caches); while the first implementations
> had write-through D-caches, they designed the architecture for
> implementations with write-back D-caches, and there byte stores would
> have cost either ECC on the byte level (50% overhead compared to ~20%
> for ECC on 32-bit units) or implementing stores by performing a
> read-modify-write of a larger unit.

That seems reasonable too, except Alpha has 32 bit stores and,
assuming they used the standard off-the-shelf 64+8 bit ECC DRAM,
those dword stores would require a read-modify-write memory cycle
and recomputing SECDED ECC. From the text below, it would seem
that they used a different ECC applied to 32 bit words,
which implies they did not used standard 72 bit DRAM DIMMs
(which in turn would have hit them on main memory cost).

Richard Sites, credited as an Alpha co-architect, gives reasons in
"Alpha AXP Architecture" 1993 and supports both views:

"The byte load/store instructions and unaligned accesses found in
some RISC architectures can be a performance bottleneck. They require
an extra byte shifter in the speed-critical load and store paths,
and they force a hard choice in fast cache design."
....
"On a previous project involving a MIPS implementation, we found the
shifter for the load-left/load-right instructions to be a direct
cycle-time bottleneck. Also, the VAX 8700 implementation (circa 1986)
removed the byte shifter in the load/store hardware in favor of a faster
microcycle, with 2 cycles for a byte load and 6 cycles for an unaligned
32-bit access. This decision achieved a net performance gain.
Our experience encouraged us to avoid byte load/store.

An additional problem with byte stores is that an implementer may easily
choose only two of the three design features: fast write-back cache,
single-bit error correction code (ECC), or byte stores.

Byte stores are straightforward in simple byte parity write-through cache
implementations. Except for the expensive design of four or five ECC bits
for every eight bits of data, a byte store to a fast ECC write-back cache
involves
1. Reading an entire cache word
2. Checking the ECC bits and correcting any single bit error
3. Modifying the byte
4. Calculating the new ECC bits
5. Writing the entire cache word

This read-modify-write sequence requires hidden sequencer hardware and
hidden state to hold the cache word temporarily. The sequencer tends to
slow down ordinary full-cache-word stores. The need for byte stores tends
to ripple throughout the memory subsystem design, making each piece a
little more complicated and a little slower. With non-replicated
hidden state, it is difficult to issue another byte store until the
first one finishes."

> Funnily, they introduced byte stores before they introduced an
> implementation with a write-back D-cache.

And according to DEC benchmarks, code got faster and smaller
so it would seem that many of the assumptions used to
justify leaving out byte/word were not correct.

Maybe later implementations switched to using 72 bit DIMMs
so it was doing the RMW for 32-bit dwords anyway.

> I guess that these days, with a relatively large write-combining store
> buffer, the RMW cost is acceptable.

x86 has its virtually tagged write combine buffers.
I don't know if anyone else does.