At present, we have competing interest of 8-bit FP and 128-bit FP giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
At present, we have competing interest of 8-bit FP and 128-bit FP
giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the
coming decade (or farther out) ??
MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving
5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
As long as fp128 supports the Augmented(Add/Mul) operations, this will almost certainly be sufficient for many decades to come.
Having those two operations available means that the only thing you
would gain from pure fp256, besides marginally faster 256-bit
operations, is an even larger exponent range, but fp128 is already quite large.
On Tue, 28 Jul 2026 19:40:28 GMT, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP
giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the
coming decade (or farther out) ??
I was thinking of date/time formats. POSIX already seems to be moving
to offering the option of nanosecond granularity; an unsigned 64-bit
integer could measure a duration of (by my calculation) up to about
584 years with such a unit.
But will that be enough? I can imagine scientific uses which might
require a timescale that goes all the way to the Big Bang (13.7
billion years ago). Using the smallest possible time unit, the Planck interval of about 10 ** -43 seconds, you would need an integer (or a mantissa) of about 201 bits.
In other words, 256 bits ought to be plenty for that particular
application of time measurement.
On Tue, 28 Jul 2026 19:40:28 GMT, MitchAlsup wrote:I worked on NTP for about 25 years, unix have had seconds + nanoseconds
At present, we have competing interest of 8-bit FP and 128-bit FP
giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the
coming decade (or farther out) ??
I was thinking of date/time formats. POSIX already seems to be moving
to offering the option of nanosecond granularity; an unsigned 64-bit
integer could measure a duration of (by my calculation) up to aboutYeah.
584 years with such a unit.
But will that be enough? I can imagine scientific uses which might
require a timescale that goes all the way to the Big Bang (13.7
billion years ago). Using the smallest possible time unit, the Planck interval of about 10 ** -43 seconds, you would need an integer (or a mantissa) of about 201 bits.
In other words, 256 bits ought to be plenty for that particular
application of time measurement.
On 7/28/2026 5:58 PM, Lawrence D|ore4raoOliveiro wrote:>> On Tue, 28 Jul 2026 19:40:28 GMT, MitchAlsup wrote:microseconds are far too coarse resolution!
At present, we have competing interest of 8-bit FP and 128-bit FP
giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the
coming decade (or farther out) ??
I was thinking of date/time formats. POSIX already seems to be moving
to offering the option of nanosecond granularity; an unsigned 64-bit
integer could measure a duration of (by my calculation) up to about
584 years with such a unit.
My vote personally would be 64-bit microseconds:
-a Microseconds are more general / less overkill than nanoseconds;> -a Epoch will likely be long enough to cover all of human civilization;
-a-a-a More so if the epoch is set in the future.
On 7/28/2026 5:58 PM, Lawrence DrCOOliveiro wrote:
On Tue, 28 Jul 2026 19:40:28 GMT, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP
giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the
coming decade (or farther out) ??
I was thinking of date/time formats. POSIX already seems to be moving
to offering the option of nanosecond granularity; an unsigned 64-bit
integer could measure a duration of (by my calculation) up to about
584 years with such a unit.
My vote personally would be 64-bit microseconds:
-a Microseconds are more general / less overkill than nanoseconds;
-a Epoch will likely be long enough to cover all of human civilization;
-a-a-a More so if the epoch is set in the future.
Well, there is possible debate here:
Humanity as we know it would probably be extinct by them, but some descendants of humanity could well still exist.
Hard to predict the long term future of humanity:
-a Will remain similar ? ;
-a Or, re-engineer themselves into something unrecognizable;
-a Or, merge with machinery and synthetic biology;
-a Or, be replaced by machinery;
-a ...
We can't really use past history to predict the future here, as humanity
now has access to tools that no life on Earth has had, and it is absurd
to think no one, no where will use them. And, if even only a rare few
here and there start doing germline edits, the long term trajectory
becomes a wildcard.
Like, a modern human going to the far future, and see what looks almost
like humans, maybe a little different, or a little strange (their skin
and eyes seeming a bit off, etc), doing things that maybe seem incomprehensible.
One might realize that there are no farm animals, not because everyone became vegan or something, but because their role had been replaced by
ever growing sausage logs. They might question why anyone would choose
to kill an animal for food rather than cut a piece off the desired
flavor of meat log or something. Well, or giant tentacled meat slugs
that regularly shed flavored meaty tentacles or something (and consume
an endless supply of hay bales or something).
Well, and modern person sees it, and wonders why anyone would replace
farm animals with eldritch monstrosities.
Maybe they still reproduce as before, maybe they decided it would have
been better if new children emerge from eggs or something (since with
eggs one can greatly externalize the cost of the reproductive process).
The person goes by the nursery, seeing the recent larva-like hatchlings crawling around and gorging themselves on slime. And wonders just what
they are looking at, and how humanity could have gone in such a direction.
Well, and/or everything comes under the control of centralized
authorities, then it is just doomed.
But will that be enough? I can imagine scientific uses which might
require a timescale that goes all the way to the Big Bang (13.7
billion years ago). Using the smallest possible time unit, the Planck
interval of about 10 ** -43 seconds, you would need an integer (or a
mantissa) of about 201 bits.
In other words, 256 bits ought to be plenty for that particular
application of time measurement.
You could make a clock that measures from the origin to the heat death
of the universe.
Do you need it?...
You could also use 256-bit floats for the time, they are sufficiently overkill for this...
Just how much usable range does one have by representing the time as a Binary128 value in seconds from Jan 1st 1970?...
Or, Binary64?...
At 2038, could still have microsecond precision with a 'double'; but go
a few centuries and you no longer have microseconds.
With Binary128, could put the epoch at the big bang and still have picosecond accuracy in the present.
...
At present, we have competing interest of 8-bit FP and 128-bit FP giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
On Tue, 28 Jul 2026 19:40:28 GMT, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP
giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the
coming decade (or farther out) ??
I was thinking of date/time formats.
I was thinking of date/time formats. POSIX already seems to be movingWell, there is possible debate here:
to offering the option of nanosecond granularity; an unsigned 64-bit integer could measure a duration of (by my calculation) up to about
584 years with such a unit.
Humanity as we know it would probably be extinct by them, but some descendants of humanity could well still exist.
At present, we have competing interest of 8-bit FP and 128-bit FP giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
Mitch
On 2026-Jul-28 15:40, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving
5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
Mitch
I see that IBM in 390 since 1998 and Power support IEEE binary128 FP in hardware.
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Hardware_support
Who uses binary128 and for what?
Who uses double-double or quad-double libraries and for what?
BGB <cr88192@gmail.com> writes:
I was thinking of date/time formats. POSIX already seems to be movingWell, there is possible debate here:
to offering the option of nanosecond granularity; an unsigned 64-bit
integer could measure a duration of (by my calculation) up to about
584 years with such a unit.
Humanity as we know it would probably be extinct by them, but some
descendants of humanity could well still exist.
I vote that the human/cockroach hybrids can figure out their own
d*mn date/time format.
At present, we have competing interest of 8-bit FP and 128-bit FP giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giving
5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit. Which means that it is much slower than an implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
On Tue, 28 Jul 2026 19:40:28 GMT, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP
giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the
coming decade (or farther out) ??
I was thinking of date/time formats. POSIX already seems to be moving
to offering the option of nanosecond granularity; an unsigned 64-bit
integer could measure a duration of (by my calculation) up to about
584 years with such a unit.
But will that be enough? I can imagine scientific uses which might
require a timescale that goes all the way to the Big Bang (13.7
billion years ago). Using the smallest possible time unit, the Planck interval of about 10 ** -43 seconds, you would need an integer (or a mantissa) of about 201 bits.
In other words, 256 bits ought to be plenty for that particular
application of time measurement.
On 2026-07-28 6:58 p.m., Lawrence DrCOOliveiro wrote:
On Tue, 28 Jul 2026 19:40:28 GMT, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP
giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the
coming decade (or farther out) ??
I was thinking of date/time formats. POSIX already seems to be moving
to offering the option of nanosecond granularity; an unsigned 64-bit
integer could measure a duration of (by my calculation) up to about
584 years with such a unit.
But will that be enough? I can imagine scientific uses which might
require a timescale that goes all the way to the Big Bang (13.7
billion years ago). Using the smallest possible time unit, the Planck
interval of about 10 ** -43 seconds, you would need an integer (or a
mantissa) of about 201 bits.
In other words, 256 bits ought to be plenty for that particular
application of time measurement.
Is the Planck interval also the smallest possible distance measurement,
distance and time being essentially the same thing in space-time, just rotated?
May greater precision/range be required for measurements of a multi-
verse, where the Planck constant may vary? If so 256-bit might be
useful. I wonder if it may be needed for multi-verse simulations.
I am thinking of usefulness for inter-dimensional travels.
Supporting potentially more than four sizes for FP in an ISA could be accomplished using additional opcodes. As long as there are a few
opcodes available whether or not 256 bit FP is supported could be left
to future processor versions.
Is the Planck interval also the smallest possible distance
measurement, distance and time being essentially the same thing in space-time, just rotated?
May greater precision/range be required for measurements of a
multi-verse, where the Planck constant may vary?
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giving
5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit. Which means that it is much slower than an implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
Formalization of double-word arithmetic, and comments on rCLtight and rigorous error bounds for basic building blocks of double-word arithmeticrCY, JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514 https://dl.acm.org/doi/pdf/10.1145/3484514
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
On 2026-Jul-28 15:40, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving
5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
Mitch
I see that IBM in 390 since 1998 and Power support IEEE binary128 FP in hardware.
https://en.wikipedia.org/wiki/Quadruple-precision_floating- point_format#Hardware_support
Who uses binary128 and for what?
Who uses double-double or quad-double libraries and for what?
On 7/29/2026 10:14 AM, EricP wrote:
On 2026-Jul-28 15:40, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>> 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
Mitch
I see that IBM in 390 since 1998 and Power support IEEE binary128 FP
in hardware.
https://en.wikipedia.org/wiki/Quadruple-precision_floating-
point_format#Hardware_support
Who uses binary128 and for what?
128 fp for a deeper zoom into a fractal?
Who uses double-double or quad-double libraries and for what?
https://youtu.be/0jGaio87u3A?list=PLlmERjBA7oggjn4C-ZFIjMPKtRw4V3Hra
There are other things as well. Needed damn near arbitrary precision.
There are other things as well. Needed damn near arbitrary
precision.
On Fri, 31 Jul 2026 13:50:32 -0700, Chris M. Thomasson wrote:
There are other things as well. Needed damn near arbitrary
precision.
I did some experimentation with PythonrCOs Decimal type at one point.
The first thing anybody tries is computing -C to lots of decimal
places, of course. I also did a comparison of algorithms involving
continued fractions.
Vertict: theyrCOre bloody useless. Mathematicians seem fond of them, but convergence is absolutely terrible.
<https://github.com/HamPUG/meetings/blob/master/2022/2022-11-14/ldo/Continued%20Fractions.ipynb>
<https://mathworld.wolfram.com/topics/ContinuedFractions.html> <https://docs.python.org/3/library/decimal.html>
On Fri, 31 Jul 2026 13:50:32 -0700, Chris M. Thomasson wrote:
There are other things as well. Needed damn near arbitrary
precision.
I did some experimentation with PythonrCOs Decimal type at one point.
The first thing anybody tries is computing -C to lots of decimal
places, of course. I also did a comparison of algorithms involving
continued fractions.
Vertict: theyrCOre bloody useless. Mathematicians seem fond of them, but convergence is absolutely terrible.
<https://github.com/HamPUG/meetings/blob/master/2022/2022-11-14/ldo/Continued%20Fractions.ipynb>
<https://mathworld.wolfram.com/topics/ContinuedFractions.html> <https://docs.python.org/3/library/decimal.html>
Also, I have ran into issues using normal floats in the GPU for trying
to see if two lines intersect, or the intersections of two circles. If
they are really tight, things can occur. Say two circles that are
tangent. Well, if I move one a way by a really small epsilon, its still
said tangent. Even though they are not. But visually, they might as well
be. If I zoom in really deep I can kind of see a separation.
Then if I move it in by a little I see intersect and get the two points
of intersection. Their delta is TINY!
Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
Also, I have ran into issues using normal floats in the GPU for trying
to see if two lines intersect, or the intersections of two circles. If
they are really tight, things can occur. Say two circles that are
tangent. Well, if I move one a way by a really small epsilon, its still
said tangent. Even though they are not. But visually, they might as well
be. If I zoom in really deep I can kind of see a separation.
The line which would be the tangent, or on which the intersections
would be, can be found in a straightforward manner. If your
circles are defined by
(x-xm1)**2 + (y-ym1)**2 = r1**2
(x-xm2)**2 + (y-ym2)**2 = r2**2
you multiply out everything and subtract the two equations. The
quadratic terms in x and y cancel out. After rearrangement, you are
then left with the equation for a straight line in the form
a*x + b*y + c = 0
which is well-defined for (xm1-xm2)**2 + (ym1-ym2)**2 > 0 (in other
words, if the center points do not coincide).
The distance between the circles is of course easy to calculate
from the distance of the center points and the radii, so you can
determine if the circles have one zero, one or two intersecting
point IF (and this is a big if) you define what "one point" means
within the accuracy and within the rounding errors that will
aoccur.
Then if I move it in by a little I see intersect and get the two points
of intersection. Their delta is TINY!
And the position is very sensitive to the distance, and to rouning
error, if the two circles are very close to having one common point.
128 fp for a deeper zoom into a fractal?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set. So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand. So 128-bit fixed-point with the
total range of [-4,4] is a better choice. Can we make do with [-4,4),
which is easier to implement? Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit fixed-point and probably want to go for fixed-point based on BigNums (variable-length arbitrary-precision big integers).
<https://weitz.de/mandelbrot/> says:
|The program will initially use 64-bit floating-point numbers for its |computations. If, at high zoom rates, it figures out that this
|wouldn't be accurate enough anymore, it automatically switches to a |home-grown fixed-point arithmetic with a variable bit size.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set. So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand. So 128-bit fixed-point with the
total range of [-4,4] is a better choice. Can we make do with [-4,4),
which is easier to implement? Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit fixed-point and probably want to go for fixed-point based on BigNums (variable-length arbitrary-precision big integers).
<https://weitz.de/mandelbrot/> says:
|The program will initially use 64-bit floating-point numbers for its |computations. If, at high zoom rates, it figures out that this
|wouldn't be accurate enough anymore, it automatically switches to a |home-grown fixed-point arithmetic with a variable bit size.
- anton
On 01/08/2026 4:39 PM, Anton Ertl wrote:
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set. So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand. So 128-bit fixed-point with the
total range of [-4,4] is a better choice. Can we make do with [-4,4),
which is easier to implement? Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit
fixed-point and probably want to go for fixed-point based on BigNums
(variable-length arbitrary-precision big integers).
You could also put on some elbow grease, and implement your own arbitrary >precision floating point library. Tom St Denis wrote a nice book about
the integer parts in /BigNum Math/ and adding an extra exponent doesn't
seem so hard.
<https://weitz.de/mandelbrot/> says:
|The program will initially use 64-bit floating-point numbers for its
|computations. If, at high zoom rates, it figures out that this
|wouldn't be accurate enough anymore, it automatically switches to a
|home-grown fixed-point arithmetic with a variable bit size.
- anton
And I wonder if that's better than arbitrary precision floating point?
Possibly in the context of Mandelbrot.
On 8/1/2026 1:39 AM, Anton Ertl wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set. So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand. So 128-bit fixed-point with the
total range of [-4,4] is a better choice. Can we make do with [-4,4),
which is easier to implement? Probably.
Well, we zoom into say a point with a range of, well for the x and y of
the complex number say:
(-.00000000000000000000000000000000000000000000000000000001, >+-.00000000000000000000000000000000000000000000000000000001)
With billions of iterations...
On 2026-Jul-29 16:39, Thomas Koenig wrote:Augmented[Addition|Multipication] was defined all the way back in ieee754-2019, so I expected new designs to consider supporting that by now. Terje
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>> 5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.-a Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming>>> decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a-a bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
Formalization of double-word arithmetic, and comments on |ore4+otight and rigorous error bounds for basic building blocks of double-word arithmetic|ore4-Y,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514 https://dl.acm.org/doi/pdf/10.1145/3484514
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giv= >ing
5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.=C2=A0 Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming=
=20decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a=C2=A0 bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
=20
Formalization of double-word arithmetic, and comments on =C3=A2=E2=82=AC= >=C5=93tight and
rigorous error bounds for basic building blocks of double-word=20
arithmetic=C3=A2=E2=82=AC=C2=9D,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514
https://dl.acm.org/doi/pdf/10.1145/3484514
=20
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in=20 >ieee754-2019, so I expected new designs to consider supporting that by no=
w.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:Arbitrary precision works well here... :^)
On 8/1/2026 1:39 AM, Anton Ertl wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set. So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand. So 128-bit fixed-point with the
total range of [-4,4] is a better choice. Can we make do with [-4,4),
which is easier to implement? Probably.
Well, we zoom into say a point with a range of, well for the x and y of
the complex number say:
(-.00000000000000000000000000000000000000000000000000000001,
+-.00000000000000000000000000000000000000000000000000000001)
With billions of iterations...
If you want to make an argument, make it. Of course, first work it
out.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:We can get rather deep:
On 8/1/2026 1:39 AM, Anton Ertl wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set. So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand. So 128-bit fixed-point with the
total range of [-4,4] is a better choice. Can we make do with [-4,4),
which is easier to implement? Probably.
Well, we zoom into say a point with a range of, well for the x and y of
the complex number say:
(-.00000000000000000000000000000000000000000000000000000001,
+-.00000000000000000000000000000000000000000000000000000001)
With billions of iterations...
If you want to make an argument, make it. Of course, first work it
out.
Terje Mathisen <terje.mathisen@tmsw.no> writes:
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:ing
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giv=
5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.=C2=A0 Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming=
=20decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a=C2=A0 bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
=20
Formalization of double-word arithmetic, and comments on =C3=A2=E2=82=AC= >> =C5=93tight and
rigorous error bounds for basic building blocks of double-word=20
arithmetic=C3=A2=E2=82=AC=C2=9D,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514
https://dl.acm.org/doi/pdf/10.1145/3484514
=20
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in=20
ieee754-2019, so I expected new designs to consider supporting that by no= >> w.
I would submit that a reason that 128-bit binary FP has not
been supported by new designs is that the use-cases for it are
rare and in niche applications where software solutions
are sufficient (if not performant). AI[*] and/or packet accelerators
are a more fruitful use of chiplet area in the current environment.
[*] e.g. various sub-32-bit floating point formats.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set. So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand. So 128-bit fixed-point with the
total range of [-4,4] is a better choice. Can we make do with [-4,4),
which is easier to implement? Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit fixed-point and probably want to go for fixed-point based on BigNums (variable-length arbitrary-precision big integers).
<https://weitz.de/mandelbrot/> says:
On 8/1/2026 1:39 AM, Anton Ertl wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set.-a So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand.-a So 128-bit fixed-point with the
total range of [-4,4] is a better choice.-a Can we make do with [-4,4),
which is easier to implement?-a Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit
fixed-point and probably want to go for fixed-point based on BigNums
(variable-length arbitrary-precision big integers).
<https://weitz.de/mandelbrot/> says:
I tried downloading the program to play with it, but Windows Defender wouldn't let it run as it thought the program was dangerous as it had no author.
On 01/08/2026 4:39 PM, Anton Ertl wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set.-a So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand.-a So 128-bit fixed-point with the
total range of [-4,4] is a better choice.-a Can we make do with [-4,4),
which is easier to implement?-a Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit
fixed-point and probably want to go for fixed-point based on BigNums
(variable-length arbitrary-precision big integers).
You could also put on some elbow grease, and implement your own arbitrary precision floating point library.-a Tom St Denis wrote a nice book about
the integer parts in /BigNum Math/ and adding an extra exponent doesn't> seem so hard.
<https://weitz.de/mandelbrot/> says:
|The program will initially use 64-bit floating-point numbers for its
|computations. If, at high zoom rates, it figures out that this
|wouldn't be accurate enough anymore, it automatically switches to a
|home-grown fixed-point arithmetic with a variable bit size.
- anton
And I wonder if that's better than arbitrary precision floating point?
Possibly in the context of Mandelbrot.
On 02/08/2026 8:17 AM, Stephen Fuld wrote:
On 8/1/2026 1:39 AM, Anton Ertl wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values
of |c|<0.25 are definitely inside the set.-a So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand.-a So 128-bit fixed-point with the
total range of [-4,4] is a better choice.-a Can we make do with [-4,4),
which is easier to implement?-a Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit
fixed-point and probably want to go for fixed-point based on BigNums
(variable-length arbitrary-precision big integers).
<https://weitz.de/mandelbrot/> says:
I tried downloading the program to play with it, but Windows Defender
wouldn't let it run as it thought the program was dangerous as it had
no author.
I don't know how you have your security settings, but there's usually a
way to get past that prompt.-a Something like /run anyway/.-a I've had to
do that many times.-a Probably, but my memory is vague, when I installed
Caml Light, from 1997.
Best wishes, and happy Mandelbroting!
It _might_ be more efficient to use a 8:56... format because that allows =
the normalizations to be simple byte shifts instead of a loop of SHRD=20 >operations.
If we implement 3:125 in the obvious way, multiplication needs 4=20 >64x64->128 MULs 3 ADD and 3 ADC, then do the rounding, followed by a=20
test for overflow (typically just a CMP that is correctly predicted to=20
not be taken, then the final SHRD + SHR.
Several of these operations can overlap, so the total latency should not =
be much more than 2.5 to 3 times the MUL time, right?
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>> 5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.-a Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a-a bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
Formalization of double-word arithmetic, and comments on |ore4+otight and rigorous error bounds for basic building blocks of double-word arithmetic|ore4-Y,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514 https://dl.acm.org/doi/pdf/10.1145/3484514
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in ieee754-2019, so I expected new designs to consider supporting that by now.
Terje
On 8/1/2026 4:33 PM, Scott Lurndal wrote:
Terje Mathisen <terje.mathisen@tmsw.no> writes:
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:=20
At present, we have competing interest of 8-bit FP and 128-bit FP giv= >> ing
5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.=C2=A0 Which means that it is much slower than an >>>> implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming= >>
decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a=C2=A0 bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
=20
Formalization of double-word arithmetic, and comments on =C3=A2=E2=82=AC= >> =C5=93tight and
rigorous error bounds for basic building blocks of double-word=20
arithmetic=C3=A2=E2=82=AC=C2=9D,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514
https://dl.acm.org/doi/pdf/10.1145/3484514
=20
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in=20
ieee754-2019, so I expected new designs to consider supporting that by no= >> w.
I would submit that a reason that 128-bit binary FP has not
been supported by new designs is that the use-cases for it are
rare and in niche applications where software solutions
are sufficient (if not performant). AI[*] and/or packet accelerators
are a more fruitful use of chiplet area in the current environment.
[*] e.g. various sub-32-bit floating point formats.
Yeah, in my own (limited) experiments with NNs, I am mostly using FP8
and FP16, even in the absence of native hardware support. The relative savings of these formats being (ironically) mostly enough to offset the
lack of native hardware support.
Though, a partial merit here being that the format conversions can also
be largely turned into lookup tables.
I haven't done much yet, but had been recently tempted to consider a non-standard FP format for weights during NN training:
S.E4.M11
Rationale:
It is cheaper to convert to/from FP8 than is normal Binary16 (S.E5.M10).
FP8 <-> Binary16: Needs a lookup table;
Modified format: Bare shift;
Naturally, the weights are already confined to FP8's dynamic range.
Though, it is debatable if this will save enough to justify the effort.
Note that more bits (then FP8) are needed to make things like back-propagation work (even when the forward propagation is all using FP8).
In a recent experiment, I decided to dust off some code from a prior experiment (trying to get an NN to do integer addition), and see if I
could get it to do next token prediction (in this test, mostly
predicting the next token in C code).
Ran into a problem that even "small" next token prediction requires very large and slow nets to have any hope of useful coverage of the token space.
Debated whether to write some new NN code specifically for the use-case
(and maybe using the newly considered intermediate weight format), but
ended up modifying the existing code to add support for sparse nets (my currently running test was still using a dense net).
The idea of a the sparse nets being that one can do, say, 16K neuron
hidden layers without each hidden layer needing 512MB and being horribly slow. So, say, one can instead use 32 or 48 inputs for each neuron (each input selected using an index), and use more around 2MB or 3MB per layer.
Though, even for a (not so large) net, the training process still ends
up taking around an hour or so to churn through all the tokens in a C
source file, which kinda sucks... But, the realization that the net is
still not big enough to even represent more than a handful of tokens,
much less make inferences about them.
But, even despite that limitation, still can get a few % at the "guess
the next token" game, where even a few percent here is "much better than chance", where in this case a pure random-chance is 1/65536, one would expect ~ .0015% at guessing the next token. Did end up having it
decompose strings and identifiers though, and eliminate one-offs, mostly because otherwise for the input file-set, was way more than the current limit of 64K unique tokens (instead, the tokenizing treats things like quotes, _ and __, etc, as operators).
Ironically, not so much in the forward stages, but more in the back-propagation and weight-update stages:
Run net forward;
Update error values based on actual and expected outputs;
Evaluate net backwards (to propagate error towards inputs);
Update weights based on input/output correlation and similar.
Ironically, one can get much more "initially impressive" results, and a
lot faster, but using an order-N Hidden Markov Model (*1), but with the limitation that one knows in advance that an HMM has an implicit
hard-limit and so can never move past a certain level of incoherent
rambling
(or occasionally repeating parts of the input sequences
verbatim when chance permits).
*1: Or, essentially a big hash table where each hash slot contains a
ranked list of tokens, and the last N tokens are used to calculate a
hash index, then use an RNG+Sqrt to select the token from that hash
slot. Usually N needs to be kept fairly low (otherwise it quickly decays into random noise).
I guess if I wanted, I could build an HMM as well, and then use the HMM
as a reference point for whether the NN is doing better or worse at
token prediction. At the moment, I suspect the HMM would have a decisive
win though. Though, NN's are better in the long run (probably a good
reason people didn't try pushing "AI" based on giant HMMs).
Then again, a counter argument could be made that in some ways an NN
being used for next-token-prediction is mostly just serving as a very computationally-inefficient way of computing a higher order token hash. Though, unclear if there could be a way to use an HMM to speed up the creation of a token-predicting NN.
...
On 8/2/2026 3:00 AM, Johann 'Myrkraverk' Oskarsson wrote:Funy that you should mention me here, I wrote several Mandelbrot
On 02/08/2026 8:17 AM, Stephen Fuld wrote:
On 8/1/2026 1:39 AM, Anton Ertl wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values>>>> of |c|<0.25 are definitely inside the set.|e-a So the dynamic range is
very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand.|e-a So 128-bit fixed-point with the >>>> total range of [-4,4] is a better choice.|e-a Can we make do with [-4,4), >>>> which is easier to implement?|e-a Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit
fixed-point and probably want to go for fixed-point based on BigNums>>>> (variable-length arbitrary-precision big integers).
<https://weitz.de/mandelbrot/> says:
I tried downloading the program to play with it, but Windows Defender
wouldn't let it run as it thought the program was dangerous as it had
no author.
I don't know how you have your security settings, but there's usually a
way to get past that prompt.|e-a Something like /run anyway/.|e-a I've had to
do that many times.|e-a Probably, but my memory is vague, when I installed >> Caml Light, from 1997.
Yes, thanks.-a For obvious reasons, I don't like to use that mechanism,
but I generally trust at least most of the people who post here, so I
did that, and it ran fine.
Quite nice, but I still preferred Fractint back in the old days.-a It had more fractals, as well as other things.-a I think it would make a good retirement project for someone, I'm looking at you Terje :-) to update > it to work on modern 64 bit processors and Windows graphics.-a It could
then be extended to support greater precision than 80 bit X87 the
original version supported.
Terje Mathisen <terje.mathisen@tmsw.no> posted:I know!
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>>>> 5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.|e-a Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming >>>>> decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a|e-a bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
Formalization of double-word arithmetic, and comments on |a-o|orCU-4|arCLtight and
rigorous error bounds for basic building blocks of double-word
arithmetic|a-o|orCU-4|e-Y,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514
https://dl.acm.org/doi/pdf/10.1145/3484514
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in
ieee754-2019, so I expected new designs to consider supporting that by now.
They provided the emphasis to add CARRY instruction-modifier
(n.e., prefix) to My 66000 ISA in the floating point side of
things.
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>>> 5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.-a Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a-a bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
Formalization of double-word arithmetic, and comments on |ore4+otight and
rigorous error bounds for basic building blocks of double-word arithmetic|ore4-Y,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514
https://dl.acm.org/doi/pdf/10.1145/3484514
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in ieee754-2019, so I expected new designs to consider supporting that by now.
Terje
MitchAlsup wrote:
Terje Mathisen <terje.mathisen@tmsw.no> posted:
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP >>>>>> giving
5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.|e-a Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming >>>>>> decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a|e-a bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
Formalization of double-word arithmetic, and comments on
|a-o|orCU-4|arCLtight and
rigorous error bounds for basic building blocks of double-word
arithmetic|a-o|orCU-4|e-Y,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514
https://dl.acm.org/doi/pdf/10.1145/3484514
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in
ieee754-2019, so I expected new designs to consider supporting that
by now.
They provided the emphasis to add CARRY instruction-modifier
(n.e., prefix) to My 66000 ISA in the floating point side of
things.
I know!
I really, really wish My 66000 was available in a machine I could afford.
On 2026-Aug-01 16:34, Terje Mathisen wrote:
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP
giving
5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.-a Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming >>>>> decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a-a bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
Formalization of double-word arithmetic, and comments on |ore4+otight and >>> rigorous error bounds for basic building blocks of double-word
arithmetic|ore4-Y,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514
https://dl.acm.org/doi/pdf/10.1145/3484514
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in
ieee754-2019, so I expected new designs to consider supporting that by
now.
Terje
Oh that's what those are. I had seen the names but not looked into it.
Yes, I was thinking as I read those papers that this cries out for
operations with two dest registers for the result and error.
A quick search of Intel manuals shows no support (yet) for
the augmented operations.
In
Emulating round-to-nearest-ties-to-zero "augmented" floating-point
operations using round-to-nearest-ties-to-even arithmetic
Boldo, Lauter, Muller, 2019
https://hal.science/hal-02137968v3/
they explain that the augmented operations are defined as using
"Round Nearest Ties to Zero" (RN0) mode whereas existing arithmetic
uses the default "Round Nearest Ties Even" (RNE) mode
which can give different results.
They say to emulate Augmented Add with RN0 using operations
in RNE mode requires the following algorithm:
ALGORITHM 7: AA-Full(EYaN, EYaa): computes
augmentedAddition(EYaN, EYaa) in all cases.
1: if |EYaa| > |EYaN| then
2:-a-a swap(EYaN, EYaa)
3: end if
4: (EYaAEYaA, EYaAEYaA) raE Fast2Sum(EYaN, EYaa)
5: (EYaA0, EYaA0) raE Recomp(EYaAEYaA, EYaAEYaA)
6: if EYaA0 = 0 then
7:-a-a EYaA0 raE (+0) |u EYaA0
8: else if |EYaAEYaA| = +reR then
9:-a-a (EYaArC#EYaA, EYaArC#EYaA) raE Fast2Sum(0.5EYaN, 0.5EYaa)
10:-a if (EYaArC#EYaA = 2EYaAmax and EYaArC#EYaA = reA2EYaAmaxreAEYaYreA1) or
-a-a-a-a-a-a-a (EYaArC#EYaA = reA2EYaAmax and EYaArC#EYaA = +2EYaAmaxreAEYaYreA1) then
11:-a-a-a-a EYaA0 raE RNEYaA(EYaArC#EYaA -+ (2 reA 2reAEYaY+1))12: EYaA0 raE reA2EYaArC#EYaA
13:-a-a else
14:-a-a-a-a EYaA0 raE EYaAEYaA (infinity with right sign)
15:-a-a-a-a EYaA0 raE EYaAEYaA
16:-a-a end if
17: end if
18: return (EYaA0, EYaA0)
and Fast2Sum() and Recomp() are inlinable subroutines.
All of which would make double-double without augmented ops incredibly
slow,
and all the branches in the routines make it non SIMD or GPU friendly.
I came across a 2025 paper which claims to have SIMD/GPU friendly versions using something called "Floating-Point Accumulation Networks"
but I haven't tracked down the example code yet.
High-performance branch-free algorithms for extended-precision
floating-point arithmetic, DK Zhang, A Aiken, 2025 https://dl.acm.org/doi/abs/10.1145/3712285.3759876 https://dl.acm.org/doi/pdf/10.1145/3712285.3759876
Stephen Fuld wrote:
On 8/2/2026 3:00 AM, Johann 'Myrkraverk' Oskarsson wrote:
On 02/08/2026 8:17 AM, Stephen Fuld wrote:
On 8/1/2026 1:39 AM, Anton Ertl wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
128 fp for a deeper zoom into a fractal?
Fixed point is more appropriate for Mandelbrot set visualizations,
because once |z|>2, it is clear that c is not in the set, and values >>>>> of |c|<0.25 are definitely inside the set.|e-a So the dynamic range is >>>>> very limited, and most of the bits spent on the exponent are wasted
and better spent on the significand.|e-a So 128-bit fixed-point with the >>>>> total range of [-4,4] is a better choice.|e-a Can we make do with
[-4,4),
which is easier to implement?|e-a Probably.
Of course, for really deep zooms, you don't want to stop at 128-bit
fixed-point and probably want to go for fixed-point based on BigNums >>>>> (variable-length arbitrary-precision big integers).
<https://weitz.de/mandelbrot/> says:
I tried downloading the program to play with it, but Windows
Defender wouldn't let it run as it thought the program was dangerous
as it had no author.
I don't know how you have your security settings, but there's usually a
way to get past that prompt.|e-a Something like /run anyway/.|e-a I've
had to
do that many times.|e-a Probably, but my memory is vague, when I installed >>> Caml Light, from 1997.
Yes, thanks.-a For obvious reasons, I don't like to use that mechanism,
but I generally trust at least most of the people who post here, so I
did that, and it ran fine.
Quite nice, but I still preferred Fractint back in the old days.-a It
had more fractals, as well as other things.-a I think it would make a
good retirement project for someone, I'm looking at you Terje :-) to
update it to work on modern 64 bit processors and Windows graphics.
It could then be extended to support greater precision than 80 bit X87
the original version supported.
Funy that you should mention me here, I wrote several Mandelbrot
generators back in the day, the crux was to be able to fit the entire evaluation loop within the 8-entry 8087 stack. :-)
For a modern version I would in fact use the 8:120 bit fixed-point I
oulined in a previous post.
On 8/2/2026 10:51 AM, Terje Mathisen wrote:[...]
On 2026-Aug-01 16:34, Terje Mathisen wrote:
EricP wrote:
On 2026-Jul-29 16:39, Thomas Koenig wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>>> 5-sizes of FP containers.
128-bit FP has very poor hardware support - AFAIK, IBM is the only
company supporting it, and only as a by-product of their decimal
floating point unit.-a Which means that it is much slower than an
implementation in hardware done with a view towards performance.
Most people who need it will then obviously use software, which
is still slower than IBM's hardware.
How many believe that 256-bit FP will be desired/useful in the coming >>>> decade (or farther out) ??
Based on the sluggish uptake of 128-bit float, I don't see it on
the horizon any time soon.
I thought the use of double-double libraries might give an idea
as to how much demand there is for binary128 FP precision.
But a-a bit of poking about finds that even though the original
D-D library was released in 1998, the experts are still
working out the exact rounding error they get in 2022.
Formalization of double-word arithmetic, and comments on |ore4+otight and >> rigorous error bounds for basic building blocks of double-word arithmetic|ore4-Y,
JM Muller, L Rideau, 2022
https://dl.acm.org/doi/abs/10.1145/3484514
https://dl.acm.org/doi/pdf/10.1145/3484514
It might be that double-double is too complicated or
the overhead of running it is too high that people
are dissuaded from using it, and therefore it is not
a good proxy for estimating binary128 market demand.
Augmented[Addition|Multipication] was defined all the way back in ieee754-2019, so I expected new designs to consider supporting that by now.
Terje
Oh that's what those are. I had seen the names but not looked into it.
Yes, I was thinking as I read those papers that this cries out for
operations with two dest registers for the result and error.
A quick search of Intel manuals shows no support (yet) for
the augmented operations.
In
Emulating round-to-nearest-ties-to-zero "augmented" floating-point
operations using round-to-nearest-ties-to-even arithmetic
Boldo, Lauter, Muller, 2019
https://hal.science/hal-02137968v3/
they explain that the augmented operations are defined as using
"Round Nearest Ties to Zero" (RN0) mode whereas existing arithmetic
uses the default "Round Nearest Ties Even" (RNE) mode
which can give different results.
They say to emulate Augmented Add with RN0 using operations
in RNE mode requires the following algorithm:
ALGORITHM 7: AA-Full(EYaN, EYaa): computes
augmentedAddition(EYaN, EYaa) in all cases.
1: if |EYaa| > |EYaN| then
2: swap(EYaN, EYaa)
3: end if
4: (EYaAEYaA, EYaAEYaA) raE Fast2Sum(EYaN, EYaa)
5: (EYaA0, EYaA0) raE Recomp(EYaAEYaA, EYaAEYaA)
6: if EYaA0 = 0 then
7: EYaA0 raE (+0) |u EYaA0
8: else if |EYaAEYaA| = +reR then
9: (EYaArC#EYaA, EYaArC#EYaA) raE Fast2Sum(0.5EYaN, 0.5EYaa)
10: if (EYaArC#EYaA = 2EYaAmax and EYaArC#EYaA = reA2EYaAmaxreAEYaYreA1) or
(EYaArC#EYaA = reA2EYaAmax and EYaArC#EYaA = +2EYaAmaxreAEYaYreA1) then
11: EYaA0 raE RNEYaA(EYaArC#EYaA -+ (2 reA 2reAEYaY+1))12: EYaA0 raE reA2EYaArC#EYaA
13: else
14: EYaA0 raE EYaAEYaA (infinity with right sign)
15: EYaA0 raE EYaAEYaA
16: end if
17: end if
18: return (EYaA0, EYaA0)
and Fast2Sum() and Recomp() are inlinable subroutines.
All of which would make double-double without augmented ops incredibly slow, and all the branches in the routines make it non SIMD or GPU friendly.
I came across a 2025 paper which claims to have SIMD/GPU friendly versions using something called "Floating-Point Accumulation Networks"
but I haven't tracked down the example code yet.
High-performance branch-free algorithms for extended-precision
floating-point arithmetic, DK Zhang, A Aiken, 2025 https://dl.acm.org/doi/abs/10.1145/3712285.3759876 https://dl.acm.org/doi/pdf/10.1145/3712285.3759876
I came across a 2025 paper which claims to have SIMD/GPU friendly versions using something called "Floating-Point Accumulation Networks"
but I haven't tracked down the example code yet.
High-performance branch-free algorithms for extended-precision
floating-point arithmetic, DK Zhang, A Aiken, 2025 https://dl.acm.org/doi/abs/10.1145/3712285.3759876 https://dl.acm.org/doi/pdf/10.1145/3712285.3759876
Quite nice, but I still preferred Fractint back in the old days.
It had more fractals, as well as other things.
DPairT DWBFAdd (DPairT a, DPairT b)That's 36 instructions, plus the call/ret overhead, while Mitch's CARRY
{
-a double g4, g5;
-a DPairT g1, g2, g3, c;
-a g1 = TwoSum (a.Val, b.Val);
-a g2 = TwoSum (a.Ext, b.Ext);
-a g3 = QuickTwoSum (g1.Val, g2.Val);
-a g4 = g1.Ext + g2.Ext;
-a g5 = g4 + g3.Ext;
-a c = QuickTwoSum (g3.Val, g5);
-a return c;
}
gives this for a double-double add:
compiled on Godbolt x86-64 GCC 16.1 -O3
# Compilation provided by Compiler Explorer at https://godbolt.org/ "DWBFAdd(DPairS, DPairS)":
-a-a-a-a-a-a-a movapd-a xmm4, xmm1
-a-a-a-a-a-a-a movapd-a xmm5, xmm0
-a-a-a-a-a-a-a addsd-a-a xmm4, xmm3
-a-a-a-a-a-a-a addsd-a-a xmm5, xmm2
-a-a-a-a-a-a-a movapd-a xmm8, xmm4
-a-a-a-a-a-a-a movapd-a xmm9, xmm4
-a-a-a-a-a-a-a movapd-a xmm7, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm8, xmm1
-a-a-a-a-a-a-a subsd-a-a xmm7, xmm0
-a-a-a-a-a-a-a movapd-a xmm6, xmm4
-a-a-a-a-a-a-a addsd-a-a xmm6, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm9, xmm8
-a-a-a-a-a-a-a subsd-a-a xmm3, xmm8
-a-a-a-a-a-a-a subsd-a-a xmm2, xmm7
-a-a-a-a-a-a-a subsd-a-a xmm1, xmm9
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm3
-a-a-a-a-a-a-a movapd-a xmm3, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm3, xmm7
-a-a-a-a-a-a-a subsd-a-a xmm0, xmm3
-a-a-a-a-a-a-a addsd-a-a xmm0, xmm2
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm0
-a-a-a-a-a-a-a movapd-a xmm0, xmm6
-a-a-a-a-a-a-a subsd-a-a xmm0, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm4, xmm0
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm4
-a-a-a-a-a-a-a movapd-a xmm0, xmm1
-a-a-a-a-a-a-a addsd-a-a xmm0, xmm6
-a-a-a-a-a-a-a movapd-a xmm2, xmm0
-a-a-a-a-a-a-a movq-a-a-a rdx, xmm0
-a-a-a-a-a-a-a subsd-a-a xmm2, xmm6
-a-a-a-a-a-a-a subsd-a-a xmm1, xmm2
-a-a-a-a-a-a-a movq-a-a-a rax, xmm1
-a-a-a-a-a-a-a xchg-a-a-a rax, rdx
-a-a-a-a-a-a-a movq-a-a-a xmm1, rdx
-a-a-a-a-a-a-a movq-a-a-a xmm0, rax
-a-a-a-a-a-a-a ret
That's a good one. However, I found a very interesting bug in it:Quite nice, but I still preferred Fractint back in the old days.
It had more fractals, as well as other things.
Another I saw passing recently is [Xaos](https://www.gnu.org/software/xaos/)
On 8/2/2026 7:30 PM, Stefan Monnier wrote:
Quite nice, but I still preferred Fractint back in the old days.
It had more fractals, as well as other things.
Another I saw passing recently is [Xaos](https://www.gnu.org/software/
xaos/)
Thanks, Stefan.-a I downloaded it, and after overriding the Windows
defender protection, installed it.-a BTW, Windows defender says it has no author.-a Is there something that the actual author and easily do to
prevent this?-a It would increase the user base.
It is more like Fractint, with lots of capabilities beyond
straightforward Mandelbrot set rendering, that I will have to take time
to explore.-a The user interface is certainly not "windows like" and thus takes a little time to get used to.-a But I expect to have a lot of fun playing with it.
Thanks again for bringing it to my/our attention.
Quite nice, but I still preferred Fractint back in the old days.
It had more fractals, as well as other things.
Another I saw passing recently is [Xaos](https://www.gnu.org/software/xaos/)
I know that a 256-bit floating-point format has already been defined
in a later version of the IEEE-754 floating-point standard. I had
thought, therefore, that there was already some demand, and some
use, for it.
128-bit and 256-bit floats will simply be used for investigations
that pose serious numerical analysis problems which can't be dealt
with at a lower precision with more careful programming.
I tend to suspect, though, that instead of extending the precision
to such a great extent, and increasing the exponent range only
modestly, the more urgent need is to extend the exponent range.
In article <6a72b2f2.7720687@news.eternal-september.org>, quadibloc@invalid.com (John Savard) wrote:
I know that a 256-bit floating-point format has already been defined
in a later version of the IEEE-754 floating-point standard. I had
thought, therefore, that there was already some demand, and some
use, for it.
It seems at least equally likely that the standards group wanted to anticipate future needs, and provide a standard. When I joined my current employer, 31 years ago, they were still supporting VAX, whose floating
point is a lot like IEEE, but not identical. There were enough different
test results to be a nuisance. Having a standard for future
higher-precision floating point seems highly desirable to me.
128-bit and 256-bit floats will simply be used for investigations
that pose serious numerical analysis problems which can't be dealt
with at a lower precision with more careful programming.
Or just to make high-precision programming a lot easier.
I tend to suspect, though, that instead of extending the precision
to such a great extent, and increasing the exponent range only
modestly, the more urgent need is to extend the exponent range.
That depends very much on what you're doing.
John
In article <6a72b2f2.7720687@news.eternal-september.org>, quadibloc@invalid.com (John Savard) wrote:
I know that a 256-bit floating-point format has already been defined
in a later version of the IEEE-754 floating-point standard. I had
thought, therefore, that there was already some demand, and some
use, for it.
It seems at least equally likely that the standards group wanted to anticipate future needs, and provide a standard. When I joined my current employer, 31 years ago, they were still supporting VAX, whose floating
point is a lot like IEEE, but not identical. There were enough different
test results to be a nuisance. Having a standard for future
higher-precision floating point seems highly desirable to me.
On 8/2/2026 7:30 PM, Stefan Monnier wrote:
Quite nice, but I still preferred Fractint back in the old days.
It had more fractals, as well as other things.
Another I saw passing recently is [Xaos](https://www.gnu.org/software/xaos/)
Thanks, Stefan. I downloaded it, and after overriding the Windows
defender protection, installed it. BTW, Windows defender says it has no >author. Is there something that the actual author and easily do to
prevent this? It would increase the user base.
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 8/2/2026 7:30 PM, Stefan Monnier wrote:
Quite nice, but I still preferred Fractint back in the old days.
It had more fractals, as well as other things.
Another I saw passing recently is [Xaos](https://www.gnu.org/software/xaos/)
Thanks, Stefan. I downloaded it, and after overriding the Windows
defender protection, installed it. BTW, Windows defender says it has no
author. Is there something that the actual author and easily do to
prevent this? It would increase the user base.
That just means the executable isn't digitally signed with a company
code signing certificate that is blessed by MS ("Authenticode"). The
name comes from the signing certificate and that certificate needs to
be able to trace the chain back to the MS Authenticode root
certificate(s).
Dealing with MS code signing certificates can be a MAJOR pita for
small or opensource developers. There's good reasons for why a lot of
free community-supported software either can't do it, isn't ALLOWED to
do it, don't want to do it or is not willing to pay the M$ tax.
Heck, with recent changes they've made it a bit of a PITA even for
people who HAVE one (physical hardware token is now required).
I'm not ruling out that MS WANT everyone to either switch to Azure
Artifact signing (AAS) service which instead is a pay-per-sign,
starting at $10/month (max 5000 signings per month) or ship only via
the MS Store (MS resigns anything coming via the Store). That would be
very on-brand. And not everyone can get access to AAS even if they
were willing to pay a monthly fee, there's a number of requirements.
At present, we have competing interest of 8-bit FP and 128-bit FP giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
On 7/28/2026 12:40 PM, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving
5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
I want to take a somewhat different approach to answering this question than the need for precision arguments presented elsewhere in this thread.-a I don't believe there will be any hardware implementation of FP256 for at least several decades.-a This is based on a "register argument".-a That is, I assume any hardware implementation would require the operands to be in some kind of registers, not only in main memory.
If one is willing to say FP256 operations can take place *only* in some kind of vector register, e.g. enhanced AVX512, not in GPRs or FPRs, then things aren't too bad.-a You need new op-codes, of course, and you reduce the number of parallel operations, but it fits reasonably well.
But if you want to support FP256 operations in non-vector registers, things get ugly.-a The obvious reason is that, with the 64 bit registers we have today, each FP256 operand requires four registers (256/64).-a So a typical FP256 operation such as FPADD requiring two sources and a destination requires 4 * 3 = 12 registers.-a If you want any amount of parallelism, even more are required. Two operations in parallel require 24 registers!-a This leaves relatively few registers for other, typical uses.-a If you have a unified registers set (i.e. no dedicated FP registers), the register pressure is worse.-a As a side note, if, like Mitch, you don't like register pairing, i.e. the instruction specifies one register but that implies use of at least one adjacent register, then you have to somehow specify all 12 registers in the instruction (or instruction modifier).-a Ugggh!
The obvious solution is going from 64 to 128 bit registers.-a But historically, register width is driven not by arithmetic precision requirements, but memory space requirements.-a I haven't kept up, but it used to be that these requirements grew by something like 1 bit every 2-3 years, but seemed like it was slowing down.-a (I welcome any updates to these numbers).-a So if we are at say 54 bits now, then requiring more than 64 bit addressing will be at least 2 decades away.
Thus, I conclude that we won't have native hardware support for FP256 for at least two decades.
Of course, This may all be wrong!-a :-)
I know that a 256-bit floating-point format has already been defined
in a later version of the IEEE-754 floating-point standard. I had
thought, therefore, that there was already some demand, and some use,
for it.
That doesn't mean that there is going to be a whole lot of demand for
it. Even 128-bit floating-point is not going to displace 64-bit floating-point; it will simply be needed occasionally for a few
specialized applications. And, of course, 128-bit floating-point
preceded the IEEE-754 standard by decades; it was provided by the IBM System/360 Model 85.
In the case of integers, 64-bit computing came about when using 32
bits for addresses was no longer feasible, because a hard 4 gigabyte
limit to storage was an unacceptable constraint. No analogous
situation exists for floating-point. 128-bit and 256-bit floats will
simply be used for investigations that pose serious numerical analysis problems which can't be dealt with at a lower precision with more
careful programming.
I tend to suspect, though, that instead of extending the precision to--- Synchronet 3.22a-Linux NewsLink 1.2
such a great extent, and increasing the exponent range only modestly,
the more urgent need is to extend the exponent range.
John Savard
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 8/2/2026 7:30 PM, Stefan Monnier wrote:
Quite nice, but I still preferred Fractint back in the old days.
It had more fractals, as well as other things.
Another I saw passing recently is [Xaos](https://www.gnu.org/software/xaos/)
Thanks, Stefan. I downloaded it, and after overriding the Windows >defender protection, installed it. BTW, Windows defender says it has no >author. Is there something that the actual author and easily do to >prevent this? It would increase the user base.
That just means the executable isn't digitally signed with a company
code signing certificate that is blessed by MS ("Authenticode"). The
name comes from the signing certificate and that certificate needs to
be able to trace the chain back to the MS Authenticode root
certificate(s).
Dealing with MS code signing certificates can be a MAJOR pita for
small or opensource developers. There's good reasons for why a lot of
free community-supported software either can't do it, isn't ALLOWED to
do it, don't want to do it or is not willing to pay the M$ tax.
Heck, with recent changes they've made it a bit of a PITA even for
people who HAVE one (physical hardware token is now required).
I'm not ruling out that MS WANT everyone to either switch to Azure
Artifact signing (AAS) service which instead is a pay-per-sign,
starting at $10/month (max 5000 signings per month) or ship only via
the MS Store (MS resigns anything coming via the Store). That would be
very on-brand. And not everyone can get access to AAS even if they
were willing to pay a monthly fee, there's a number of requirements.
On 2026-Aug-05 10:48, Stephen Fuld wrote:
On 7/28/2026 12:40 PM, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>> 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
I want to take a somewhat different approach to answering this
question than the need for precision arguments presented elsewhere in
this thread.-a I don't believe there will be any hardware
implementation of FP256 for at least several decades.-a This is based
on a "register argument".-a That is, I assume any hardware
implementation would require the operands to be in some kind of
registers, not only in main memory.
If one is willing to say FP256 operations can take place *only* in
some kind of vector register, e.g. enhanced AVX512, not in GPRs or
FPRs, then things aren't too bad.-a You need new op-codes, of course,
and you reduce the number of parallel operations, but it fits
reasonably well.
But if you want to support FP256 operations in non-vector registers,
things get ugly.-a The obvious reason is that, with the 64 bit
registers we have today, each FP256 operand requires four registers
(256/64).-a So a typical FP256 operation such as FPADD requiring two
sources and a destination requires 4 * 3 = 12 registers.-a If you want
any amount of parallelism, even more are required. Two operations in
parallel require 24 registers!-a This leaves relatively few registers
for other, typical uses.-a If you have a unified registers set (i.e. no
dedicated FP registers), the register pressure is worse.-a As a side
note, if, like Mitch, you don't like register pairing, i.e. the
instruction specifies one register but that implies use of at least
one adjacent register, then you have to somehow specify all 12
registers in the instruction (or instruction modifier).-a Ugggh!
FMA has 3 source and 1 dest registers.
Augmented Add/Mul has two source and two dest registers.
With a 64 bit register file that's #registers * 2 or 4 ports per instruction.
Also requires renaming 2 or 4 physical dest registers for each arch dest register, which has O(N^2) complexity growth.
quadibloc@invalid.com (John Savard) posted:
I know that a 256-bit floating-point format has already been defined
in a later version of the IEEE-754 floating-point standard. I had
thought, therefore, that there was already some demand, and some use,
for it.
That doesn't mean that there is going to be a whole lot of demand for
it. Even 128-bit floating-point is not going to displace 64-bit
floating-point; it will simply be needed occasionally for a few
specialized applications. And, of course, 128-bit floating-point
preceded the IEEE-754 standard by decades; it was provided by the IBM
System/360 Model 85.
We ("we") were inside the cabinets of the 360/67 at CMU one night
when we found several (4) wires unconnected with little labels as
to where they go. We connected the wires and ran diagnostics.
Presto the Quadword FP (ala /85) was on and running. We removed the
wires to avoid collateral issues of "we" being inside the cabinets...
In the case of integers, 64-bit computing came about when using 32
bits for addresses was no longer feasible, because a hard 4 gigabyte
limit to storage was an unacceptable constraint. No analogous
situation exists for floating-point. 128-bit and 256-bit floats will
simply be used for investigations that pose serious numerical analysis
problems which can't be dealt with at a lower precision with more
careful programming.
Galactic evolution calculations are one. Too many individual stars
for simple double precision to be enough.
Torbjorn Lindgren <tl@none.invalid> posted:
I'm not ruling out that MS WANT everyone to either switch to Azure
Artifact signing (AAS) service which instead is a pay-per-sign,
starting at $10/month (max 5000 signings per month) or ship only via
the MS Store (MS resigns anything coming via the Store). That would be
very on-brand. And not everyone can get access to AAS even if they
were willing to pay a monthly fee, there's a number of requirements.
"Those who are willing to sacrifice liberty for safety,
will soon have neither" Ben Franklin.
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
Torbjorn Lindgren <tl@none.invalid> posted:
I'm not ruling out that MS WANT everyone to either switch to Azure
Artifact signing (AAS) service which instead is a pay-per-sign,
starting at $10/month (max 5000 signings per month) or ship only via
the MS Store (MS resigns anything coming via the Store). That would be
very on-brand. And not everyone can get access to AAS even if they
were willing to pay a monthly fee, there's a number of requirements.
"Those who are willing to sacrifice liberty for safety,
will soon have neither" Ben Franklin.
The quotation was actually
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
Franklin wrote that to support the assembly's power
to tax wealthy proprietors to pay for military defense
during the French and Indian war.
"Liberty" in this context referred to the communities
right to self-governance and ability to tax to pay for
collective self-defence"
On 2026-Aug-02 14:04, EricP wrote:
I came across a 2025 paper which claims to have SIMD/GPU friendly versions >> using something called "Floating-Point Accumulation Networks"
but I haven't tracked down the example code yet.
High-performance branch-free algorithms for extended-precision
floating-point arithmetic, DK Zhang, A Aiken, 2025
https://dl.acm.org/doi/abs/10.1145/3712285.3759876
https://dl.acm.org/doi/pdf/10.1145/3712285.3759876
Note that the "High-performance branch-free" paper doesn't mention
the compensation for the difference between Round-Nearest-Zero and Round-Nearest-Even that Muller does.
I don't know if that effects its results.
The above paper wrote its examples in the Julia language.
Using algorithms from the paper below which claims to be the same:
Acceleration of multicomponent multiple-precision arithmetic with
branch-free algorithms and SIMD vectorization https://arxiv.org/abs/2603.14926
gives the following code for a double word branch free add DWBFAdd:
typedef struct DPairS
{
-a double Val;
-a double Ext;
} DPairT, *DPairPT;
static DPairT QuickTwoSum (double a, double b)
{
-a double sum, ext;
-a sum = a + b;
-a ext = b - (sum - a);
-a return {sum, ext};
}
static DPairT TwoSum (double a, double b)
{
-a double sum, ext, tmp;
-a sum = a + b;
-a tmp = sum - a;
-a ext = (a - (sum - tmp)) + (b - tmp);
-a return {sum, ext};
}
DPairT DWBFAdd (DPairT a, DPairT b)
{
-a double g4, g5;
-a DPairT g1, g2, g3, c;
-a g1 = TwoSum (a.Val, b.Val);
-a g2 = TwoSum (a.Ext, b.Ext);
-a g3 = QuickTwoSum (g1.Val, g2.Val);
-a g4 = g1.Ext + g2.Ext;
-a g5 = g4 + g3.Ext;
-a c = QuickTwoSum (g3.Val, g5);
-a return c;
}
gives this for a double-double add:
compiled on Godbolt x86-64 GCC 16.1 -O3
# Compilation provided by Compiler Explorer at https://godbolt.org/ "DWBFAdd(DPairS, DPairS)":
-a-a-a-a-a-a-a movapd-a xmm4, xmm1
-a-a-a-a-a-a-a movapd-a xmm5, xmm0
-a-a-a-a-a-a-a addsd-a-a xmm4, xmm3
-a-a-a-a-a-a-a addsd-a-a xmm5, xmm2
-a-a-a-a-a-a-a movapd-a xmm8, xmm4
-a-a-a-a-a-a-a movapd-a xmm9, xmm4
-a-a-a-a-a-a-a movapd-a xmm7, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm8, xmm1
-a-a-a-a-a-a-a subsd-a-a xmm7, xmm0
-a-a-a-a-a-a-a movapd-a xmm6, xmm4
-a-a-a-a-a-a-a addsd-a-a xmm6, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm9, xmm8
-a-a-a-a-a-a-a subsd-a-a xmm3, xmm8
-a-a-a-a-a-a-a subsd-a-a xmm2, xmm7
-a-a-a-a-a-a-a subsd-a-a xmm1, xmm9
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm3
-a-a-a-a-a-a-a movapd-a xmm3, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm3, xmm7
-a-a-a-a-a-a-a subsd-a-a xmm0, xmm3
-a-a-a-a-a-a-a addsd-a-a xmm0, xmm2
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm0
-a-a-a-a-a-a-a movapd-a xmm0, xmm6
-a-a-a-a-a-a-a subsd-a-a xmm0, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm4, xmm0
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm4
-a-a-a-a-a-a-a movapd-a xmm0, xmm1
-a-a-a-a-a-a-a addsd-a-a xmm0, xmm6
-a-a-a-a-a-a-a movapd-a xmm2, xmm0
-a-a-a-a-a-a-a movq-a-a-a rdx, xmm0
-a-a-a-a-a-a-a subsd-a-a xmm2, xmm6
-a-a-a-a-a-a-a subsd-a-a xmm1, xmm2
-a-a-a-a-a-a-a movq-a-a-a rax, xmm1
-a-a-a-a-a-a-a xchg-a-a-a rax, rdx
-a-a-a-a-a-a-a movq-a-a-a xmm1, rdx
-a-a-a-a-a-a-a movq-a-a-a xmm0, rax
-a-a-a-a-a-a-a ret
FMA has 3 source and 1 dest registers.
Augmented Add/Mul has two source and two dest registers.
On 2026-Aug-05 13:12, Scott Lurndal wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
Torbjorn Lindgren <tl@none.invalid> posted:
I'm not ruling out that MS WANT everyone to either switch to Azure
Artifact signing (AAS) service which instead is a pay-per-sign,
starting at $10/month (max 5000 signings per month) or ship only via
the MS Store (MS resigns anything coming via the Store). That would be >>>> very on-brand. And not everyone can get access to AAS even if they
were willing to pay a monthly fee, there's a number of requirements.
"Those who are willing to sacrifice liberty for safety,
will soon have neither" Ben Franklin.
The quotation was actually
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
Franklin wrote that to support the assembly's power
to tax wealthy proprietors to pay for military defense
during the French and Indian war.
"Liberty" in this context referred to the communities
right to self-governance and ability to tax to pay for
collective self-defence"
So "liberty" is the governments freedom to choose not the citizens
(assuming few citizens would willingly tax themselves).
On 8/2/2026 7:30 PM, Stefan Monnier wrote:
Quite nice, but I still preferred Fractint back in the old days.
It had more fractals, as well as other things.
Another I saw passing recently is [Xaos](https://www.gnu.org/software/
xaos/)
Thanks, Stefan.-a I downloaded it, and after overriding the Windows
defender protection, installed it.-a BTW, Windows defender says it has no author.-a Is there something that the actual author and easily do to
prevent this?-a It would increase the user base.
It is more like Fractint, with lots of capabilities beyond
straightforward Mandelbrot set rendering, that I will have to take time
to explore.-a The user interface is certainly not "windows like" and thus takes a little time to get used to.-a But I expect to have a lot of fun playing with it.
Thanks again for bringing it to my/our attention.
On 7/28/2026 12:40 PM, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming decade (or farther out) ??
I want to take a somewhat different approach to answering this question
than the need for precision arguments presented elsewhere in this
thread. I don't believe there will be any hardware implementation of
FP256 for at least several decades. This is based on a "register
argument". That is, I assume any hardware implementation would require
the operands to be in some kind of registers, not only in main memory.
If one is willing to say FP256 operations can take place *only* in some
kind of vector register, e.g. enhanced AVX512, not in GPRs or FPRs, then things aren't too bad. You need new op-codes, of course, and you reduce
the number of parallel operations, but it fits reasonably well.
But if you want to support FP256 operations in non-vector registers,
things get ugly.
The obvious reason is that, with the 64 bit registers
we have today, each FP256 operand requires four registers (256/64). So
a typical FP256 operation such as FPADD requiring two sources and a destination requires 4 * 3 = 12 registers.
If you want any amount of parallelism, even more are required.
Two operations in parallel require
24 registers! This leaves relatively few registers for other, typical
uses. If you have a unified registers set (i.e. no dedicated FP
registers), the register pressure is worse. As a side note, if, like
Mitch, you don't like register pairing, i.e. the instruction specifies
one register but that implies use of at least one adjacent register,
then you have to somehow specify all 12 registers in the instruction (or instruction modifier). Ugggh!
The obvious solution is going from 64 to 128 bit registers. But historically, register width is driven not by arithmetic precision requirements, but memory space requirements. I haven't kept up, but it
used to be that these requirements grew by something like 1 bit every
2-3 years, but seemed like it was slowing down. (I welcome any updates
to these numbers). So if we are at say 54 bits now, then requiring more than 64 bit addressing will be at least 2 decades away.
Thus, I conclude that we won't have native hardware support for FP256
for at least two decades.
Of course, This may all be wrong! :-)
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
quadibloc@invalid.com (John Savard) posted:
I know that a 256-bit floating-point format has already been defined
in a later version of the IEEE-754 floating-point standard. I had
thought, therefore, that there was already some demand, and some use,
for it.
That doesn't mean that there is going to be a whole lot of demand for
it. Even 128-bit floating-point is not going to displace 64-bit
floating-point; it will simply be needed occasionally for a few
specialized applications. And, of course, 128-bit floating-point
preceded the IEEE-754 standard by decades; it was provided by the IBM
System/360 Model 85.
We ("we") were inside the cabinets of the 360/67 at CMU one night
when we found several (4) wires unconnected with little labels as
to where they go. We connected the wires and ran diagnostics.
Presto the Quadword FP (ala /85) was on and running. We removed the
wires to avoid collateral issues of "we" being inside the cabinets...
Wasn't uncommon in those days. The Burroughs B4925 and B4955
differed by a couple of wires - basically the 4925 disabled overlapping
fetch and execute stages (which reduced performance by 50%).
In the case of integers, 64-bit computing came about when using 32
bits for addresses was no longer feasible, because a hard 4 gigabyte
limit to storage was an unacceptable constraint. No analogous
situation exists for floating-point. 128-bit and 256-bit floats will
simply be used for investigations that pose serious numerical analysis
problems which can't be dealt with at a lower precision with more
careful programming.
Galactic evolution calculations are one. Too many individual stars
for simple double precision to be enough.
You don't need floating point to count the number of stars.
On 2026-Aug-05 10:48, Stephen Fuld wrote:
On 7/28/2026 12:40 PM, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >> 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
I want to take a somewhat different approach to answering this question than the need for precision arguments presented elsewhere in this thread.-a I don't believe there will be any hardware implementation of FP256 for at least several decades.-a This is based on a "register argument".-a That is, I assume any hardware implementation would require the operands to be in some kind of registers, not only in main memory.
If one is willing to say FP256 operations can take place *only* in some kind of vector register, e.g. enhanced AVX512, not in GPRs or FPRs, then things aren't too bad.-a You need new op-codes, of course, and you reduce the number of parallel operations, but it fits reasonably well.
But if you want to support FP256 operations in non-vector registers, things get ugly.-a The obvious reason is that, with the 64 bit registers we have today, each FP256 operand requires four registers (256/64).-a So a typical FP256 operation such as FPADD requiring two sources and a destination requires 4 * 3 = 12 registers.-a If you want any amount of parallelism, even more are required. Two operations in parallel require 24 registers!-a This leaves relatively few registers for other, typical uses.-a If you have a unified registers set (i.e. no dedicated FP registers), the register pressure is worse.-a As a side note, if, like Mitch, you don't like register pairing, i.e. the instruction specifies one register but that implies use of at least one adjacent register, then you have to somehow specify all 12 registers in the instruction (or instruction modifier).-a Ugggh!
FMA has 3 source and 1 dest registers.
Augmented Add/Mul has two source and two dest registers.
With a 64 bit register file that's #registers * 2 or 4 ports per instruction. Also requires renaming 2 or 4 physical dest registers for each arch dest register, which has O(N^2) complexity growth.
The obvious solution is going from 64 to 128 bit registers.-a But historically, register width is driven not by arithmetic precision requirements, but memory space requirements.-a I haven't kept up, but it used to be that these requirements grew by something like 1 bit every 2-3 years, but seemed like it was slowing down.-a (I welcome any updates to these numbers).-a So if we are at say 54 bits now, then requiring more than 64 bit addressing will be at least 2 decades away.
Thus, I conclude that we won't have native hardware support for FP256 for at least two decades.
Of course, This may all be wrong!-a :-)
On 2026-Aug-05 13:12, Scott Lurndal wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
Torbjorn Lindgren <tl@none.invalid> posted:
I'm not ruling out that MS WANT everyone to either switch to Azure
Artifact signing (AAS) service which instead is a pay-per-sign,
starting at $10/month (max 5000 signings per month) or ship only via
the MS Store (MS resigns anything coming via the Store). That would be >>> very on-brand. And not everyone can get access to AAS even if they
were willing to pay a monthly fee, there's a number of requirements.
"Those who are willing to sacrifice liberty for safety,
will soon have neither" Ben Franklin.
The quotation was actually
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
Franklin wrote that to support the assembly's power
to tax wealthy proprietors to pay for military defense
during the French and Indian war.
"Liberty" in this context referred to the communities
right to self-governance and ability to tax to pay for
collective self-defence"
So "liberty" is the governments freedom to choose not the citizens
(assuming few citizens would willingly tax themselves).
On 2026-Aug-02 18:52, EricP wrote:
On 2026-Aug-02 14:04, EricP wrote:
I came across a 2025 paper which claims to have SIMD/GPU friendly versions >> using something called "Floating-Point Accumulation Networks"
but I haven't tracked down the example code yet.
High-performance branch-free algorithms for extended-precision
floating-point arithmetic, DK Zhang, A Aiken, 2025
https://dl.acm.org/doi/abs/10.1145/3712285.3759876
https://dl.acm.org/doi/pdf/10.1145/3712285.3759876
Note that the "High-performance branch-free" paper doesn't mention
the compensation for the difference between Round-Nearest-Zero and Round-Nearest-Even that Muller does.
I don't know if that effects its results.
The above paper wrote its examples in the Julia language.
Using algorithms from the paper below which claims to be the same:
Acceleration of multicomponent multiple-precision arithmetic with branch-free algorithms and SIMD vectorization https://arxiv.org/abs/2603.14926
gives the following code for a double word branch free add DWBFAdd:
typedef struct DPairS
{
-a double Val;
-a double Ext;
} DPairT, *DPairPT;
static DPairT QuickTwoSum (double a, double b)
{
-a double sum, ext;
-a sum = a + b;
-a ext = b - (sum - a);
-a return {sum, ext};
}
static DPairT TwoSum (double a, double b)
{
-a double sum, ext, tmp;
-a sum = a + b;
-a tmp = sum - a;
-a ext = (a - (sum - tmp)) + (b - tmp);
-a return {sum, ext};
}
DPairT DWBFAdd (DPairT a, DPairT b)
{
-a double g4, g5;
-a DPairT g1, g2, g3, c;
-a g1 = TwoSum (a.Val, b.Val);
-a g2 = TwoSum (a.Ext, b.Ext);
-a g3 = QuickTwoSum (g1.Val, g2.Val);
-a g4 = g1.Ext + g2.Ext;
-a g5 = g4 + g3.Ext;
-a c = QuickTwoSum (g3.Val, g5);
-a return c;
}
gives this for a double-double add:
compiled on Godbolt x86-64 GCC 16.1 -O3
# Compilation provided by Compiler Explorer at https://godbolt.org/ "DWBFAdd(DPairS, DPairS)":
-a-a-a-a-a-a-a movapd-a xmm4, xmm1
-a-a-a-a-a-a-a movapd-a xmm5, xmm0
-a-a-a-a-a-a-a addsd-a-a xmm4, xmm3
-a-a-a-a-a-a-a addsd-a-a xmm5, xmm2
-a-a-a-a-a-a-a movapd-a xmm8, xmm4
-a-a-a-a-a-a-a movapd-a xmm9, xmm4
-a-a-a-a-a-a-a movapd-a xmm7, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm8, xmm1
-a-a-a-a-a-a-a subsd-a-a xmm7, xmm0
-a-a-a-a-a-a-a movapd-a xmm6, xmm4
-a-a-a-a-a-a-a addsd-a-a xmm6, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm9, xmm8
-a-a-a-a-a-a-a subsd-a-a xmm3, xmm8
-a-a-a-a-a-a-a subsd-a-a xmm2, xmm7
-a-a-a-a-a-a-a subsd-a-a xmm1, xmm9
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm3
-a-a-a-a-a-a-a movapd-a xmm3, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm3, xmm7
-a-a-a-a-a-a-a subsd-a-a xmm0, xmm3
-a-a-a-a-a-a-a addsd-a-a xmm0, xmm2
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm0
-a-a-a-a-a-a-a movapd-a xmm0, xmm6
-a-a-a-a-a-a-a subsd-a-a xmm0, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm4, xmm0
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm4
-a-a-a-a-a-a-a movapd-a xmm0, xmm1
-a-a-a-a-a-a-a addsd-a-a xmm0, xmm6
-a-a-a-a-a-a-a movapd-a xmm2, xmm0
-a-a-a-a-a-a-a movq-a-a-a rdx, xmm0
-a-a-a-a-a-a-a subsd-a-a xmm2, xmm6
-a-a-a-a-a-a-a subsd-a-a xmm1, xmm2
-a-a-a-a-a-a-a movq-a-a-a rax, xmm1
-a-a-a-a-a-a-a xchg-a-a-a rax, rdx
-a-a-a-a-a-a-a movq-a-a-a xmm1, rdx
-a-a-a-a-a-a-a movq-a-a-a xmm0, rax
-a-a-a-a-a-a-a ret
That's 35 instructions for the DWAdd (excluding the RET).
There are a lot of MOV's because of the two operand operations.
I added the code for double-double multiply.
It uses FMA which requires including math.h and enabling its with a #define.
To get GCC to use the FMA instruction I had to use -march=haswell
which also has the effect of enabling the 3 operand instructions
which lowers the DWBFAdd instruction count to 24.
DWBFMul is 14 instructions.
#define FP_FAST_FMA (1)
#include <math.h>
static DPairT TwoProd (double a, double b)
{
DPairT c;
c.Val = a * b;
c.Ext = fma(a, b, -c.Val);
return c;
}
DPairT DWBFMul (DPairT a, DPairT b)
{
double p01, p10, g1, g2;
DPairT p0, c;
p0 = TwoProd (a.Val, b.Val);
p01 = a.Val * b.Ext;
p10 = a.Ext * b.Val;
g1 = p01 + p10;
g2 = p0.Ext + g1;
c = QuickTwoSum (p0.Val, g2);
return c;
}
compiled on Godbolt x86-64 GCC 16.1 -O3 -march=haswell
# Compilation provided by Compiler Explorer at https://godbolt.org/ "DWBFAdd(DPairS, DPairS)":
vaddsd xmm4, xmm1, xmm3
vaddsd xmm5, xmm0, xmm2
vsubsd xmm8, xmm4, xmm1
vsubsd xmm7, xmm5, xmm0
vaddsd xmm6, xmm4, xmm5
vsubsd xmm9, xmm4, xmm8
vsubsd xmm3, xmm3, xmm8
vsubsd xmm2, xmm2, xmm7
vsubsd xmm1, xmm1, xmm9
vaddsd xmm1, xmm1, xmm3
vsubsd xmm3, xmm5, xmm7
vsubsd xmm5, xmm6, xmm5
vsubsd xmm0, xmm0, xmm3
vsubsd xmm4, xmm4, xmm5
vaddsd xmm0, xmm0, xmm2
vaddsd xmm1, xmm1, xmm0
vaddsd xmm1, xmm1, xmm4
vaddsd xmm0, xmm1, xmm6
vsubsd xmm6, xmm0, xmm6
vsubsd xmm1, xmm1, xmm6
vpunpcklqdq xmm7, xmm0, xmm1
vpextrq rdx, xmm7, 1
vmovapd xmm0, xmm7
vmovq xmm1, rdx
ret
"DWBFMul(DPairS, DPairS)":
vmulsd xmm1, xmm1, xmm2
vmovapd xmm4, xmm0
vmovapd xmm5, xmm2
vmulsd xmm0, xmm0, xmm2
vfmadd132sd xmm3, xmm1, xmm4
vfmsub132sd xmm5, xmm0, xmm4
vaddsd xmm3, xmm3, xmm5
vaddsd xmm1, xmm3, xmm0
vsubsd xmm0, xmm1, xmm0
vsubsd xmm3, xmm3, xmm0
vpunpcklqdq xmm6, xmm1, xmm3
vpextrq rdx, xmm6, 1
vmovapd xmm0, xmm6
vmovq xmm1, rdx
ret
Something odd about DWBFMul is that the source contains one call
to TwoProd which uses one fma, but the asm contains two fma:
vfmadd132sd xmm3, xmm1, xmm4
vfmsub132sd xmm5, xmm0, xmm4
scott@slp53.sl.home (Scott Lurndal) posted:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
Galactic evolution calculations are one. Too many individual stars
for simple double precision to be enough.
You don't need floating point to count the number of stars.
It is not the counting of stars, but the calculation of the gravitational forces of each star on each other star. Sometimes, one also has to consider the speed-of-light problems as separate from the speed-of-gravity {also
known as the gravitational anomaly. If the sun disappeared instantaneously the earth would leave its orbit instantaneously, even though we could still see the light from it for 8 minutes.}
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
Augmented Add/Mul has two source and two dest registers.
And this is a requiremnt you cannot get around.
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-Aug-05 13:12, Scott Lurndal wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
Torbjorn Lindgren <tl@none.invalid> posted:
I'm not ruling out that MS WANT everyone to either switch to Azure
Artifact signing (AAS) service which instead is a pay-per-sign,
starting at $10/month (max 5000 signings per month) or ship only via >>>>> the MS Store (MS resigns anything coming via the Store). That would be >>>>> very on-brand. And not everyone can get access to AAS even if they
were willing to pay a monthly fee, there's a number of requirements.
"Those who are willing to sacrifice liberty for safety,
will soon have neither" Ben Franklin.
The quotation was actually
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
Franklin wrote that to support the assembly's power
to tax wealthy proprietors to pay for military defense
during the French and Indian war.
"Liberty" in this context referred to the communities
right to self-governance and ability to tax to pay for
collective self-defence"
So "liberty" is the governments freedom to choose not the citizens
(assuming few citizens would willingly tax themselves).
Liberty is the concept of being out in public without someone following
you around
(although with the number of cameras around today it can be
argued that none of us have liberty anymore.)
Liberty is a right manifest on the citizen by the constitution.
A right is something the *.gov is not allowed to encumber from its
citizens (without due process).
scott@slp53.sl.home (Scott Lurndal) posted:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
quadibloc@invalid.com (John Savard) posted:
I know that a 256-bit floating-point format has already been defined
in a later version of the IEEE-754 floating-point standard. I had
thought, therefore, that there was already some demand, and some use,
for it.
That doesn't mean that there is going to be a whole lot of demand for
it. Even 128-bit floating-point is not going to displace 64-bit
floating-point; it will simply be needed occasionally for a few
specialized applications. And, of course, 128-bit floating-point
preceded the IEEE-754 standard by decades; it was provided by the IBM
System/360 Model 85.
We ("we") were inside the cabinets of the 360/67 at CMU one night
when we found several (4) wires unconnected with little labels as
to where they go. We connected the wires and ran diagnostics.
Presto the Quadword FP (ala /85) was on and running. We removed the
wires to avoid collateral issues of "we" being inside the cabinets...
Wasn't uncommon in those days. The Burroughs B4925 and B4955
differed by a couple of wires - basically the 4925 disabled overlapping
fetch and execute stages (which reduced performance by 50%).
In the case of integers, 64-bit computing came about when using 32
bits for addresses was no longer feasible, because a hard 4 gigabyte
limit to storage was an unacceptable constraint. No analogous
situation exists for floating-point. 128-bit and 256-bit floats will
simply be used for investigations that pose serious numerical analysis >>>> problems which can't be dealt with at a lower precision with more
careful programming.
Galactic evolution calculations are one. Too many individual stars
for simple double precision to be enough.
You don't need floating point to count the number of stars.
It is not the counting of stars, but the calculation of the gravitational forces of each star on each other star.
Sometimes, one also has to consider
the speed-of-light problems as separate from the speed-of-gravity {also
known as the gravitational anomaly. If the sun disappeared instantaneously the earth would leave its orbit instantaneously, even though we could still see the light from it for 8 minutes.}
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
Augmented Add/Mul has two source and two dest registers.
And this is a requiremnt you cannot get around.
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version.
Augmented Add/Mul has two source and two dest registers.
And this is a requiremnt you cannot get around.
I tend to suspect, though, that instead of extending the precision to
such a great extent, and increasing the exponent range only modestly,
the more urgent need is to extend the exponent range.
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-Aug-02 18:52, EricP wrote:
On 2026-Aug-02 14:04, EricP wrote:
I came across a 2025 paper which claims to have SIMD/GPU friendly versions >>>> using something called "Floating-Point Accumulation Networks"
but I haven't tracked down the example code yet.
High-performance branch-free algorithms for extended-precision
floating-point arithmetic, DK Zhang, A Aiken, 2025
https://dl.acm.org/doi/abs/10.1145/3712285.3759876
https://dl.acm.org/doi/pdf/10.1145/3712285.3759876
Note that the "High-performance branch-free" paper doesn't mention
the compensation for the difference between Round-Nearest-Zero and
Round-Nearest-Even that Muller does.
I don't know if that effects its results.
The above paper wrote its examples in the Julia language.
Using algorithms from the paper below which claims to be the same:
Acceleration of multicomponent multiple-precision arithmetic with
branch-free algorithms and SIMD vectorization
https://arxiv.org/abs/2603.14926
gives the following code for a double word branch free add DWBFAdd:
typedef struct DPairS
{
-a double Val;
-a double Ext;
} DPairT, *DPairPT;
static DPairT QuickTwoSum (double a, double b)
{
-a double sum, ext;
-a sum = a + b;
-a ext = b - (sum - a);
-a return {sum, ext};
}
static DPairT TwoSum (double a, double b)
{
-a double sum, ext, tmp;
-a sum = a + b;
-a tmp = sum - a;
-a ext = (a - (sum - tmp)) + (b - tmp);
-a return {sum, ext};
}
DPairT DWBFAdd (DPairT a, DPairT b)
{
-a double g4, g5;
-a DPairT g1, g2, g3, c;
-a g1 = TwoSum (a.Val, b.Val);
-a g2 = TwoSum (a.Ext, b.Ext);
-a g3 = QuickTwoSum (g1.Val, g2.Val);
-a g4 = g1.Ext + g2.Ext;
-a g5 = g4 + g3.Ext;
-a c = QuickTwoSum (g3.Val, g5);
-a return c;
}
gives this for a double-double add:
compiled on Godbolt x86-64 GCC 16.1 -O3
# Compilation provided by Compiler Explorer at https://godbolt.org/
"DWBFAdd(DPairS, DPairS)":
-a-a-a-a-a-a-a movapd-a xmm4, xmm1
-a-a-a-a-a-a-a movapd-a xmm5, xmm0
-a-a-a-a-a-a-a addsd-a-a xmm4, xmm3
-a-a-a-a-a-a-a addsd-a-a xmm5, xmm2
-a-a-a-a-a-a-a movapd-a xmm8, xmm4
-a-a-a-a-a-a-a movapd-a xmm9, xmm4
-a-a-a-a-a-a-a movapd-a xmm7, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm8, xmm1
-a-a-a-a-a-a-a subsd-a-a xmm7, xmm0
-a-a-a-a-a-a-a movapd-a xmm6, xmm4
-a-a-a-a-a-a-a addsd-a-a xmm6, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm9, xmm8
-a-a-a-a-a-a-a subsd-a-a xmm3, xmm8
-a-a-a-a-a-a-a subsd-a-a xmm2, xmm7
-a-a-a-a-a-a-a subsd-a-a xmm1, xmm9
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm3
-a-a-a-a-a-a-a movapd-a xmm3, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm3, xmm7
-a-a-a-a-a-a-a subsd-a-a xmm0, xmm3
-a-a-a-a-a-a-a addsd-a-a xmm0, xmm2
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm0
-a-a-a-a-a-a-a movapd-a xmm0, xmm6
-a-a-a-a-a-a-a subsd-a-a xmm0, xmm5
-a-a-a-a-a-a-a subsd-a-a xmm4, xmm0
-a-a-a-a-a-a-a addsd-a-a xmm1, xmm4
-a-a-a-a-a-a-a movapd-a xmm0, xmm1
-a-a-a-a-a-a-a addsd-a-a xmm0, xmm6
-a-a-a-a-a-a-a movapd-a xmm2, xmm0
-a-a-a-a-a-a-a movq-a-a-a rdx, xmm0
-a-a-a-a-a-a-a subsd-a-a xmm2, xmm6
-a-a-a-a-a-a-a subsd-a-a xmm1, xmm2
-a-a-a-a-a-a-a movq-a-a-a rax, xmm1
-a-a-a-a-a-a-a xchg-a-a-a rax, rdx
-a-a-a-a-a-a-a movq-a-a-a xmm1, rdx
-a-a-a-a-a-a-a movq-a-a-a xmm0, rax
-a-a-a-a-a-a-a ret
That's 35 instructions for the DWAdd (excluding the RET).
There are a lot of MOV's because of the two operand operations.
I added the code for double-double multiply.
It uses FMA which requires including math.h and enabling its with a #define. >>
To get GCC to use the FMA instruction I had to use -march=haswell
which also has the effect of enabling the 3 operand instructions
which lowers the DWBFAdd instruction count to 24.
DWBFMul is 14 instructions.
#define FP_FAST_FMA (1)
#include <math.h>
static DPairT TwoProd (double a, double b)
{
DPairT c;
c.Val = a * b;
c.Ext = fma(a, b, -c.Val);
return c;
}
BGB should note: the preceding code only "works" when FMAC produces
all 106-bits of the pre-rounded product.
On 2026-Aug-05 15:27, MitchAlsup wrote:
scott@slp53.sl.home (Scott Lurndal) posted:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
Galactic evolution calculations are one. Too many individual stars
for simple double precision to be enough.
You don't need floating point to count the number of stars.
It is not the counting of stars, but the calculation of the gravitational forces of each star on each other star. Sometimes, one also has to consider the speed-of-light problems as separate from the speed-of-gravity {also known as the gravitational anomaly. If the sun disappeared instantaneously the earth would leave its orbit instantaneously, even though we could still see the light from it for 8 minutes.}
That's Newtonian gravity not relativistic.
With relativity if the sun disappeared it would take 8.5 minutes
for the relaxing of the gravity well wave to arrive.
That is similar a black hole merger where some of the total
mass suddenly disappears and is converted to gravity waves
that radiate outwards at the speed of light.
Space-time can stretch or contract faster than the speed of light,
as in the Alcubierre warp drive. https://en.wikipedia.org/wiki/Alcubierre_drive
On 8/5/2026 12:30 PM, MitchAlsup wrote:
EricP <ThatWouldBeTelling@thevillage.com> posted:
On 2026-Aug-05 13:12, Scott Lurndal wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
Torbjorn Lindgren <tl@none.invalid> posted:
I'm not ruling out that MS WANT everyone to either switch to Azure >>>>> Artifact signing (AAS) service which instead is a pay-per-sign,"Those who are willing to sacrifice liberty for safety,
starting at $10/month (max 5000 signings per month) or ship only via >>>>> the MS Store (MS resigns anything coming via the Store). That would be >>>>> very on-brand. And not everyone can get access to AAS even if they >>>>> were willing to pay a monthly fee, there's a number of requirements. >>>>
will soon have neither" Ben Franklin.
The quotation was actually
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
Franklin wrote that to support the assembly's power
to tax wealthy proprietors to pay for military defense
during the French and Indian war.
"Liberty" in this context referred to the communities
right to self-governance and ability to tax to pay for
collective self-defence"
So "liberty" is the governments freedom to choose not the citizens
(assuming few citizens would willingly tax themselves).
Liberty is the concept of being out in public without someone following
you around
Have a phone? For some reason, I don't. Its bad in case I am in an
accident or something. But, the little shit is akin to "someone
following you around"...?
(although with the number of cameras around today it can be
argued that none of us have liberty anymore.)
Well, yeah. But at least they are not mandating "gov" cameras in our
houses, yet... ;^) kidding, but funny to ponder on.
Liberty is a right manifest on the citizen by the constitution.
A right is something the *.gov is not allowed to encumber from its
citizens (without due process).
Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
Augmented Add/Mul has two source and two dest registers.
And this is a requiremnt you cannot get around.
So if you only have one write port, then the second destination gets
written one cycle later?
Terje
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version.
I would assume using a 3R form for the basic case, and 4R via a prefix-expanded case or similar.
Say:
Rd=Rs*Rt+Rd;
For example, RISC-V has 4R FMA instructions but it seems hard to justify
the *massive* chunk of encoding space they burnt on this (like, both the
P and V extensions use less encoding space than just these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to justify burning this much encoding space on it.
Augmented Add/Mul has two source and two dest registers.
And this is a requiremnt you cannot get around.
On 8/5/2026 2:35 PM, MitchAlsup wrote:---------------------
EricP <ThatWouldBeTelling@thevillage.com> posted:
#define FP_FAST_FMA (1)
#include <math.h>
static DPairT TwoProd (double a, double b)
{
DPairT c;
c.Val = a * b;
c.Ext = fma(a, b, -c.Val);
return c;
}
BGB should note: the preceding code only "works" when FMAC produces
all 106-bits of the pre-rounded product.
Yes, this is however the defined behavior of "fma()", and "fma()" is for
the cases where this behavior is actually needed, so a version that
failed to do so would in effect be kinda useless for its intended purpose...
Doesn't mean though that it needs to be a single CPU instruction
(arguably, doing this fast and in native hardware would be desirable,
but is not always realistic).
From my C library:
<===
double fma(double x, double y, double z)
{
long double x1, y1, z1, w1;
double w;
x1=x; y1=y; z1=z;
w1=x1*y1+z1;
w=w1;
return(w);
}
Where "long double" just sorta converts it to Binary128, and uses
Binary128 operations (slow, but works).
However, "fmal()" doesn't currently work correctly (still double-rounded ATM), the "TODO" here being to either implement something for full
Binary128 FMA (in software), or quietly use Binary256. Either way, this
one is a TODO item ATM.
...
BGB <cr88192@gmail.com> posted:
On 8/5/2026 2:35 PM, MitchAlsup wrote:---------------------
EricP <ThatWouldBeTelling@thevillage.com> posted:
Yes, this is however the defined behavior of "fma()", and "fma()" is for
#define FP_FAST_FMA (1)
#include <math.h>
static DPairT TwoProd (double a, double b)
{
DPairT c;
c.Val = a * b;
c.Ext = fma(a, b, -c.Val);
return c;
}
BGB should note: the preceding code only "works" when FMAC produces
all 106-bits of the pre-rounded product.
the cases where this behavior is actually needed, so a version that
failed to do so would in effect be kinda useless for its intended purpose...
The above only works when both FMUL and FMAC both produce 106-bit intermediate results.
Doesn't mean though that it needs to be a single CPU instruction
(arguably, doing this fast and in native hardware would be desirable,
but is not always realistic).
From my C library:
<===
double fma(double x, double y, double z)
{
long double x1, y1, z1, w1;
double w;
x1=x; y1=y; z1=z;
w1=x1*y1+z1;
w=w1;
return(w);
}
Where "long double" just sorta converts it to Binary128, and uses
Binary128 operations (slow, but works).
However, "fmal()" doesn't currently work correctly (still double-rounded
ATM), the "TODO" here being to either implement something for full
Binary128 FMA (in software), or quietly use Binary256. Either way, this
one is a TODO item ATM.
...
I tend to suspect, though, that instead of extending the precision to
such a great extent, and increasing the exponent range only modestly,
the more urgent need is to extend the exponent range.
Why?
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version.
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version.
I would assume using a 3R form for the basic case, and 4R via a prefix-expanded case or similar.
Say:
Rd=Rs*Rt+Rd;
BGB <cr88192@gmail.com> schrieb:
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version.
I would assume using a 3R form for the basic case, and 4R via a
prefix-expanded case or similar.
Say:
Rd=Rs*Rt+Rd;
A register move would suffice. If that is zero-cycle, there
is no need for a prefix.
A register move would suffice. If that is zero-cycle, there
is no need for a prefix.
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version.
I would assume using a 3R form for the basic case, and 4R via a prefix-expanded case or similar.
Say:
-a Rd=Rs*Rt+Rd;
For example, RISC-V has 4R FMA instructions but it seems hard to justify the *massive* chunk of encoding space they burnt on this (like, both the P and V extensions use less encoding space than just these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to justify burning this much encoding space on it.
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Yes.
Because that would just be expanded by decode into a 4 operand version.
Sure, but you need an additional register move.
MitchAlsup wrote:
Terje Mathisen <terje.mathisen@tmsw.no> posted:
Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
Augmented Add/Mul has two source and two dest registers.
And this is a requiremnt you cannot get around.
So if you only have one write port, then the second destination gets
written one cycle later?
it is not a "port" count problem, it is a result-count problem
that any renamer, RoB, or reservation station can solve.
So in effect: If an OoO cpu can retire up to 6 or 8 instructions/cycle,
then having a few instructions that supply two of those retirees would
not even cause a bubble?
Terje
Thomas Koenig <tkoenig@netcologne.de> writes:
A register move would suffice. If that is zero-cycle, there
is no need for a prefix.
Intel and AMD have had zero-cycle moves for a while. And yet they are
adding a general scheme of non-overwriting prefixes with APX (with
Nova Lake for Intel according to rumors, I have read no rumors for
AMD).
So apparently it is easier to implement such a prefix scheme than
providing the same level of performance with moves and overwriting instructions.
Why is that so? My guess is that it is due to dealing with
exceptions. Consider
reg1 <- reg2
reg1 <- reg1 op operand
If op or the access to operand can trap, the decide cannot just
optimize that to
reg1 <- reg2 op operand
because in case of a trap,
one needs to be able to produce the state
between the move and the trapping instruction. With a non-overwriting prefix, this problem does not exist.
- anton--- Synchronet 3.22a-Linux NewsLink 1.2
On 2026-Aug-05 18:41, BGB wrote:
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version.
I would assume using a 3R form for the basic case, and 4R via a
prefix-expanded case or similar.
Say:
-a-a Rd=Rs*Rt+Rd;
For example, RISC-V has 4R FMA instructions but it seems hard to
justify the *massive* chunk of encoding space they burnt on this
(like, both the P and V extensions use less encoding space than just
these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to
justify burning this much encoding space on it.
Hmmm... I don't understand the problem.
In a 32-bit instruction 4 5-bit register fields is 20 bits,
leaving 12 bits for the opcode. Bits to control negation of the
product and addend operands use 2 of those opcode bits.
So it needs 10 bits to encode the unique opcode.
I realize that doesn't fit with RV's defined instruction formats
but that's shouldn't be a technical limitation on what Decode
can handle.
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 7/28/2026 12:40 PM, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>> 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
I want to take a somewhat different approach to answering this question
than the need for precision arguments presented elsewhere in this
thread. I don't believe there will be any hardware implementation of
FP256 for at least several decades. This is based on a "register
argument". That is, I assume any hardware implementation would require
the operands to be in some kind of registers, not only in main memory.
At the current moment, FP128 use is low to at best moderate--that is we occasionally want to do FP128 calculations, but we are no where near
wanting to build architectures that concentrate heavily on FP128 {whether register based or memory based or some where in between}. FP256 has even lower use patterns.
If one is willing to say FP256 operations can take place *only* in some
kind of vector register, e.g. enhanced AVX512, not in GPRs or FPRs, then
things aren't too bad. You need new op-codes, of course, and you reduce
the number of parallel operations, but it fits reasonably well.
It screws up the reservation station models by needing to wait for 4
set of operands before starting calculations. Whether VR or GPR or FPR.
But if you want to support FP256 operations in non-vector registers,
things get ugly.
Even uglier when one considers argument and result passings.
The obvious reason is that, with the 64 bit registers
we have today, each FP256 operand requires four registers (256/64). So
a typical FP256 operation such as FPADD requiring two sources and a
destination requires 4 * 3 = 12 registers.
Which is why we can dabble in FP128 and consider dabbling in FP256
but we really don't want to go "Whole Hog" in either.
If you want any amount of
parallelism, even more are required.
I suspect the compiler's register use pattern would be fairly easy
to rename into a sufficiently high-count PRF.
Two operations in parallel require
24 registers! This leaves relatively few registers for other, typical
uses. If you have a unified registers set (i.e. no dedicated FP
registers), the register pressure is worse. As a side note, if, like
Mitch, you don't like register pairing, i.e. the instruction specifies
one register but that implies use of at least one adjacent register,
then you have to somehow specify all 12 registers in the instruction (or
instruction modifier). Ugggh!
I recently added the DBLE instruction-modifier to My 66000 ISA. DBLE is
a 3-register i-m that supplies 3 operands and 1 <more> result register
(or constants !!) to the immediately successive instruction. On lower
end machines it would decode-execute-retire as 2 instructions; on middle
end machines it would decode as one, reside in stations as 2, and then execute as one; in High end machines the pair is treated uniformly as
a single instruction. 1 instruction added, ~40 - 128-bit calculations
added to useable ISA.
The obvious solution is going from 64 to 128 bit registers. But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements. I haven't kept up, but it
used to be that these requirements grew by something like 1 bit every
2-3 years, but seemed like it was slowing down. (I welcome any updates
to these numbers). So if we are at say 54 bits now, then requiring more
than 64 bit addressing will be at least 2 decades away.
Thus, I conclude that we won't have native hardware support for FP256
for at least two decades.
Which is, of course, longer than I have left above ground.
Thomas Koenig <tkoenig@netcologne.de> writes:
A register move would suffice. If that is zero-cycle, there
is no need for a prefix.
Intel and AMD have had zero-cycle moves for a while. And yet they are
adding a general scheme of non-overwriting prefixes with APX (with
Nova Lake for Intel according to rumors, I have read no rumors for
AMD).
So apparently it is easier to implement such a prefix scheme than
providing the same level of performance with moves and overwriting instructions.
Intel and AMD are saddled up to x86 which has a destructive calculation model. 0 cycle MOVs are a way of reducing the problem. A RISC architecture would not have this problem and not need 0 cycle MOVs (to the same extent).
Stefan Monnier <monnier@iro.umontreal.ca> schrieb:[...]
I tend to suspect, though, that instead of extending the precision toWhy?
such a great extent, and increasing the exponent range only modestly,
the more urgent need is to extend the exponent range.
To be any good, such mixing needs to be chaotic, which means
exponential growth in the resulting deformation tensors. I tend
to hit the double precision limit pretty fast then.
On 8/5/2026 12:20 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 7/28/2026 12:40 PM, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>> 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming
decade (or farther out) ??
I want to take a somewhat different approach to answering this question
than the need for precision arguments presented elsewhere in this
thread. I don't believe there will be any hardware implementation of
FP256 for at least several decades. This is based on a "register
argument". That is, I assume any hardware implementation would require
the operands to be in some kind of registers, not only in main memory.
At the current moment, FP128 use is low to at best moderate--that is we occasionally want to do FP128 calculations, but we are no where near wanting to build architectures that concentrate heavily on FP128 {whether register based or memory based or some where in between}. FP256 has even lower use patterns.
If one is willing to say FP256 operations can take place *only* in some
kind of vector register, e.g. enhanced AVX512, not in GPRs or FPRs, then >> things aren't too bad. You need new op-codes, of course, and you reduce >> the number of parallel operations, but it fits reasonably well.
It screws up the reservation station models by needing to wait for 4
set of operands before starting calculations. Whether VR or GPR or FPR.
But if you want to support FP256 operations in non-vector registers,
things get ugly.
Even uglier when one considers argument and result passings.
The obvious reason is that, with the 64 bit registers >> we have today, each FP256 operand requires four registers (256/64). So
a typical FP256 operation such as FPADD requiring two sources and a
destination requires 4 * 3 = 12 registers.
Which is why we can dabble in FP128 and consider dabbling in FP256
but we really don't want to go "Whole Hog" in either.
If you want any amount of
parallelism, even more are required.
I suspect the compiler's register use pattern would be fairly easy
to rename into a sufficiently high-count PRF.
Two operations in parallel require >> 24 registers! This leaves relatively few registers for other, typical
uses. If you have a unified registers set (i.e. no dedicated FP
registers), the register pressure is worse. As a side note, if, like
Mitch, you don't like register pairing, i.e. the instruction specifies
one register but that implies use of at least one adjacent register,
then you have to somehow specify all 12 registers in the instruction (or >> instruction modifier). Ugggh!
I recently added the DBLE instruction-modifier to My 66000 ISA. DBLE is
a 3-register i-m that supplies 3 operands and 1 <more> result register
(or constants !!) to the immediately successive instruction. On lower
end machines it would decode-execute-retire as 2 instructions; on middle end machines it would decode as one, reside in stations as 2, and then execute as one; in High end machines the pair is treated uniformly as
a single instruction. 1 instruction added, ~40 - 128-bit calculations
added to useable ISA.
The obvious solution is going from 64 to 128 bit registers. But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements. I haven't kept up, but it
used to be that these requirements grew by something like 1 bit every
2-3 years, but seemed like it was slowing down. (I welcome any updates
to these numbers). So if we are at say 54 bits now, then requiring more >> than 64 bit addressing will be at least 2 decades away.
Thus, I conclude that we won't have native hardware support for FP256
for at least two decades.
Which is, of course, longer than I have left above ground.
While probably true, assuming that your architecture is wildly
successful, and far outlives you, you don't want future architects/users posthumously cursing your memory saying things like "If only he had . .
." For example, not requiring the upper byte as zero in S/360
addresses, or several things in 8086.
So I think it is worth some time thinking about trying to "future proof"
an architecture.
And since the consensus seems to be the worst mistake
in computer architecture is not allowing enough address bits, I think
you should spend a little time thinking about how the architecture would adapt to 128 bit addressing.
Just my opinion.
On 8/6/2026 9:16 AM, EricP wrote:
On 2026-Aug-05 18:41, BGB wrote:
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version. >>>
I would assume using a 3R form for the basic case, and 4R via a
prefix-expanded case or similar.
Say:
-a-a Rd=Rs*Rt+Rd;
For example, RISC-V has 4R FMA instructions but it seems hard to
justify the *massive* chunk of encoding space they burnt on this
(like, both the P and V extensions use less encoding space than just
these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to
justify burning this much encoding space on it.
Hmmm... I don't understand the problem.
In a 32-bit instruction 4 5-bit register fields is 20 bits,
leaving 12 bits for the opcode. Bits to control negation of the
product and addend operands use 2 of those opcode bits.
So it needs 10 bits to encode the unique opcode.
I realize that doesn't fit with RV's defined instruction formats
but that's shouldn't be a technical limitation on what Decode
can handle.
In RV's case, they also burn an additional:
2-bit type selector (S/D/H/Q);
3-bit rounding mode (From memory: RNE, RTZ, RDN, RUP, RMM, -, -, DYN).
So, each costs 25 bits.
Though, 20 bits would still have been steep, 25 is worse.
This puts the cost of each on par with a JAL or LUI or similar.
The 2-bit type-selector and 3-bit rounding mode is common to most of the
FPU ops in RV's case.
Though, yeah, in theory one could reuse rounding modes 5 and 6 as escape cases to reclaim some of the encoding space.
It is possible that it could make sense to evaluate widening the path between the FMUL and FADD stages in the FPU while still preserving the existing structure and ability to break these into two separate units
when needed (vs forcing the full latency every time).
This would mean an additional 52 bits routed from the FMUL to the FADD representing the low-order results of the FMUL's result (and/or a full-width result, but
with an extra clock-cycle spent on the adder chains, with the primary
output still containing the final result of a truncated multiply).
Then again, even if I still couldn't make it faster than 12 cycles,
could possibly try to make the case of "more expensive Single-Rounded
FMA is justified in that RISC-V's FMADD.D would no longer tank
performance with emulation traps...".
And, would allow for a potentially faster way to evaluate the "fma()" function.
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
A register move would suffice. If that is zero-cycle, there
is no need for a prefix.
Intel and AMD have had zero-cycle moves for a while. And yet they are adding a general scheme of non-overwriting prefixes with APX (with
Nova Lake for Intel according to rumors, I have read no rumors for
AMD).
So apparently it is easier to implement such a prefix scheme than
providing the same level of performance with moves and overwriting instructions.
Let's look at some data. Comparing POWER and x86_64 for the
number of register moves (obviously different systems, but
enough for a rough comparison)
POWER x86_64
/usr/bin/cc 8.68 % 12.13 %
/usr/bin/grep 7.39 % 10.30 %
/usr/bin/luatex 8.24 % 12.08 %
/usr/bin/emacs 6.78 % 9.77 %
I am actually a little bit surprised that the difference is not
larger, especially since register moves on POWER are not zero cost.
But apart from not having to shuffle around values in registers,
having fewer memory accesses by being able to store more values
in registers is also a big win.
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
Intel and AMD are saddled up to x86 which has a destructive calculation model. 0 cycle MOVs are a way of reducing the problem. A RISC architecture would not have this problem and not need 0 cycle MOVs (to the same extent).
Considering the numbers I just posted elsethread, I think that
zero-cycle register moves can also benefit a RISC architecture,
quite a lot. Of course those were static counts, not dynamic.
BGB <cr88192@gmail.com> posted:
On 8/6/2026 9:16 AM, EricP wrote:
On 2026-Aug-05 18:41, BGB wrote:
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version. >>>>>
I would assume using a 3R form for the basic case, and 4R via a
prefix-expanded case or similar.
Say:
-a-a Rd=Rs*Rt+Rd;
For example, RISC-V has 4R FMA instructions but it seems hard to
justify the *massive* chunk of encoding space they burnt on this
(like, both the P and V extensions use less encoding space than just
these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to
justify burning this much encoding space on it.
Hmmm... I don't understand the problem.
In a 32-bit instruction 4 5-bit register fields is 20 bits,
leaving 12 bits for the opcode. Bits to control negation of the
product and addend operands use 2 of those opcode bits.
So it needs 10 bits to encode the unique opcode.
I realize that doesn't fit with RV's defined instruction formats
but that's shouldn't be a technical limitation on what Decode
can handle.
In RV's case, they also burn an additional:
2-bit type selector (S/D/H/Q);
3-bit rounding mode (From memory: RNE, RTZ, RDN, RUP, RMM, -, -, DYN).
Well there is a waste of entropy.
So, each costs 25 bits.
Though, 20 bits would still have been steep, 25 is worse.
This puts the cost of each on par with a JAL or LUI or similar.
Nobody ever said RISC-V is peoperly encoded.
The 2-bit type-selector and 3-bit rounding mode is common to most of the
FPU ops in RV's case.
Though, yeah, in theory one could reuse rounding modes 5 and 6 as escape
cases to reclaim some of the encoding space.
Making Decode even more difficult.
-----------------
It is possible that it could make sense to evaluate widening the path
between the FMUL and FADD stages in the FPU while still preserving the
existing structure and ability to break these into two separate units
when needed (vs forcing the full latency every time).
You still (after 10 years) don't get it. You need an FMAC that is IEEE 754-2008 accurate--which requires a 53|u53 multiplier tree. There is
simply no way around this F A C T.
This would mean an
additional 52 bits routed from the FMUL to the FADD representing the
low-order results of the FMUL's result (and/or a full-width result, but
with an extra clock-cycle spent on the adder chains, with the primary
output still containing the final result of a truncated multiply).
This still does not work without the 53|u53 multiplier tree. You may
inch closer, but in IEEE-754 sense, you remain miles away.
Then again, even if I still couldn't make it faster than 12 cycles,
could possibly try to make the case of "more expensive Single-Rounded
FMA is justified in that RISC-V's FMADD.D would no longer tank
performance with emulation traps...".
And, would allow for a potentially faster way to evaluate the "fma()"
function.
Which should be an instruction !
Comparing POWER and x86_64 for the
number of register moves (obviously different systems, but
enough for a rough comparison)
POWER x86_64
/usr/bin/cc 8.68 % 12.13 %
/usr/bin/grep 7.39 % 10.30 %
/usr/bin/luatex 8.24 % 12.08 %
/usr/bin/emacs 6.78 % 9.77 %
I am actually a little bit surprised that the difference is not
larger, especially since register moves on POWER are not zero cost.
But apart from not having to shuffle around values in registers,
having fewer memory accesses by being able to store more values
in registers is also a big win.
Thomas Koenig <tkoenig@netcologne.de> posted:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
Intel and AMD are saddled up to x86 which has a destructive calculation
model. 0 cycle MOVs are a way of reducing the problem. A RISC architecture >> > would not have this problem and not need 0 cycle MOVs (to the same extent).
Considering the numbers I just posted elsethread, I think thatThe depth of the execution window determines how much latency the
zero-cycle register moves can also benefit a RISC architecture,
quite a lot. Of course those were static counts, not dynamic.
machine can tolerate without slowing down.
With EWs nearing 300
instructions
... Sometimes, one also has to consider
the speed-of-light problems as separate from the speed-of-gravity {also
known as the gravitational anomaly. If the sun disappeared instantaneously the earth would leave its orbit instantaneously, even though we could still see the light from it for 8 minutes.}
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
... Sometimes, one also has to consider
the speed-of-light problems as separate from the speed-of-gravity {also
known as the gravitational anomaly. If the sun disappeared instantaneously >> the earth would leave its orbit instantaneously, even though we could still >> see the light from it for 8 minutes.}
This is the pithiest description of the anomaly I can remember. Thank you!
While probably true, assuming that your architecture is wildly
successful, and far outlives you, you don't want future architects/users posthumously cursing your memory saying things like "If only he had . .
." For example, not requiring the upper byte as zero in S/360
addresses,
Thomas Koenig [2026-08-06 05:44:32] wrote:
Stefan Monnier <monnier@iro.umontreal.ca> schrieb:[...]
I tend to suspect, though, that instead of extending the precision toWhy?
such a great extent, and increasing the exponent range only modestly,
the more urgent need is to extend the exponent range.
To be any good, such mixing needs to be chaotic, which means
exponential growth in the resulting deformation tensors. I tend
to hit the double precision limit pretty fast then.
But the IEEE format for 128bit and 256bit formats *already* extend the exponent (to 15 and 19 bits respectively, IIRC), so would that still be insufficient? And if 19bits are still insufficient, how many
would suffice?
posthumously cursing your memory saying things like "If only he had . .
." For example, not requiring the upper byte as zero in S/360
addresses,
That was actually an error. The architecture was supposed to be
32-bit clean, but apparently some people in the huge distributed
project team didn't get the memo (possibly literally). And those
extra eight bits were just too tempting...
In later architectures they I know they avoided the mistake of not reserving unused
high order bits, but made the mistake of making the fields too small. That's what
killed the PDP-10 (yes, I know about the extended addressing hack), PDP-11, and
to some extent the Vax.
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
While probably true, assuming that your architecture is wildly
successful, and far outlives you, you don't want future architects/users posthumously cursing your memory saying things like "If only he had . .
." For example, not requiring the upper byte as zero in S/360
addresses,
That was actually an error. The architecture was supposed to be
32-bit clean, but apparently some people in the huge distributed
project team didn't get the memo (possibly literally). And those
extra eight bits were just too tempting...
Thomas Koenig <tkoenig@netcologne.de> posted:
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:The depth of the execution window determines how much latency the
Intel and AMD are saddled up to x86 which has a destructive calculation
model. 0 cycle MOVs are a way of reducing the problem. A RISC architecture >> > would not have this problem and not need 0 cycle MOVs (to the same extent).
Considering the numbers I just posted elsethread, I think that
zero-cycle register moves can also benefit a RISC architecture,
quite a lot. Of course those were static counts, not dynamic.
machine can tolerate without slowing down. With EWs nearing 300
instructions, I suspect that the gain is smaller than you surmise.
On 07/08/2026 16:31, Andy Valencia wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
... Sometimes, one also has to consider the speed-of-lightThis is the pithiest description of the anomaly I can remember.
problems as separate from the speed-of-gravity {also known as
the gravitational anomaly. If the sun disappeared
instantaneously the earth would leave its orbit
instantaneously, even though we could still see the light from
it for 8 minutes.}
Thank you!
It would be even better if it were true.
If the sun disappeared instantaneously, it would be about 8
minutes before the earth changed from a circular orbit to a
straight line (like a stone leaving a sling).
No information or effects travel through space-time faster than
the speed of light. Space-time itself can expand faster, but
that is not happening in this hypothetical case.
To be slightly more accurate, the earth is already moving in a
straight line - it is the warping of space-time that makes it
appear to be moving in an approximately circular orbit. If the
sun disappeared, the earth would continue to move in a straight
line, but the space-time would flatten out. This flattening
change moves at the speed of light.
The fact (in the sense of "the current best theory that fits
what we can measure of reality") that the "speed of gravity" is
the same as the speed of light is not just a prediction from
general relativity, it has also been confirmed in measurements
of Mercury's orbits, and seen in the way gravitational waves
work.
(Please don't ask me about "quantum entanglement" acting faster
- I am not one of the tiny number of people who genuinely
understand that, but the real physicists have figured out that
it does not let you transfer information faster than the speed
of light.)
On 8/6/2026 9:16 AM, EricP wrote:
On 2026-Aug-05 18:41, BGB wrote:
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand version. >>>>
I would assume using a 3R form for the basic case, and 4R via a prefix-expanded case or similar.
Say:
-a-a Rd=Rs*Rt+Rd;
For example, RISC-V has 4R FMA instructions but it seems hard to justify the *massive* chunk of encoding space they burnt on this (like, both the P and V extensions use less encoding space than just these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to justify burning this much encoding space on it.
Hmmm... I don't understand the problem.
In a 32-bit instruction 4 5-bit register fields is 20 bits,
leaving 12 bits for the opcode. Bits to control negation of the
product and addend operands use 2 of those opcode bits.
So it needs 10 bits to encode the unique opcode.
I realize that doesn't fit with RV's defined instruction formats
but that's shouldn't be a technical limitation on what Decode
can handle.
In RV's case, they also burn an additional:
-a 2-bit type selector (S/D/H/Q);
-a 3-bit rounding mode (From memory: RNE, RTZ, RDN, RUP, RMM, -, -, DYN).
So, each costs 25 bits.
-a Though, 20 bits would still have been steep, 25 is worse.
-a This puts the cost of each on par with a JAL or LUI or similar.
The 2-bit type-selector and 3-bit rounding mode is common to most of the FPU ops in RV's case.
On 2026-Aug-06 15:54, BGB wrote:
On 8/6/2026 9:16 AM, EricP wrote:
On 2026-Aug-05 18:41, BGB wrote:
On 8/5/2026 3:06 PM, EricP wrote:
On 2026-Aug-05 14:12, Thomas Koenig wrote:
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
FMA has 3 source and 1 dest registers.
I just looked at gnuplot and GSL (GNU Scientific Library) to
see how often this actually occurs with My 66000, which has
a four-register FMA instruction.
In GSL, it is 12.3% of FMAs, in GNUPLOT, it is 18.9%.
As opposed to what alternative, a 3 operand FMA like x84
where one register is both source and dest?
Because that would just be expanded by decode into a 4 operand
version.
I would assume using a 3R form for the basic case, and 4R via a
prefix-expanded case or similar.
Say:
-a-a Rd=Rs*Rt+Rd;
For example, RISC-V has 4R FMA instructions but it seems hard to
justify the *massive* chunk of encoding space they burnt on this
(like, both the P and V extensions use less encoding space than just
these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to
justify burning this much encoding space on it.
Hmmm... I don't understand the problem.
In a 32-bit instruction 4 5-bit register fields is 20 bits,
leaving 12 bits for the opcode. Bits to control negation of the
product and addend operands use 2 of those opcode bits.
So it needs 10 bits to encode the unique opcode.
I realize that doesn't fit with RV's defined instruction formats
but that's shouldn't be a technical limitation on what Decode
can handle.
In RV's case, they also burn an additional:
-a-a 2-bit type selector (S/D/H/Q);
-a-a 3-bit rounding mode (From memory: RNE, RTZ, RDN, RUP, RMM, -, -, DYN). >>
So, each costs 25 bits.
-a-a Though, 20 bits would still have been steep, 25 is worse.
-a-a This puts the cost of each on par with a JAL or LUI or similar.
The 2-bit type-selector and 3-bit rounding mode is common to most of
the FPU ops in RV's case.
Ok, extra H and Q data types and round mode bits.
Well, that is why one has a variable length instruction - add another granule.
I think that is better to bite the bullet on that than doing some kludge
as 48-bit instructions opens the door to a whole set of instructions
that have 4 or 5 registers like for double wide integers.
In later architectures I know they avoided the mistake of not reserving
unused high order bits, but made the mistake of making the fields too
small. That's what killed the PDP-10 (yes, I know about the extended addressing hack), PDP-11, and to some extent the Vax.
The obvious solution is going from 64 to 128 bit registers. But historically, register width is driven not by arithmetic precision requirements, but memory space requirements.
The death of the VAX, AFAICS, seems to have been due to the difficulty of >keeping it performance-competitive.
There was a separate problem with the system call interfaces in VMS, in
that the control blocks were sized in absolute numbers of bits and bytes, >rather than in terms of pointer sizes. By the time DEC had faced up to
the need for 64-bit, they couldn't afford the engineer-hours to duplicate
the interfaces for it. That still handicaps 64-bit VMS, where lots of
system calls can only address the top 2GB and the bottom 2GB, leaving a
vast space in between.
On 8/8/2026 11:36 AM, EricP wrote:
On 2026-Aug-06 15:54, BGB wrote:
On 8/6/2026 9:16 AM, EricP wrote:
On 2026-Aug-05 18:41, BGB wrote:
For example, RISC-V has 4R FMA instructions but it seems hard to justify the *massive* chunk of encoding space they burnt on this (like, both the P and V extensions use less encoding space than just these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to justify burning this much encoding space on it.
Hmmm... I don't understand the problem.
In a 32-bit instruction 4 5-bit register fields is 20 bits,
leaving 12 bits for the opcode. Bits to control negation of the
product and addend operands use 2 of those opcode bits.
So it needs 10 bits to encode the unique opcode.
I realize that doesn't fit with RV's defined instruction formats
but that's shouldn't be a technical limitation on what Decode
can handle.
In RV's case, they also burn an additional:
-a-a 2-bit type selector (S/D/H/Q);
-a-a 3-bit rounding mode (From memory: RNE, RTZ, RDN, RUP, RMM, -, -, DYN). >>>
So, each costs 25 bits.
-a-a Though, 20 bits would still have been steep, 25 is worse.
-a-a This puts the cost of each on par with a JAL or LUI or similar.
The 2-bit type-selector and 3-bit rounding mode is common to most of the FPU ops in RV's case.
Ok, extra H and Q data types and round mode bits.
Well, that is why one has a variable length instruction - add another granule.
I think that is better to bite the bullet on that than doing some kludge
as 48-bit instructions opens the door to a whole set of instructions
that have 4 or 5 registers like for double wide integers.
Yeah.
In my own ISA's, I had these as 64-bit encodings.
But, for RISC-V, it is what it is...
For RV+Jx, I am using 64-bit encodings.
Though, some 48-bit ops exist in RV-C mode, I am less inclined towards RV-C (RV-C has a performance penalty that is difficult to avoid without more advanced fetch-and-decode logic).
On 2026-Aug-08 15:43, BGB wrote:
On 8/8/2026 11:36 AM, EricP wrote:
On 2026-Aug-06 15:54, BGB wrote:
On 8/6/2026 9:16 AM, EricP wrote:
On 2026-Aug-05 18:41, BGB wrote:
For example, RISC-V has 4R FMA instructions but it seems hard to
justify the *massive* chunk of encoding space they burnt on this
(like, both the P and V extensions use less encoding space than
just these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to
justify burning this much encoding space on it.
Hmmm... I don't understand the problem.
In a 32-bit instruction 4 5-bit register fields is 20 bits,
leaving 12 bits for the opcode. Bits to control negation of the
product and addend operands use 2 of those opcode bits.
So it needs 10 bits to encode the unique opcode.
I realize that doesn't fit with RV's defined instruction formats
but that's shouldn't be a technical limitation on what Decode
can handle.
In RV's case, they also burn an additional:
-a-a 2-bit type selector (S/D/H/Q);
-a-a 3-bit rounding mode (From memory: RNE, RTZ, RDN, RUP, RMM, -, -, >>>> DYN).
So, each costs 25 bits.
-a-a Though, 20 bits would still have been steep, 25 is worse.
-a-a This puts the cost of each on par with a JAL or LUI or similar.
The 2-bit type-selector and 3-bit rounding mode is common to most of
the FPU ops in RV's case.
Ok, extra H and Q data types and round mode bits.
Well, that is why one has a variable length instruction - add another
granule.
I think that is better to bite the bullet on that than doing some kludge >>> as 48-bit instructions opens the door to a whole set of instructions
that have 4 or 5 registers like for double wide integers.
Yeah.
In my own ISA's, I had these as 64-bit encodings.
But, for RISC-V, it is what it is...
For RV+Jx, I am using 64-bit encodings.
Though, some 48-bit ops exist in RV-C mode, I am less inclined towards
RV-C (RV-C has a performance penalty that is difficult to avoid
without more advanced fetch-and-decode logic).
If you are only decoding 1 instruction per clock, the fetch-parse of variable length 48b
instructions should be relatively straight forward as there are only 3 lengths to deal with.
Instructions only stretch across 6 bytes so a 16 byte prefetch buffer
would be easiest
to manage.
My TTL risc-ish VAX-ish fetch-decode had byte granules and instructions
1 to 12 bytes long.
It required a 32 byte prefetch buffer and alignment shifter.
The description below is a subset of my fetch-parse logic retargeted for RV-C format.
For RV a 16 byte circular prefetch buffer holds aligned 8B blocks, each block with a Valid bit
and an Error bit. The Valid bit is set when the prefetcher loads an 8B
block from the I$ cache,
and cleared when the parser pulls the last byte of the block from the buffer.
The Error bit is if any error, VA translate or hardware parity/ECC
error, occurs when
trying to read the physical cache line. An error is only detected if the parser tries to
read any bytes from a block with its Error flag set. (Remember that the prefetcher is
running ahead of the parser, so it is not and error for prefetch to get
a VA translate
error - it is only an error if the parser tries to consume a byte from
that VA.)
The prefetch sequencer translates the fetch RIP-VA to PA then loads sequential 8B blocks
into the prefetch buffer. The buffer block to load is selected by PA
address bit [3].
A buffer block is loaded whenever a Valid bit indicates a block is empty *OR* is
going to become empty at the end of this cycle because the parser pulled
the bytes.
This effectively turns the I$ cache into a pipeline stage.
The alignment shifter is controlled by the RIP-VA of the fetch parser sequencer.
The parser RIP-VA address bis [3:1] controls a set of 8:1 muxes that
rotates the
buffer 16b granules + Valid and Error status bits to align the first instruction
granule with the fetch instruction buffer.
The parser then looks at the instruction length bits and checks that the Valid
bits are set and no Error bits on all the 1..3 granules in the prefetch buffer.
If all well the granules are copied into the instruction buffer along with the instructions parse RIP-VA, and set the Valid flag on the instruction buffer.
Parser then adds the instruction length to its RIP-VA and resets the block Valid bit if RIP-VA increments across an 8B boundary.
Decode sees the Valid flag set on its input instruction buffer, does its thing,
and generates an output uOp with its Valid flag into its output stage.
Other things one needs to deal with are:
- privilege modes for addresses (in my design all virtual addresses
travel with its priv mode)
- exceptions and hardware errors
- jumps
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/5/2026 12:20 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 7/28/2026 12:40 PM, MitchAlsup wrote:
At present, we have competing interest of 8-bit FP and 128-bit FP giving >>>>> 5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming >>>>> decade (or farther out) ??
I want to take a somewhat different approach to answering this question >>>> than the need for precision arguments presented elsewhere in this
thread. I don't believe there will be any hardware implementation of
FP256 for at least several decades. This is based on a "register
argument". That is, I assume any hardware implementation would require >>>> the operands to be in some kind of registers, not only in main memory.
At the current moment, FP128 use is low to at best moderate--that is we
occasionally want to do FP128 calculations, but we are no where near
wanting to build architectures that concentrate heavily on FP128 {whether >>> register based or memory based or some where in between}. FP256 has even >>> lower use patterns.
If one is willing to say FP256 operations can take place *only* in some >>>> kind of vector register, e.g. enhanced AVX512, not in GPRs or FPRs, then >>>> things aren't too bad. You need new op-codes, of course, and you reduce >>>> the number of parallel operations, but it fits reasonably well.
It screws up the reservation station models by needing to wait for 4
set of operands before starting calculations. Whether VR or GPR or FPR.
But if you want to support FP256 operations in non-vector registers,
things get ugly.
Even uglier when one considers argument and result passings.
The obvious reason is that, with the 64 bit registers >>>> we have today, each FP256 operand requires four registers (256/64). So >>>> a typical FP256 operation such as FPADD requiring two sources and a
destination requires 4 * 3 = 12 registers.
Which is why we can dabble in FP128 and consider dabbling in FP256
but we really don't want to go "Whole Hog" in either.
If you want any amount of >>>> parallelism, even more are required.
I suspect the compiler's register use pattern would be fairly easy
to rename into a sufficiently high-count PRF.
Two operations in parallel require >>>> 24 registers! This leaves relatively few registers for other, typical >>>> uses. If you have a unified registers set (i.e. no dedicated FP
registers), the register pressure is worse. As a side note, if, like
Mitch, you don't like register pairing, i.e. the instruction specifies >>>> one register but that implies use of at least one adjacent register,
then you have to somehow specify all 12 registers in the instruction (or >>>> instruction modifier). Ugggh!
I recently added the DBLE instruction-modifier to My 66000 ISA. DBLE is
a 3-register i-m that supplies 3 operands and 1 <more> result register
(or constants !!) to the immediately successive instruction. On lower
end machines it would decode-execute-retire as 2 instructions; on middle >>> end machines it would decode as one, reside in stations as 2, and then
execute as one; in High end machines the pair is treated uniformly as
a single instruction. 1 instruction added, ~40 - 128-bit calculations
added to useable ISA.
The obvious solution is going from 64 to 128 bit registers. But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements. I haven't kept up, but it >>>> used to be that these requirements grew by something like 1 bit every
2-3 years, but seemed like it was slowing down. (I welcome any updates >>>> to these numbers). So if we are at say 54 bits now, then requiring more >>>> than 64 bit addressing will be at least 2 decades away.
Thus, I conclude that we won't have native hardware support for FP256
for at least two decades.
Which is, of course, longer than I have left above ground.
While probably true, assuming that your architecture is wildly
successful, and far outlives you, you don't want future architects/users
posthumously cursing your memory saying things like "If only he had . .
." For example, not requiring the upper byte as zero in S/360
addresses, or several things in 8086.
This (amongst others) is a reason an ISA should remain "under covers"
long enough that the failing features can be identified and fixed.
So I think it is worth some time thinking about trying to "future proof"
an architecture.
You can only make the architecture live a long life. There is no such
thing as "future proof" since the future will continue for 107^79 more
years.
And since the consensus seems to be the worst mistake?
in computer architecture is not allowing enough address bits, I think
you should spend a little time thinking about how the architecture would
adapt to 128 bit addressing.
DBLE
--
Just my opinion.
In article <114vifh$32lm9$1@dont-email.me>, sfuld@alumni.cmu.edu.invalid (Stephen Fuld) wrote:
The obvious solution is going from 64 to 128 bit registers. But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements.
There were plenty of ISAs with 32-bit addressing, 32-bit integer
registers, and 64-bit floating-point registers. There are ISAs now with 64-bit integer registers and 128-bit registers for pairs of doubles.
Adding 128-bit floats to them would require new opcodes and wider FPUs,
but the register sets don't look like a problem.
On 8/6/2026 6:18 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/5/2026 12:20 PM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 7/28/2026 12:40 PM, MitchAlsup wrote:At the current moment, FP128 use is low to at best moderate--that is we >>>> occasionally want to do FP128 calculations, but we are no where near
At present, we have competing interest of 8-bit FP and 128-bit FP >>>>>> giving
5-sizes of FP containers.
How many believe that 256-bit FP will be desired/useful in the coming >>>>>> decade (or farther out) ??
I want to take a somewhat different approach to answering this
question
than the need for precision arguments presented elsewhere in this
thread.-a I don't believe there will be any hardware implementation of >>>>> FP256 for at least several decades.-a This is based on a "register
argument".-a That is, I assume any hardware implementation would
require
the operands to be in some kind of registers, not only in main memory. >>>>
wanting to build architectures that concentrate heavily on FP128
{whether
register based or memory based or some where in between}. FP256 has
even
lower use patterns.
If one is willing to say FP256 operations can take place *only* in
some
kind of vector register, e.g. enhanced AVX512, not in GPRs or FPRs, >>>>> then
things aren't too bad.-a You need new op-codes, of course, and you
reduce
the number of parallel operations, but it fits reasonably well.
It screws up the reservation station models by needing to wait for 4
set of operands before starting calculations. Whether VR or GPR or FPR. >>>>> But if you want to support FP256 operations in non-vector registers, >>>>> things get ugly.
Even uglier when one considers argument and result passings.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a The obvious reason is that, with the 64 bit
registers
we have today, each FP256 operand requires four registers
(256/64).-a So
a typical FP256 operation such as FPADD requiring two sources and a
destination requires 4 * 3 = 12 registers.
Which is why we can dabble in FP128 and consider dabbling in FP256
but we really don't want to go "Whole Hog" in either.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a If you want any
amount of
parallelism, even more are required.
I suspect the compiler's register use pattern would be fairly easy
to rename into a sufficiently high-count PRF.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a Two operations in parallel
require
24 registers!-a This leaves relatively few registers for other, typical >>>>> uses.-a If you have a unified registers set (i.e. no dedicated FP
registers), the register pressure is worse.-a As a side note, if, like >>>>> Mitch, you don't like register pairing, i.e. the instruction specifies >>>>> one register but that implies use of at least one adjacent register, >>>>> then you have to somehow specify all 12 registers in the
instruction (or
instruction modifier).-a Ugggh!
I recently added the DBLE instruction-modifier to My 66000 ISA. DBLE is >>>> a 3-register i-m that supplies 3 operands and 1 <more> result register >>>> (or constants !!) to the immediately successive instruction. On lower
end machines it would decode-execute-retire as 2 instructions; on
middle
end machines it would decode as one, reside in stations as 2, and then >>>> execute as one; in High end machines the pair is treated uniformly as
a single instruction. 1 instruction added, ~40 - 128-bit calculations
added to useable ISA.
The obvious solution is going from 64 to 128 bit registers.-a But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements.-a I haven't kept up,
but it
used to be that these requirements grew by something like 1 bit every >>>>> 2-3 years, but seemed like it was slowing down.-a (I welcome any
updates
to these numbers).-a So if we are at say 54 bits now, then requiring >>>>> more
than 64 bit addressing will be at least 2 decades away.
Thus, I conclude that we won't have native hardware support for FP256 >>>>> for at least two decades.
Which is, of course, longer than I have left above ground.
While probably true, assuming that your architecture is wildly
successful, and far outlives you, you don't want future architects/users >>> posthumously cursing your memory saying things like "If only he had . .
."-a For example, not requiring the upper byte as zero in S/360
addresses, or several things in 8086.
This (amongst others) is a reason an ISA should remain "under covers"
long enough that the failing features can be identified and fixed.
So I think it is worth some time thinking about trying to "future proof" >>> an architecture.
You can only make the architecture live a long life. There is no such
thing as "future proof" since the future will continue for 107^79 more
years.
Sure.-a The two oldest currently evolving architectures, S/360 and X86,
are still going after about 6-8 decades.-a And if the trend of linear address expansion continues at the same pace, the transition from 128 to
256 won't occur for well over two centuries, I suspect the 64-128
transition will be the last one.-a So lets restrict it to that one.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a And since the consensus seems to be the worst mistake?
in computer architecture is not allowing enough address bits, I think
you should spend a little time thinking about how the architecture would >>> adapt to 128 bit addressing.
DBLE
Huh?-a So are you saying that there won't be some future version of My
66000 that has 128 bit GPRs and thus will require a DBLE instruction modifier for every load and store in case the address exceeds 64 bits?
That doesn't seem right.
Just my opinion.
On 8/9/2026 4:36 AM, John Dallman wrote:
In article <114vifh$32lm9$1@dont-email.me>, sfuld@alumni.cmu.edu.invalid
(Stephen Fuld) wrote:
The obvious solution is going from 64 to 128 bit registers.-a But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements.
There were plenty of ISAs with 32-bit addressing, 32-bit integer
registers, and 64-bit floating-point registers. There are ISAs now with
64-bit integer registers and 128-bit registers for pairs of doubles.
Adding 128-bit floats to them would require new opcodes and wider FPUs,
but the register sets don't look like a problem.
Good point!-a-a That is an argument for separate FP and GPRs, instead of a unified register set.-a But if the requirement for larger address space (thus GPRs) is what drives register size, then I am not sure that
allowing double sized FPRs is such a big advantage.
On 8/6/2026 6:18 PM, MitchAlsup wrote:--------------------
This (amongst others) is a reason an ISA should remain "under covers"
long enough that the failing features can be identified and fixed.
So I think it is worth some time thinking about trying to "future proof" >> an architecture.
You can only make the architecture live a long life. There is no such
thing as "future proof" since the future will continue for 107^79 more years.
Sure. The two oldest currently evolving architectures, S/360 and X86,
are still going after about 6-8 decades. And if the trend of linear
address expansion continues at the same pace, the transition from 128 to
256 won't occur for well over two centuries, I suspect the 64-128
transition will be the last one. So lets restrict it to that one.
And since the consensus seems to be the worst mistake >> in computer architecture is not allowing enough address bits, I think?
you should spend a little time thinking about how the architecture would >> adapt to 128 bit addressing.
DBLE
Huh? So are you saying that there won't be some future version of My
66000 that has 128 bit GPRs and thus will require a DBLE instruction modifier for every load and store in case the address exceeds 64 bits?
That doesn't seem right.
--- Synchronet 3.22a-Linux NewsLink 1.2
Just my opinion.
On 8/9/2026 4:36 AM, John Dallman wrote:
In article <114vifh$32lm9$1@dont-email.me>, sfuld@alumni.cmu.edu.invalid (Stephen Fuld) wrote:
The obvious solution is going from 64 to 128 bit registers. But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements.
There were plenty of ISAs with 32-bit addressing, 32-bit integer
registers, and 64-bit floating-point registers. There are ISAs now with 64-bit integer registers and 128-bit registers for pairs of doubles.
Adding 128-bit floats to them would require new opcodes and wider FPUs,
but the register sets don't look like a problem.
Good point! That is an argument for separate FP and GPRs, instead of a unified register set. But if the requirement for larger address space
(thus GPRs) is what drives register size, then I am not sure that
allowing double sized FPRs is such a big advantage.
On 8/10/2026 2:22 PM, Stephen Fuld wrote:
On 8/9/2026 4:36 AM, John Dallman wrote:
In article <114vifh$32lm9$1@dont-email.me>, sfuld@alumni.cmu.edu.invalid >> (Stephen Fuld) wrote:
The obvious solution is going from 64 to 128 bit registers.-a But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements.
There were plenty of ISAs with 32-bit addressing, 32-bit integer
registers, and 64-bit floating-point registers. There are ISAs now with
64-bit integer registers and 128-bit registers for pairs of doubles.
Adding 128-bit floats to them would require new opcodes and wider FPUs,
but the register sets don't look like a problem.
Good point!-a-a That is an argument for separate FP and GPRs, instead of a unified register set.-a But if the requirement for larger address space (thus GPRs) is what drives register size, then I am not sure that
allowing double sized FPRs is such a big advantage.
If one really must have them, IMO may as well make all the registers 128 bits. Then you can have big addresses and/or capabilities, as well as
maybe 128 bit integers.
IMO, 128-bit integers are kinda useful, but native support is still
pretty rare in any mainstream ISAs (despite it not actually being all
that expensive to implement by reusing 64-bit ALUs internally).
Though, granted, would be more expensive if the 64-bit CPU is actually internally 32-bit but merely playing dress-up as 64-bit (using a similar trick to using a 64-bit pipeline to support 128-bit ALU ops by
internally splitting them in half across two lanes or similar).
...
The obvious reason is that, with the 64 bit registersWhich is why we can dabble in FP128 and consider dabbling in FP256
we have today, each FP256 operand requires four registers (256/64). So
a typical FP256 operation such as FPADD requiring two sources and a
destination requires 4 * 3 = 12 registers.
but we really don't want to go "Whole Hog" in either.
BGB <cr88192@gmail.com> posted:
On 8/10/2026 2:22 PM, Stephen Fuld wrote:
On 8/9/2026 4:36 AM, John Dallman wrote:
In article <114vifh$32lm9$1@dont-email.me>, sfuld@alumni.cmu.edu.invalid >>>> (Stephen Fuld) wrote:
The obvious solution is going from 64 to 128 bit registers.-a But
historically, register width is driven not by arithmetic precision
requirements, but memory space requirements.
There were plenty of ISAs with 32-bit addressing, 32-bit integer
registers, and 64-bit floating-point registers. There are ISAs now with >>>> 64-bit integer registers and 128-bit registers for pairs of doubles.
Adding 128-bit floats to them would require new opcodes and wider FPUs, >>>> but the register sets don't look like a problem.
Good point!-a-a That is an argument for separate FP and GPRs, instead of a >>> unified register set.-a But if the requirement for larger address space
(thus GPRs) is what drives register size, then I am not sure that
allowing double sized FPRs is such a big advantage.
If one really must have them, IMO may as well make all the registers 128
bits. Then you can have big addresses and/or capabilities, as well as
maybe 128 bit integers.
IMO, 128-bit integers are kinda useful, but native support is still
pretty rare in any mainstream ISAs (despite it not actually being all
that expensive to implement by reusing 64-bit ALUs internally).
Though, granted, would be more expensive if the 64-bit CPU is actually
internally 32-bit but merely playing dress-up as 64-bit (using a similar
trick to using a 64-bit pipeline to support 128-bit ALU ops by
internally splitting them in half across two lanes or similar).
On the other hand, using 64-bit ALUs to serially calculate 128-bit
stuff does seem to be reasonable so long as 64-bit stuff is close
to optimal {pipeline, circuits, sequencing}. So, adding 128-bit
stuff to a microarchitecture which is inherently 64-bits seems
reasonable--so long as it does not screw up the 64-bit stuff.
On the FP side, one needs 3 more bits in the exponent path, and
sequencing {multi-cycle calculations as if in microcode-but just
using hardwired sequencing.}
...
The obvious reason is that, with the 64 bit registers >>> we have today, each FP256 operand requires four registers (256/64). SoWhich is why we can dabble in FP128 and consider dabbling in FP256
a typical FP256 operation such as FPADD requiring two sources and a
destination requires 4 * 3 = 12 registers.
but we really don't want to go "Whole Hog" in either.
Probably more useful at this point would be instructions that can help implement FP256 libraries (and hopefully FP96, FP128, FP192, FP512, ...).
=== Stefan
Good point! That is an argument for separate FP and GPRs, instead
of a unified register set. But if the requirement for larger
address space (thus GPRs) is what drives register size, then I am
not sure that allowing double sized FPRs is such a big advantage.
By the time DEC had faced up to the need for 64-bit, they
couldn't afford the engineer-hours to duplicate the interfaces
for it. That still handicaps 64-bit VMS, where lots of
system calls can only address the top 2GB and the bottom 2GB,
leaving a vast space in between.
It's unclear to me what the problem is. Why not just add additional
system calls with full 64-bit addresses, and have the old system
calls as stubs that call the new ones?
In article <2026Aug9.180501@mips.complang.tuwien.ac.at>, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
By the time DEC had faced up to the need for 64-bit, they
couldn't afford the engineer-hours to duplicate the interfaces
for it. That still handicaps 64-bit VMS, where lots of
system calls can only address the top 2GB and the bottom 2GB,
leaving a vast space in between.
It's unclear to me what the problem is. Why not just add additional
system calls with full 64-bit addresses, and have the old system
calls as stubs that call the new ones?
The VMS system calls are not designed round C calling conventions.
They're usable to lots of different languages that DEC supported, which
DEC achieved by specifying everything in absolute sizes and implementing
it in assembler and BLISS. That meant doing 64-bit interfaces would have taken engineer-years they felt they couldn't afford.
By the time 8GB of
RAM was cheap, they'd been taken over by Compaq, and then HP, neither of which was interested in spending money on fixing DEC's technical debt.
John Dallman <jgd@cix.co.uk> schrieb:
In article <2026Aug9.180501@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
By the time DEC had faced up to the need for 64-bit, they
couldn't afford the engineer-hours to duplicate the interfaces
for it. That still handicaps 64-bit VMS, where lots of
system calls can only address the top 2GB and the bottom 2GB,
leaving a vast space in between.
It's unclear to me what the problem is. Why not just add additional
system calls with full 64-bit addresses, and have the old system
calls as stubs that call the new ones?
The VMS system calls are not designed round C calling conventions.
They're usable to lots of different languages that DEC supported, which
DEC achieved by specifying everything in absolute sizes and implementing
it in assembler and BLISS. That meant doing 64-bit interfaces would have
taken engineer-years they felt they couldn't afford.
(I've never worked with VMS, but I have met fans).
I am just browsing through the "OpenVMS Alpha
Guide to 64-Bit Addressing and VLM Features" at >https://www0.mi.infn.it/~calcolo/OpenVMS/ssb71/6467/6467p.htm
Seems they had 32-bit system services, which only worked with
32-bit addresses (sign-extended), serives with 64-bit friendly
interface (which just worked) and 64-bit system services, which
were 64-bit only.
So, they had something, and it looked a bit messy, but that was
probably inevitable.
On 8/10/2026 9:29 AM, EricP wrote:
On 2026-Aug-08 15:43, BGB wrote:
On 8/8/2026 11:36 AM, EricP wrote:
On 2026-Aug-06 15:54, BGB wrote:
On 8/6/2026 9:16 AM, EricP wrote:
On 2026-Aug-05 18:41, BGB wrote:
For example, RISC-V has 4R FMA instructions but it seems hard to justify the *massive* chunk of encoding space they burnt on this (like, both the P and V extensions use less encoding space than just these instructions)..
The full 4R FMA instructions aren't used anywhere near enough to justify burning this much encoding space on it.
Hmmm... I don't understand the problem.
In a 32-bit instruction 4 5-bit register fields is 20 bits,
leaving 12 bits for the opcode. Bits to control negation of the
product and addend operands use 2 of those opcode bits.
So it needs 10 bits to encode the unique opcode.
I realize that doesn't fit with RV's defined instruction formats
but that's shouldn't be a technical limitation on what Decode
can handle.
In RV's case, they also burn an additional:
-a-a 2-bit type selector (S/D/H/Q);
-a-a 3-bit rounding mode (From memory: RNE, RTZ, RDN, RUP, RMM, -, -, DYN).
So, each costs 25 bits.
-a-a Though, 20 bits would still have been steep, 25 is worse.
-a-a This puts the cost of each on par with a JAL or LUI or similar. >>>>>
The 2-bit type-selector and 3-bit rounding mode is common to most of the FPU ops in RV's case.
Ok, extra H and Q data types and round mode bits.
Well, that is why one has a variable length instruction - add another granule.
I think that is better to bite the bullet on that than doing some kludge >>>> as 48-bit instructions opens the door to a whole set of instructions
that have 4 or 5 registers like for double wide integers.
Yeah.
In my own ISA's, I had these as 64-bit encodings.
But, for RISC-V, it is what it is...
For RV+Jx, I am using 64-bit encodings.
Though, some 48-bit ops exist in RV-C mode, I am less inclined towards RV-C (RV-C has a performance penalty that is difficult to avoid without more advanced fetch-and-decode logic).
If you are only decoding 1 instruction per clock, the fetch-parse of variable length 48b
instructions should be relatively straight forward as there are only 3 lengths to deal with.
Instructions only stretch across 6 bytes so a 16 byte prefetch buffer would be easiest
to manage.
For RV-C (and misaligned 32-bit ops), it falls back to only 1 instruction per clock.
Even if the superscalar isn't particularly effective much of the time, it can still offer enough benefit to see an impact for code that largely drops to a maximum of 1 instruction per cycle.
As noted, for RV64G and XG3, it can potentially fetch up to 3 instructions per cycle.
It seems that in some cases, this can perform well. Mostly depends on having enough logic in a basic-block with independent instructions that the compiler can effectively shuffle it into independent instruction chains.
Tight loops and highly-dependent chains effectively are the poorly performing cases.
My TTL risc-ish VAX-ish fetch-decode had byte granules and instructions 1 to 12 bytes long.
It required a 32 byte prefetch buffer and alignment shifter.
The description below is a subset of my fetch-parse logic retargeted for RV-C format.
For RV a 16 byte circular prefetch buffer holds aligned 8B blocks, each block with a Valid bit
and an Error bit. The Valid bit is set when the prefetcher loads an 8B block from the I$ cache,
and cleared when the parser pulls the last byte of the block from the buffer.
The Error bit is if any error, VA translate or hardware parity/ECC error, occurs when
trying to read the physical cache line. An error is only detected if the parser tries to
read any bytes from a block with its Error flag set. (Remember that the prefetcher is
running ahead of the parser, so it is not and error for prefetch to get a VA translate
error - it is only an error if the parser tries to consume a byte from that VA.)
The prefetch sequencer translates the fetch RIP-VA to PA then loads sequential 8B blocks
into the prefetch buffer. The buffer block to load is selected by PA address bit [3].
A buffer block is loaded whenever a Valid bit indicates a block is empty *OR* is
going to become empty at the end of this cycle because the parser pulled the bytes.
This effectively turns the I$ cache into a pipeline stage.
The alignment shifter is controlled by the RIP-VA of the fetch parser sequencer.
The parser RIP-VA address bis [3:1] controls a set of 8:1 muxes that rotates the
buffer 16b granules + Valid and Error status bits to align the first instruction
granule with the fetch instruction buffer.
The parser then looks at the instruction length bits and checks that the Valid
bits are set and no Error bits on all the 1..3 granules in the prefetch buffer.
If all well the granules are copied into the instruction buffer along with >> the instructions parse RIP-VA, and set the Valid flag on the instruction buffer.
Parser then adds the instruction length to its RIP-VA and resets the block >> Valid bit if RIP-VA increments across an 8B boundary.
Decode sees the Valid flag set on its input instruction buffer, does its thing,
and generates an output uOp with its Valid flag into its output stage.
Other things one needs to deal with are:
- privilege modes for addresses (in my design all virtual addresses travel with its priv mode)
- exceptions and hardware errors
- jumps
My approach is a little different:
You have two parallel arrays of 512 x 16 bytes (Even and Odd);
You have tag bits for each array, which encode:
-a Address of fetched line;
-a Relevant operating mode bits;
Bits used to encode the length and superscalar status of the relevant words.
Typically, when fetching a line, it looks at the instruction words and figures out the lengths and similar based on the mode, including superscalar status.
It determines length-status for every 16-bit multiple, but superscalar status only for 32-bit multiples.
So, say, per 32-bit word:
-a 4b: 32-bit aligned part
-a-a-a Jumbo, WEX, JWX=Jumbo|(WXE&WEX)
-a-a-a Sz=32/16
And, 16-bit part:
-a 2b: Sz=32/16, Jumbo
In XG1/XG2:
The Jumbo/WEX bits are determined purely based on the instruction word, as is Sz.
For RV and XG3:
Jumbo is determined from the instruction word;
Sz: Always 0 for XG3; Set if RV-C.
WEX: Inferred from superscalar logic.
JWX: Jumbo|WEX.
-a In the mode encoding, WXE simply selects between RV64GC and XG3 modes.
-a Rather than Enabling/Disabling WEX in XG1/XG2.
-a-a-a In XG1/XG2, WXE depended on pipeline compatibility for the code.
-a-a-a If trying to run code built for the wrong pipeline, WXE was cleared.
Determining the WEX bit (RV/XG3):
-a Lookup pipeline allowance bits;
-a-a-a Can run in Lane 2
-a-a-a Can run in Lane 3
-a-a-a Can run in Lane 1 with co-op in Lane2
-a-a-a Can run in Lane 1 with co-op in Lane3
Then, register alias checking:
-a Rd, Rs, Rt:
-a-a-a Rd1==Rs2 || Rd1==Rt2 || Rd1==Rd2
-a-a-a Rd2==Rs1 || Rd2==Rt1 || Rd1==Rd2
-a For 3-wide fetch:
-a-a-a Repeat above 2 more times, 1/3 and 2/3.
-a-a-a If OK for the former, but not the latter, 2-wide.
Currently this logic is split between RV and XG3, as cross-ISA checking added too much cost (was cheaper to do this for two separate ISAs than to do it between instruction layouts).
Then, for final WEX bit, it is a case of:
-a Would this combination be allowed in the pipeline?
-a Are there no aliases?
With this logic, one can determine the virtual WEX bit for each instruction word; albeit (when done on L2 fetch) the end of a cache line is an invisible wall (WEX status must always come back as 0).
This allows various patterns (0000=all scalar):
-a 0000, 0010, 0100, 0110, 1000, 1010, 1100
Though, if one were to collapse all the legal patterns of Sz and JWX, could probably fit all possible combinations into ~ 7 or 8 bits per cache-line.
In this case, the Sz and JWX bits need to be kept for the Fetch stage.
IF stage:One way I can see for decoding multiple variable length instructions
-a Fetch cache lines from arrays;
-a Check Hit/Miss;
-a Fetch 96-bit block based on PC;
-a Fetch relevant Sz and JWX bits based on PC;
-a Feed Sz and JWX bits through a lookup to determine fetch length;
-a-a-a 2/4/6/8/12 bytes.
-a Do instruction repacking (for XG3 and parts of RV-C):
-a-a-a Normalizes instructions to an internal format for the decoders.
ID stage:
-a Run branch predictor;
-a Run the 3 parallel decoders;
-a Select the outputs based on fetch width and instruction types.
-a-a-a Fills Lane 1/2/3.
Thomas Koenig <tkoenig@netcologne.de> writes:
John Dallman <jgd@cix.co.uk> schrieb:
In article <2026Aug9.180501@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
By the time DEC had faced up to the need for 64-bit, they
couldn't afford the engineer-hours to duplicate the interfaces
for it. That still handicaps 64-bit VMS, where lots of
system calls can only address the top 2GB and the bottom 2GB,
leaving a vast space in between.
It's unclear to me what the problem is. Why not just add additional
system calls with full 64-bit addresses, and have the old system
calls as stubs that call the new ones?
The VMS system calls are not designed round C calling conventions.
They're usable to lots of different languages that DEC supported, which
DEC achieved by specifying everything in absolute sizes and implementing >> it in assembler and BLISS. That meant doing 64-bit interfaces would have >> taken engineer-years they felt they couldn't afford.
(I've never worked with VMS, but I have met fans).
I am just browsing through the "OpenVMS Alpha
Guide to 64-Bit Addressing and VLM Features" at >https://www0.mi.infn.it/~calcolo/OpenVMS/ssb71/6467/6467p.htm
Seems they had 32-bit system services, which only worked with
32-bit addresses (sign-extended), serives with 64-bit friendly
interface (which just worked) and 64-bit system services, which
were 64-bit only.
So, they had something, and it looked a bit messy, but that was
probably inevitable.
"Messy" was de riguour when dealing with the 32-bit to
64-bit transition for most operating systems. Parallel
32-bit and 64-bit APIs were not uncommon in Unix or Linux.
The Large File Summit, which was charged with enabling 64-bit filesystem offsets on 32-bit unix-like operating systems was an early effort--- Synchronet 3.22a-Linux NewsLink 1.2
to standardize such efforts across multiple vendors.
On 2026-Aug-10 13:59, BGB wrote:---------merciful snip-----------
On 8/10/2026 9:29 AM, EricP wrote:
On 2026-Aug-08 15:43, BGB wrote:
On 8/8/2026 11:36 AM, EricP wrote:
On 2026-Aug-06 15:54, BGB wrote:
On 8/6/2026 9:16 AM, EricP wrote:
On 2026-Aug-05 18:41, BGB wrote:
My approach is a little different:
You have two parallel arrays of 512 x 16 bytes (Even and Odd);
You have tag bits for each array, which encode:
-a Address of fetched line;
-a Relevant operating mode bits;
Bits used to encode the length and superscalar status of the relevant words.
Typically, when fetching a line, it looks at the instruction words and figures out the lengths and similar based on the mode, including superscalar status.
It determines length-status for every 16-bit multiple, but superscalar status only for 32-bit multiples.
You would have to read multiple cache lines just in case an instruction straddles a cache line.
One way I can see for decoding multiple variable length instructions
is a staggered overlapping tree of decoders. To decode 4 instructions of
1..3 16b granules needs a 64B circular prefetch buffer feeding 12 decoders.
All 12 decoders examine the fetch buffer in parallel, with the selection
of which 4 decoder outputs to use made by propagating the sum of the instructions lengths from low to high. That allows the output selection critical path to work in parallel with each decode critical path.
It also means a giant mux on the output to select 4 of the 12 decoder outputs.
FG = 16b Fetch Granule
F...F F F F F
G G G G G G
6 4 3 2 1 0
4 | | | | |
v v v v v v
--ROTATE_64B--
| | | | |
| | v v v
| | Decode0
| | | | |
| v v v |
| Decode1 |
| | | | |
v v v | |
Decode2 | |
| | | |
v v v v
I... I I I
1 0 0 0
2 2 1 0
--SELECT_MUX--
| | | |
v v v v
scott@slp53.sl.home (Scott Lurndal) posted:
"Messy" was de riguour when dealing with the 32-bit to
64-bit transition for most operating systems. Parallel
32-bit and 64-bit APIs were not uncommon in Unix or Linux.
Does anyone think the 64->128 bit transition will be any
more messy or less messy ?
scott@slp53.sl.home (Scott Lurndal) posted:
"Messy" was de riguour when dealing with the 32-bit to
64-bit transition for most operating systems. Parallel
32-bit and 64-bit APIs were not uncommon in Unix or Linux.
Does anyone think the 64->128 bit transition will be any
more messy or less messy ?
scott@slp53.sl.home (Scott Lurndal) posted:
Thomas Koenig <tkoenig@netcologne.de> writes:
John Dallman <jgd@cix.co.uk> schrieb:
In article <2026Aug9.180501@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
By the time DEC had faced up to the need for 64-bit, they
couldn't afford the engineer-hours to duplicate the interfaces
for it. That still handicaps 64-bit VMS, where lots of
system calls can only address the top 2GB and the bottom 2GB,
leaving a vast space in between.
It's unclear to me what the problem is. Why not just add additional
system calls with full 64-bit addresses, and have the old system
calls as stubs that call the new ones?
The VMS system calls are not designed round C calling conventions.
They're usable to lots of different languages that DEC supported, which >> >> DEC achieved by specifying everything in absolute sizes and implementing >> >> it in assembler and BLISS. That meant doing 64-bit interfaces would have >> >> taken engineer-years they felt they couldn't afford.
(I've never worked with VMS, but I have met fans).
I am just browsing through the "OpenVMS Alpha
Guide to 64-Bit Addressing and VLM Features" at
https://www0.mi.infn.it/~calcolo/OpenVMS/ssb71/6467/6467p.htm
Seems they had 32-bit system services, which only worked with
32-bit addresses (sign-extended), serives with 64-bit friendly
interface (which just worked) and 64-bit system services, which
were 64-bit only.
So, they had something, and it looked a bit messy, but that was
probably inevitable.
"Messy" was de riguour when dealing with the 32-bit to
64-bit transition for most operating systems. Parallel
32-bit and 64-bit APIs were not uncommon in Unix or Linux.
Does anyone think the 64->128 bit transition will be any
more messy or less messy ?
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
scott@slp53.sl.home (Scott Lurndal) posted:
"Messy" was de riguour when dealing with the 32-bit to
64-bit transition for most operating systems. Parallel
32-bit and 64-bit APIs were not uncommon in Unix or Linux.
Does anyone think the 64->128 bit transition will be any
more messy or less messy ?
My first instinct is "more". From the start of the 32-bit age for
Unix around 1980 until the start of the 64-bit age around 1992 there
were only 12 years. I don't expect commercially relevant 128-bit architectures to appear before 2050, if ever (RAM growth has slowed
down even before prices went up, and I expect that it will ever grow
more slowly in the future). So by then there will be more than 50
years of programs nearly all of which (except, of course, Thomas
Koenig's programs) are not 128-bit clean (whatever that may mean;
maybe they will be smart enough to go for ILP128 this time), and many
of which are larger than the programs from the 32-bit era.
OTOH, these days we have AI to help with code cleanup (but also AI to
help write much larger amounts of unclean code), so by investing
computing power on the order of a few TWh (the going currency for
computing power in AI), we may be able to turn all the 64-bit legacy
code into 128-bit clean code.
On the gripping hand, do we actually need to turn a lot of software to
be able to run in 128-bit address spaces? If my guess about the
slowing and maybe eventually stopping growth becomes reality, for most programs 64-bit address space will be good enough forever, and we
don't need to convert them.
128-bit integer and fp will happen much sooner!
It appears that Terje Mathisen <terje.mathisen@tmsw.no> said:
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah, much sooner.
It appears that Terje Mathisen <terje.mathisen@tmsw.no> said:<snip>
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah, much sooner.
But anyway, we've had some kind of 128 bit FP for almost 60 years, and we've >had 128 IEEE FP for at least 30. This isn't new.
John Levine <johnl@taugh.com> writes:
It appears that Terje Mathisen <terje.mathisen@tmsw.no> said:
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah,<snip>
much sooner.
But anyway, we've had some kind of 128 bit FP for almost 60 years,
and we've had 128 IEEE FP for at least 30. This isn't new.
The Burroughs B3500 had 400-bit (100 digit) FP mantissas in 1966.
It turned out that customers (mainly financial) were happy with the
100 digit integer fixed point formats and the 408-bit FP format was
removed from the next generation (B4800) processors and replaced with
a single smaller (20 digit mantissa, 2 digit exponent) floating
point accumulator.
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
scott@slp53.sl.home (Scott Lurndal) posted:
"Messy" was de riguour when dealing with the 32-bit to
64-bit transition for most operating systems. Parallel
32-bit and 64-bit APIs were not uncommon in Unix or Linux.
Does anyone think the 64->128 bit transition will be any
more messy or less messy ?
First, it is a question if, and when, it will become necessary.
I don't see it for memory sizes soon (like "in my lifetime").
If more bits are needed, they would have to carry some extra
information, like capabilities.
Storage sizes... there 64 bit may already be close (as in not
too many powers of two) to the limit.
But if it ever happens: I32LP64 mostly cleaned up the assumptions
about integer size == pointer size, which was the main problem in
legacy software.
Now we are left with sizeof(long) == sizeof(void *), which does
not hold on Windows, at least. So, my guess would be not quite
as messy. APIs should take care of most of it.
But let's not forget... 2**64 is a humunguous number, it is
~ 1/30000 of a *mole*.
It appears that Terje Mathisen<terje.mathisen@tmsw.no> said:
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah, much sooner.
The data format was by current standards rather odd. An extended format number
was stored as a pair of long format numbers, stored in a pair of floating poitn
registers, with the exponent of the second one 14 less than the first, since there were 14 hex digits in the fraction of each part. The system ignored the sign and exponent in the low part but set it consistently in instruction results.
On Wed, 12 Aug 2026 18:52:27 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
John Levine <johnl@taugh.com> writes:
It appears that Terje Mathisen <terje.mathisen@tmsw.no> said:<snip>
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah,
much sooner.
But anyway, we've had some kind of 128 bit FP for almost 60 years,
and we've had 128 IEEE FP for at least 30. This isn't new.
The Burroughs B3500 had 400-bit (100 digit) FP mantissas in 1966.
It turned out that customers (mainly financial) were happy with the
100 digit integer fixed point formats and the 408-bit FP format was
removed from the next generation (B4800) processors and replaced with
a single smaller (20 digit mantissa, 2 digit exponent) floating
point accumulator.
Either because customers were happy with 100 digit integer or
because they were unhappy witth speed of 100 digit FP.
On 8/12/2026 12:57 AM, Thomas Koenig wrote:
HDD sizes:
Well, now one can potentially get a 12TB or so, but 4TB/6TB is more
typical for new "big" drives.
When did 1TB drives start showing up? Around 2007 or so. So, 19 years,
for a reasonable maximum of around 3.5 bits or so...
Recently got ahold of some used 2TB drives, still good.
Date of manufacture: 2018.
So, 1 decade, HDD size doubled.
SSDs showed up, and are smaller. Still, a multi-TB SSD is pretty
expensive, and also are seeing neither rapid size gains nor price drops.
On the gripping hand, do we actually need to turn a lot of software to
be able to run in 128-bit address spaces? If my guess about the
slowing and maybe eventually stopping growth becomes reality, for most programs 64-bit address space will be good enough forever, and we
don't need to convert them.
BGB <cr88192@gmail.com> writes:
On 8/12/2026 12:57 AM, Thomas Koenig wrote:
HDD sizes:
Well, now one can potentially get a 12TB or so, but 4TB/6TB is more
typical for new "big" drives.
You are behind the times, seagate offers drives with more than
40TB.
When did 1TB drives start showing up? Around 2007 or so. So, 19 years,
for a reasonable maximum of around 3.5 bits or so...
Recently got ahold of some used 2TB drives, still good.
Date of manufacture: 2018.
So, 1 decade, HDD size doubled.
SSDs showed up, and are smaller. Still, a multi-TB SSD is pretty
expensive, and also are seeing neither rapid size gains nor price drops.
NVME has eclipsed (and at the high-end superceeded) SSD drives.
The largest NVMe drives store up to 512TB, and petabytes aren't
far away.
https://www.techradar.com/pro/the-worlds-largest-ssd-is-here-dapustor-unveils-a-massive-512tb-drive
Flash prices are currently inflated by the ML bubble, with most
production pre-sold for the next two years or more. Expect them
to go up until the bubble pops.
On 8/11/2026 2:21 PM, MitchAlsup wrote:
[...]
For some reason this reminds me of the 63 bit counter lockless counter
algo from Joe Seigh. I think this is it:
https://groups.google.com/g/comp.lang.asm.x86/c/FScbTaQEYLc/m/HueJj2wTqQUJ
It appears that Terje Mathisen <terje.mathisen@tmsw.no> said:
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah, much sooner.
The data format was by current standards rather odd. An extended format number
was stored as a pair of long format numbers, stored in a pair of floating poitn
registers, with the exponent of the second one 14 less than the first, since there were 14 hex digits in the fraction of each part. The system ignored the sign and exponent in the low part but set it consistently in instruction results. The instructions were add, subtract, multiply, multiply long with extended result, and round from extended to long. You could lengthen from long
to extended by making the second part zero. There was no extended compare but it
was easy to fake, long compare of the high parts, if they're equal compare the
low parts. All formats had the same 7 bit exponent which since it was hex FP was roughly equivalent to a 9 bit binary exponent.
They've carried this forward through 370/XA, 370 and zSeries. S/390 added a few
new instructions like square root.
S/390 added IEEE binary floating point including a 128 bit format with a 15 bit
binary exponent. The 128 bit numbers are still stored in pairs of floating registers
but the instruction set is more complete, including comarisons and division, and there
are now 16 FP registers rather than just 4.
zSeries added decimal floating point, again with a 128 bit format.
The two-part format seems odd to us but it was typical of the era. The 7094's single precision floating point instructions produced two word results, as two
floating numbers in the AC and MQ registers with the second having a suitably smaller exponent. It also had double add, subtract, multiply, and divide using
that format. The first model of the PDP-10 used a similar double format but later ones switched to one with a single exponent and more fraction bits.
I believe that the reason they added the extended format to the 360/85 was due
to well justified complaints that the 360's FP was much worse than the 7094's.
The 7094's double precision had two 27-bit fractions for a total of 54 fraction--- Synchronet 3.22a-Linux NewsLink 1.2
bits in a 72 bit word pair. A S/360 long had 14 hex digits or nominally 56 bits, but due to its wobbling precision, it lost 2 or 3 bits on each operation.
So they added extended precision which was definitely better than 54 bits.
But anyway, we've had some kind of 128 bit FP for almost 60 years, and we've had 128 IEEE FP for at least 30. This isn't new.
John Levine wrote:
It appears that Terje Mathisen <terje.mathisen@tmsw.no> said:
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah, much sooner.
Yeah, I knew that. :-)
What's been missing is general support for ieee754 fp128 across CPU architectures, so that portable code can assume it is there.
The more problematic part, but also somewhat easier to solve is 128-bit integers:
Using pairs of double does not extend the exponent range, but with pairs
of 64-bit registers we can support 128-bit integer ops in exactly the
same way we did 64-bit back in the 32-bit days:
ADD + ADC, SUB + SBB for add128 and sub128, 4 x MUL plus a few ADD/ADC
for mul128.
div128 ends up as a function call, the best way to implement that
depends on the hardware architecture and what it supports in the form of fast 64-bit DIV (like the latest Apple/ARM silicon), fast FF1,
reciprocal lookup and the relative speeds of them.
CMP needs a few extra ops, but easily within what a compiler will
happily inline.
Logic ops are easy of course, shifts need to handle shift amounts in the [64-127] range, typically with a MOV plus residual shift.
I guess what I'm saying is that int128_t isn't a problem, except when
you want to use them for array indexing!
Terje
BGB <cr88192@gmail.com> writes:
On 8/12/2026 12:57 AM, Thomas Koenig wrote:
HDD sizes:
Well, now one can potentially get a 12TB or so, but 4TB/6TB is more
typical for new "big" drives.
You are behind the times, seagate offers drives with more than
40TB.
When did 1TB drives start showing up? Around 2007 or so. So, 19 years,
for a reasonable maximum of around 3.5 bits or so...
Recently got ahold of some used 2TB drives, still good.
Date of manufacture: 2018.
So, 1 decade, HDD size doubled.
SSDs showed up, and are smaller. Still, a multi-TB SSD is pretty
expensive, and also are seeing neither rapid size gains nor price drops.
NVME has eclipsed (and at the high-end superceeded) SSD drives.
The largest NVMe drives store up to 512TB, and petabytes aren't
far away.
https://www.techradar.com/pro/the-worlds-largest-ssd-is-here-dapustor-unveils-a-massive-512tb-drive
Flash prices are currently inflated by the ML bubble, with most
production pre-sold for the next two years or more. Expect them
to go up until the bubble pops.
On the gripping hand, do we actually need to turn a lot of software to
be able to run in 128-bit address spaces? If my guess about the
slowing and maybe eventually stopping growth becomes reality, for most
programs 64-bit address space will be good enough forever, and we
don't need to convert them.
As a matter of fact 32bit is already enough "for ever" for many
programs. But in order to accommodate the other use cases, you may
still need new OS-level APIs (e.g. with 128bit file sizes) and you need
to update all the libraries that may be used by programs that need the
larger space, which in turn forces the other programs to be updated if
they also use those same libraries. So it tends to spread "everywhere".
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
On the gripping hand, do we actually need to turn a lot of software to
be able to run in 128-bit address spaces?-a If my guess about the
slowing and maybe eventually stopping growth becomes reality, for most
programs 64-bit address space will be good enough forever, and we
don't need to convert them.
As a matter of fact 32bit is already enough "for ever" for many
programs.-a But in order to accommodate the other use cases, you may
still need new OS-level APIs (e.g. with 128bit file sizes) and you need
to update all the libraries that may be used by programs that need the
larger space, which in turn forces the other programs to be updated if
they also use those same libraries.-a So it tends to spread "everywhere".
Yeah. Probably the majority of programs could run in a 32-bit VAS, but:
-a Typically only makes around a 15% difference in overall memory use;
-a Mostly only applies to smaller programs;
-a-a-a So, 15% off an already smaller process doesn't save much.
-a Not worth the added cost of dealing with both a 32 and 64-bit ABI.
As for files, video files and ISO's and similar can often exceed 4GB.
-a But, most other files are much smaller than this.
It is likely going to be a long time as well before anyone needs more
than 64 bits for a file offset. Well, for the subset of use-cases that
need files bigger than 4GB.
If one averages the files for all the files on a drive, wasn't seeing GB
or even MB...
IIRC, it was more in the area of 160K or so IIRC.
Then again, the predominant file formats also come up as ".c" and
similar, which may skew things.
I guess maybe it could make sense to run stats based on file extension.
Say, for example:
-a ".c" and ".h" and ".txt" and similar tending to skew smaller;
-a But ".mp4", ".avi", ".iso", etc tending to skew much larger.
Like, a comparably small number of video files can easily eat all the
space on an HDD; vs millions of C files...
Even a lot of other formats, like ".bmp", still tend to average in kB
range (when, in theory, they can be much larger).
Well, say, vs the 1-2MB JPEG's one gets from a phone camera (well, where phone camera likes giving images with a whole lot of pixels, but kinda
meh for colors, but this is kinda true with all of the cameras).
So, it seems likely that average-case file sizes are not likely to see a steady size-increase over time.
Well, even if the multi-MB ".c" or ".bmp" file may show up occasionally.
-a Well, or other formats, like ".xpm" or ".ppm" or so on.
I guess a TODO could be to stat average file sizes based on file type
and their % usage relative to total drive contents.
On 8/12/2026 8:59 PM, BGB wrote:
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
On the gripping hand, do we actually need to turn a lot of software to >>>> be able to run in 128-bit address spaces?-a If my guess about the
slowing and maybe eventually stopping growth becomes reality, for most >>>> programs 64-bit address space will be good enough forever, and we
don't need to convert them.
As a matter of fact 32bit is already enough "for ever" for many
programs.-a But in order to accommodate the other use cases, you may
still need new OS-level APIs (e.g. with 128bit file sizes) and you need
to update all the libraries that may be used by programs that need the
larger space, which in turn forces the other programs to be updated if
they also use those same libraries.-a So it tends to spread "everywhere". >>>
Yeah. Probably the majority of programs could run in a 32-bit VAS, but:
-a-a Typically only makes around a 15% difference in overall memory use;
-a-a Mostly only applies to smaller programs;
-a-a-a-a So, 15% off an already smaller process doesn't save much.
-a-a Not worth the added cost of dealing with both a 32 and 64-bit ABI.
As for files, video files and ISO's and similar can often exceed 4GB.
-a-a But, most other files are much smaller than this.
It is likely going to be a long time as well before anyone needs more
than 64 bits for a file offset. Well, for the subset of use-cases that
need files bigger than 4GB.
If one averages the files for all the files on a drive, wasn't seeing
GB or even MB...
IIRC, it was more in the area of 160K or so IIRC.
Then again, the predominant file formats also come up as ".c" and
similar, which may skew things.
I guess maybe it could make sense to run stats based on file extension.
Say, for example:
-a-a ".c" and ".h" and ".txt" and similar tending to skew smaller;
-a-a But ".mp4", ".avi", ".iso", etc tending to skew much larger.
Like, a comparably small number of video files can easily eat all the
space on an HDD; vs millions of C files...
Even a lot of other formats, like ".bmp", still tend to average in kB
range (when, in theory, they can be much larger).
Well, say, vs the 1-2MB JPEG's one gets from a phone camera (well,
where phone camera likes giving images with a whole lot of pixels, but
kinda meh for colors, but this is kinda true with all of the cameras).
So, it seems likely that average-case file sizes are not likely to see
a steady size-increase over time.
Well, even if the multi-MB ".c" or ".bmp" file may show up occasionally.
-a-a Well, or other formats, like ".xpm" or ".ppm" or so on.
I guess a TODO could be to stat average file sizes based on file type
and their % usage relative to total drive contents.
Your analysis is flawed as it is based on personal computer use.-a Think
of large databases used by industry or government.-a Some examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million.-a Besides basic identifying information (perhaps a hundred bytes), it has the earnings record for
every year that each of them worked, perhaps averaging several hundred
bytes each.-a So that is something like 150 GB for that one file.
Think of a large airline.-a It has information for every seat (several hundred) for every flight (perhaps several hundred per day), for a year.
And it has another file with information on each passenger.
Think of the detailed worldwide maps used by the government for
targeting cruise missiles.
There are lots of examples like this.
HDD sizes:
Well, now one can potentially get a 12TB or so, but 4TB/6TB is more
typical for new "big" drives.
When did 1TB drives start showing up? Around 2007 or so. So, 19 years,
for a reasonable maximum of around 3.5 bits or so...
Recently got ahold of some used 2TB drives, still good.
Date of manufacture: 2018.
So, 1 decade, HDD size doubled.
SSDs showed up, and are smaller. Still, a multi-TB SSD is pretty
expensive, and also are seeing neither rapid size gains nor price drops.
Speculation:
It is going to be a while...
Flash prices are currently inflated by the ML bubble, with most
production pre-sold for the next two years or more. Expect them
to go up until the bubble pops.
On 8/12/2026 8:59 PM, BGB wrote:<snip>
I guess a TODO could be to stat average file sizes based on file type
and their % usage relative to total drive contents.
Your analysis is flawed as it is based on personal computer use. Think
of large databases used by industry or government. Some examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic identifying >information (perhaps a hundred bytes), it has the earnings record for
every year that each of them worked, perhaps averaging several hundred
bytes each. So that is something like 150 GB for that one file.
Think of a large airline. It has information for every seat (several >hundred) for every flight (perhaps several hundred per day), for a year.
And it has another file with information on each passenger.
Think of the detailed worldwide maps used by the government for
targeting cruise missiles.
On 8/12/2026 5:00 PM, Scott Lurndal wrote:<snip>
If a 512TB SSD exists somewhere, I would imagine the price would be... >unreasonable...
https://www.techradar.com/pro/the-worlds-largest-ssd-is-here-dapustor-unveils-a-massive-512tb-drive
Flash prices are currently inflated by the ML bubble, with most
production pre-sold for the next two years or more. Expect them
to go up until the bubble pops.
Not sure what MOBO's would take that form factor, or what such a thing
would cost...
In any case, when 1TB HDD's appeared like 18/19 years ago, they were not >like some super-expensive / unobtanium type of thing...
Why would a database necessarily need to be a single giant file though,
as opposed to spreading it over a number of smaller files?...
That gives us a much better baseline, 40x (5.3 bits) in 19 years or
roughly a bit per 3.5 years (3.7 years if we use 36TB). Which based on
the above do suggest a slow-down since 2007 (but more intermediate
data points are needed to conclude anything).
But as others have mentioned a 512TB SSD has just been announced (by >DapuStor) and a good argument can be made that they should count since
it's really about storage, not specific methods.
Michael S <already5chosen@yahoo.com> writes:
On Wed, 12 Aug 2026 18:52:27 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
John Levine <johnl@taugh.com> writes:
It appears that Terje Mathisen <terje.mathisen@tmsw.no> said:<snip>
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah,
much sooner.
But anyway, we've had some kind of 128 bit FP for almost 60 years,
and we've had 128 IEEE FP for at least 30. This isn't new.
The Burroughs B3500 had 400-bit (100 digit) FP mantissas in 1966.
It turned out that customers (mainly financial) were happy with the
100 digit integer fixed point formats and the 408-bit FP format was
removed from the next generation (B4800) processors and replaced with
a single smaller (20 digit mantissa, 2 digit exponent) floating
point accumulator.
Either because customers were happy with 100 digit integer or
because they were unhappy witth speed of 100 digit FP.
Banks, insurance companies, corporate IT and later ATM network providers weren't interested in floating point
at all. Using fixed point integer was much easier to reconcile
with various bookkeeping standards and regulations.
Burroughs large systems (B6500 & successors) were the systems
more likely to be used for scientific applications requiring
floating point.
On 8/12/2026 8:59 PM, BGB wrote:-------------------------
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
Your analysis is flawed as it is based on personal computer use. Think
of large databases used by industry or government. Some examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic identifying information (perhaps a hundred bytes), it has the earnings record for
every year that each of them worked, perhaps averaging several hundred
bytes each. So that is something like 150 GB for that one file.
Think of a large airline. It has information for every seat (several hundred) for every flight (perhaps several hundred per day), for a year.
And it has another file with information on each passenger.
Think of the detailed worldwide maps used by the government for
targeting cruise missiles.
There are lots of examples like this.
scott@slp53.sl.home (Scott Lurndal) posted:
Michael S <already5chosen@yahoo.com> writes:
On Wed, 12 Aug 2026 18:52:27 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
John Levine <johnl@taugh.com> writes:
It appears that Terje Mathisen <terje.mathisen@tmsw.no> said:<snip>
128-bit integer and fp will happen much sooner!
IBM added 128 bit floating point to the 360/85 in 1967, so yeah,
much sooner.
But anyway, we've had some kind of 128 bit FP for almost 60 years,
and we've had 128 IEEE FP for at least 30. This isn't new.
The Burroughs B3500 had 400-bit (100 digit) FP mantissas in 1966.
It turned out that customers (mainly financial) were happy with the
100 digit integer fixed point formats and the 408-bit FP format was
removed from the next generation (B4800) processors and replaced with
a single smaller (20 digit mantissa, 2 digit exponent) floating
point accumulator.
Either because customers were happy with 100 digit integer or
because they were unhappy witth speed of 100 digit FP.
Banks, insurance companies, corporate IT and later ATM network providers
weren't interested in floating point
at all. Using fixed point integer was much easier to reconcile
with various bookkeeping standards and regulations.
And with the rounding required to match the states' regulations not
some IEEE standard rounding, fixed-point probably always will win.
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
On 8/12/2026 8:59 PM, BGB wrote:<snip>
I guess a TODO could be to stat average file sizes based on file type
and their % usage relative to total drive contents.
Your analysis is flawed as it is based on personal computer use. Think
of large databases used by industry or government. Some examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic identifying
information (perhaps a hundred bytes), it has the earnings record for
every year that each of them worked, perhaps averaging several hundred
bytes each. So that is something like 150 GB for that one file.
Which could just as easily be stored in 1000 files (one for each
of the leading 3-digits of the SSN).
Think of a large airline. It has information for every seat (several
hundred) for every flight (perhaps several hundred per day), for a year.
And it has another file with information on each passenger.
It's highly unlikely that all that information would be stored in a
single file, even on the Univac (now Unisys) TIP software that
many airlines are still using.
Think of the detailed worldwide maps used by the government for
targeting cruise missiles.
Again, there is no requirement that these be stored as a single
file.
And with the rounding required to match the states' regulations not
some IEEE standard rounding, fixed-point probably always will win.
The rounding rules vary for different calculations, for diffferent financial products,
in different countries.
Again, there is no requirement that these be stored as a single file.
Right.
The fact that the AS400 had a unified store with everthing memorymapped
does not mean that this is the only way to do it, or even the most >efficient.
BGB <cr88192@gmail.com> writes:
On 8/12/2026 5:00 PM, Scott Lurndal wrote:<snip>
If a 512TB SSD exists somewhere, I would imagine the price would be...
unreasonable...
https://www.techradar.com/pro/the-worlds-largest-ssd-is-here-dapustor-unveils-a-massive-512tb-drive
Flash prices are currently inflated by the ML bubble, with most
production pre-sold for the next two years or more. Expect them
to go up until the bubble pops.
Not sure what MOBO's would take that form factor, or what such a thing
would cost...
Pretty much every mainboard that isn't aimed at consumers.
The other innovation being used widely, at large scale,
in the big datacenters for storage is to re-use old DDR4
and DDR5 dimms from retired servers in PCI-Express CXL cards
(many of which offer in-line compression) to expand
DRAM. Generally used for KV storage.
In any case, when 1TB HDD's appeared like 18/19 years ago, they were not
like some super-expensive / unobtanium type of thing...
I beg to differ.
And with the rounding required to match the states' regulations not
some IEEE standard rounding, fixed-point probably always will win.
Torbjorn Lindgren <tl@none.invalid> writes:
That gives us a much better baseline, 40x (5.3 bits) in 19 years or
roughly a bit per 3.5 years (3.7 years if we use 36TB). Which based on
the above do suggest a slow-down since 2007 (but more intermediate
data points are needed to conclude anything).
As it happens, I have recently extended my data from <2025May26.091301@mips.complang.tuwien.ac.at>, and up to now we have:
size since
16TB 2019
18TB 2020
20TB 2021
22TB 2022
24TB 2023
26TB 2024
30TB 2025
32TB 2026-08-01
(Method: looking at the "gelistet seit" entries on <https://geizhals.eu/?cat=hde7s>).
Seagate claims they are delivering 44TB HDDs, but no HDD above 32TB
was for sale in various computer shops at the time when they made this
claim.
I expect a boost compare to the last years in the next few years
thanks to HAMR, but even Seagate does not expect a return to earlier
capacity growth rates: <https://pics.computerbase.de/1/2/0/3/5/3-d53d8a319080a28f/5-1080.eab585b2.png>.
But as others have mentioned a 512TB SSD has just been announced (by
DapuStor) and a good argument can be made that they should count since
it's really about storage, not specific methods.
I don't think that maximum capacity at any cost is a good way to
measure progress in SSDs.
For HDDs, it's different because they tend not to use more resources
(and thus higher cost) for more capacity, but for high-capacity SSDs
that's different.
But we could go with a similar approach of looking only at the SSDs on
offer and listed at <https://geizhals.at/?cat=hdssd&pagesize=30&sort=p&promode=false&allvalues=true>
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
Unfortunately, for 8TB drives, I only find some listed since 2018 and
2019, so the research method is not useful for researching more than a
few years in the past, as products get replaced.
Anyway, we can conclude that we saw a growth by 1 bit in 5 years,
which is faster than for HDDs, but much less than we were used to when
Moore was still in full swing.
- anton
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
Newegg, which despite its odd name is a well known mail order computer seller,
offers a 122TB SSD for $64,000.
https://www.newegg.com/p/N82E16820318206
Not having ordered one, I couldn't tell you how real it is.
Here's the vendor's page:
https://www.solidigm.com/products/technology/solidigm-path-to-122tb-ssd.html
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
Newegg, which despite its odd name is a well known mail order computer seller, >offers a 122TB SSD for $64,000.
https://www.newegg.com/p/N82E16820318206
Not having ordered one, I couldn't tell you how real it is.
John Levine <johnl@taugh.com> writes:
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
Newegg, which despite its odd name is a well known mail order computer seller,
offers a 122TB SSD for $64,000.
https://www.newegg.com/p/N82E16820318206
Not having ordered one, I couldn't tell you how real it is.
It says "out of stock" on that page.
But I expect that Solidigm has delivered such SSDs to some customers.
It's just that the trend in recent years to put more flash devices in
a package just reflects on market demand (especially before the flash
prices rose), not on technical advances in individual flash devices.
The 512TB announcement uses a new, larger form factor in order to fit
all the devices in one package, so it obviously does not reflect an
advance in flash density.
Note that Moore referred to "minimum component cost" in his law. For
things like DRAM and SSD (and HDDs, although the bits there are not
just due to semiconductor advances), with a site like
http://geizhals.eu, you can sort by lowest price per memory amount; at
the moment this shows a 2TB SSD at EUR81/TB, closely followed by two
4TB SSDs.
Unfortunately, one cannot easily find out what the corresponding price
was at earlier times, so one would have to do such queries regularly
and keep records for them, which I have not done.
Another problem with this method is that some items are sometimes
offered for a short time at substantially lower prices, possibly due
to clearance sales or somesuch, and that may lead to results that do
not reflect the general situation. In the present case, the 2TB SSD
is offered by one dealer at that low price, and by two others at more
than twice the price, the cheapest 4TB SSD is only offered by two
dealers, and only the second 4TB SSD is offered by many dealers (12),
with several (actually, in this case, all) at prices not too far from
the cheapest offer.
- anton
According to EricP <ThatWouldBeTelling@thevillage.com>:
And with the rounding required to match the states' regulations not
some IEEE standard rounding, fixed-point probably always will win.
The rounding rules vary for different calculations, for diffferent financial products,
in different countries.
DFP is a plausible alternative, since its rounding rules are different. Rather than
normalizing results, opoerations preserve the "quantum", the magnitude of the least
significant digit, if possible. Each arithmetic operation can specify the rounding
to use, and there are other operations to manage operand scales.
I think the main advantage over fixed point is that you can do the rounding in each
operation rather than having to fix it up after each possibly inexact op.
According to Terje Mathisen <terje.mathisen@tmsw.no>:
Again, there is no requirement that these be stored as a single file.
Right.
The fact that the AS400 had a unified store with everthing memorymapped >does not mean that this is the only way to do it, or even the most >efficient.
Sure, but it enables a programming model that a lot of people seem to like, considering the success and longevity of S/38->AS/400->something i something.
There's been more than one time that I built a database with all of the
files and tables set up for efficient implementation of the kind of work
I anticipated, then found that it was spending a lot of time doing other stuff.
Single address space can push those issues down into the implementation.
John Levine <johnl@taugh.com> posted:
According to Terje Mathisen <terje.mathisen@tmsw.no>:
Again, there is no requirement that these be stored as a single
file.
Right.
The fact that the AS400 had a unified store with everthing
memorymapped does not mean that this is the only way to do it, or
even the most efficient.
Sure, but it enables a programming model that a lot of people seem
to like, considering the success and longevity of
S/38->AS/400->something i something.
S/38->S400 has had a long life. However it was supposed to take over
from 360->series Z--which it has not.
There's been more than one time that I built a database with all of
the files and tables set up for efficient implementation of the
kind of work I anticipated, then found that it was spending a lot
of time doing other stuff.
Single address space can push those issues down into the
implementation.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
Newegg, which despite its odd name is a well known mail order computer seller, >offers a 122TB SSD for $64,000.
https://www.newegg.com/p/N82E16820318206
Not having ordered one, I couldn't tell you how real it is.
On Fri, 14 Aug 2026 14:24:11 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
S/38->S400 has had a long life. However it was supposed to take over
from 360->series Z--which it has not.
Supposed by whom?
Certainly not by IBM officials.
John Levine <johnl@taugh.com> writes:
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
Newegg, which despite its odd name is a well known mail order computer seller,
offers a 122TB SSD for $64,000.
https://www.newegg.com/p/N82E16820318206
Not having ordered one, I couldn't tell you how real it is.
That would be the $64,000 dollar question, no?
The fact that the AS400 had a unified store with everthing memorymapped
does not mean that this is the only way to do it, or even the most
efficient.
Sure, but it enables a programming model that a lot of people seem to like, >> considering the success and longevity of S/38->AS/400->something i something.
S/38->S400 has had a long life. However it was supposed to take over
from 360->series Z--which it has not.
John Levine <johnl@taugh.com> posted:
According to EricP <ThatWouldBeTelling@thevillage.com>:
And with the rounding required to match the states' regulations not
some IEEE standard rounding, fixed-point probably always will win.
The rounding rules vary for different calculations, for diffferent financial products,
in different countries.
DFP is a plausible alternative, since its rounding rules are different. Rather than
normalizing results, opoerations preserve the "quantum", the magnitude of the least
significant digit, if possible. Each arithmetic operation can specify the rounding
to use, and there are other operations to manage operand scales.
How does DFP obey a state rule whereby every monetary calculation resulting in >a value over $0.0045 is rounded up +0.01 ??
John Levine <johnl@taugh.com> writes:
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
Newegg, which despite its odd name is a well known mail order computer seller,
offers a 122TB SSD for $64,000.
https://www.newegg.com/p/N82E16820318206
Not having ordered one, I couldn't tell you how real it is.
It says "out of stock" on that page.
The 512TB announcement uses a new, larger form factor in order to fit
all the devices in one package, so it obviously does not reflect an
advance in flash density.
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
John Levine <johnl@taugh.com> writes:
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219 >>>>and EUR 26009). The first of these was listed in 2023. So we get:
2018 15.36TB
2023 30.72TB
Newegg, which despite its odd name is a well known mail order computer seller,
offers a 122TB SSD for $64,000.
https://www.newegg.com/p/N82E16820318206
Not having ordered one, I couldn't tell you how real it is.
It says "out of stock" on that page.
I see "Request a Quote" which presumably means they don't stock it and
would have to order it from Solidgm. Other places show it with 32
week leadtimes. I presume they've sold them all to bulk customers
like Coreweave.
The 512TB announcement uses a new, larger form factor in order to fit
all the devices in one package, so it obviously does not reflect an
advance in flash density.
True, but it's impressive they managed to squeeze 122TB into an NVME >package. It uses QLC NAND, four bits per cell, which means fast reads
but slow writes. That's apparently OK for AI training.
According to MitchAlsup <user5857@newsgrouper.org.invalid>:
John Levine <johnl@taugh.com> posted:
According to EricP <ThatWouldBeTelling@thevillage.com>:
And with the rounding required to match the states' regulations not
some IEEE standard rounding, fixed-point probably always will win.
The rounding rules vary for different calculations, for diffferent financial products,
in different countries.
DFP is a plausible alternative, since its rounding rules are different. Rather than
normalizing results, opoerations preserve the "quantum", the magnitude of the least
significant digit, if possible. Each arithmetic operation can specify the rounding
to use, and there are other operations to manage operand scales.
How does DFP obey a state rule whereby every monetary calculation resulting in
a value over $0.0045 is rounded up +0.01 ??
With explicit code. It has all of the normal rounding modes, but if you have an abnormal one
you need to do it yourself. That would be a pretty easy one, a compare, a test and a round
instruction.
According to MitchAlsup <user5857@newsgrouper.org.invalid>:
The fact that the AS400 had a unified store with everthing memorymapped >>> >does not mean that this is the only way to do it, or even the most
efficient.
Sure, but it enables a programming model that a lot of people seem to like, >>> considering the success and longevity of S/38->AS/400->something i something.
S/38->S400 has had a long life. However it was supposed to take over
from 360->series Z--which it has not.
As far as I can tell FS was an exercise in hubris. IBM had just lived through the
painful conversion from their 70xx and 1400 machines to the 360, and still had a
lot of customers running old code in emulation on 360/370. It was absurd to imagine that the customers would do that again when the 370 was stiil viable with 31 bit addressing and not close to running out of address bits.
They certainly learned that lesson since z has a mode that runs 24 bit code from the 1960s and 70s.
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
Currently that shows SSDs up to 30.72TB (at prices between EUR 14219
and EUR 26009). The first of these was listed in 2023. So we get:
Yeah, I think the slowdown is most dramatic in the desktop/laptop
consumer market, where since Dennard scaling stopped (~2006) I think
this market has almost stopped growing in terms of RAM/storage/CPU
capacity. Instead it has slowly joined up with the smartphone band,
both because smartphones have substantially increased their performance
and because laptops&desktops have slowly shrunk and reduced their
power consumption.
=== Stefan
How does DFP obey a state rule whereby every monetary calculation resulting in
a value over $0.0045 is rounded up +0.01 ??
With explicit code. It has all of the normal rounding modes, but if you have an abnormal one
you need to do it yourself. That would be a pretty easy one, a compare, a test and a round
instruction.
So,
sum = sum + item.price;
compiles into:
LDD Rip,[Rd,#item.price]
FADD Rt,Rsum,Rip
TRNK Rs,Rt,#cents // so we have something to compare
FSUB Rs,Rt,Rs
FCMP Rs,Rs,#0.0045 // check state rounding value
PGE Rs,T
FADD Rt,Rt,#0.01
Looks kind of horrible compared to: Set RND.Point = 0.0045 outside
of loop:
LDD Rip,[Rd,#item.price]
FADD Rt,Rsum,Rip
don't you think ???
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/12/2026 8:59 PM, BGB wrote:-------------------------
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
Your analysis is flawed as it is based on personal computer use. Think
of large databases used by industry or government. Some examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic identifying
information (perhaps a hundred bytes), it has the earnings record for
every year that each of them worked, perhaps averaging several hundred
bytes each. So that is something like 150 GB for that one file.
it is 300M files not 1, and one indexing directory.
And, yes, the total size is TB+ level, but each individual has his/her
own file.
Yeah, I think the slowdown is most dramatic in the desktop/laptop
consumer market, where since Dennard scaling stopped (~2006) I think
this market has almost stopped growing in terms of RAM/storage/CPU
capacity.
Instead it has slowly joined up with the smartphone band,
both because smartphones have substantially increased their performance
and because laptops&desktops have slowly shrunk and reduced their
power consumption.
It very much depends on the usage. Gamers tend to buy more
power-hungry graphics cards and processors with each generation, and consequently, the power supply capacities have gone up, too.
On 8/13/2026 10:45 AM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/12/2026 8:59 PM, BGB wrote:-------------------------
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
Your analysis is flawed as it is based on personal computer use. Think
of large databases used by industry or government. Some examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic identifying
information (perhaps a hundred bytes), it has the earnings record for
every year that each of them worked, perhaps averaging several hundred
bytes each. So that is something like 150 GB for that one file.
it is 300M files not 1, and one indexing directory.
And, yes, the total size is TB+ level, but each individual has his/her
own file.
Disclaimer. I used to work for the Social Security Administration, but
that was a long time ago, and I am sure things have changed a lot since then, but it certainly didn't use to be like that.
I am not saying you are wrong, but do you have a reference to that, or personal knowledge? ISTM that is a very odd way of doing it. You are spending a lot of storage on the directory information, etc. for 300M
files, and I don't see the advantage of that versus something like a database management system or even one or a small number of simple
direct access files.
BTW, just the concept of 300M files on a single system boggles my mind.
From my, admittedly limited, experience, most systems have a few
thousand or a few tens of thousand files at most. With 300M files, how
many I/Os to directories does it take to get to the file?
Michael S <already5chosen@yahoo.com> writes:
On Fri, 14 Aug 2026 14:24:11 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
S/38->S400 has had a long life. However it was supposed to take over
from 360->series Z--which it has not.
Supposed by whom?
Certainly not by IBM officials.
If you go back far enough, <https://en.wikipedia.org/wiki/IBM_Future_Systems_project> says:
|The new systems were intended to replace the System/370 in the market
|some time in the late 1970s.
...
|The single-level store was implemented in the System/38 in 1978 and
|moved to other systems in the lineup after that
In particular, the S/38 was succeeded by the much more successful
AS/400, also with a single-level store.
I heard (from Heinz Zemanek) and recently also read somewhere that IBM expected to be broken up due to anti-trust action, and that they had
several architectures in preparation for this, and that AS/400 is an
outcome of this. However, reading <https://cs.stanford.edu/people/eroberts/cs181/projects/corporate-monopolies/government_ibm.html>,
the danger seems to have been over by the time AS/400 was introduced
(the case was dropped in 1982, AS/400 was introduced in 1988), but
S/38 could have been a result of that. If that is the case, S/38
definitely was not intended to replace S/370 (and the fact that S/38 addressed a lower-cost market also speaks against such an intention),
even if Future Systems originally was.
On 8/13/2026 10:45 AM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/12/2026 8:59 PM, BGB wrote:-------------------------
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
Your analysis is flawed as it is based on personal computer use.
Think of large databases used by industry or government. Some
examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic
identifying information (perhaps a hundred bytes), it has the
earnings record for every year that each of them worked, perhaps
averaging several hundred bytes each. So that is something like
150 GB for that one file.
it is 300M files not 1, and one indexing directory.
And, yes, the total size is TB+ level, but each individual has
his/her own file.
Disclaimer. I used to work for the Social Security Administration,
but that was a long time ago, and I am sure things have changed a lot
since then, but it certainly didn't use to be like that.
I am not saying you are wrong, but do you have a reference to that,
or personal knowledge? ISTM that is a very odd way of doing it. You
are spending a lot of storage on the directory information, etc. for
300M files, and I don't see the advantage of that versus something
like a database management system or even one or a small number of
simple direct access files.
BTW, just the concept of 300M files on a single system boggles my
mind. From my, admittedly limited, experience, most systems have a
few thousand or a few tens of thousand files at most. With 300M
files, how many I/Os to directories does it take to get to the file?
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
It very much depends on the usage. Gamers tend to buy more
power-hungry graphics cards and processors with each generation, and consequently, the power supply capacities have gone up, too.
As they say... with huge power comes a huge electricity bill.
On Fri, 14 Aug 2026 16:20:49 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Fri, 14 Aug 2026 14:24:11 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
S/38->S400 has had a long life. However it was supposed to take
over from 360->series Z--which it has not.
Supposed by whom?
Certainly not by IBM officials.
If you go back far enough, <https://en.wikipedia.org/wiki/IBM_Future_Systems_project> says:
|The new systems were intended to replace the System/370 in the
market |some time in the late 1970s.
...
|The single-level store was implemented in the System/38 in 1978 and
|moved to other systems in the lineup after that
In particular, the S/38 was succeeded by the much more successful
AS/400, also with a single-level store.
I heard (from Heinz Zemanek) and recently also read somewhere thatFFI check afc and any post by Lynn Wheeler.
IBM expected to be broken up due to anti-trust action, and that
they had several architectures in preparation for this, and that
AS/400 is an outcome of this. However, reading <https://cs.stanford.edu/people/eroberts/cs181/projects/corporate-monopolies/government_ibm.html>,
the danger seems to have been over by the time AS/400 was introduced
(the case was dropped in 1982, AS/400 was introduced in 1988), but
S/38 could have been a result of that. If that is the case, S/38 definitely was not intended to replace S/370 (and the fact that S/38 addressed a lower-cost market also speaks against such an
intention), even if Future Systems originally was.
Stefan Monnier <monnier@iro.umontreal.ca> writes:
Yeah, I think the slowdown is most dramatic in the desktop/laptop
consumer market, where since Dennard scaling stopped (~2006) I think
this market has almost stopped growing in terms of RAM/storage/CPU
capacity.
There is no connection, and also, the growth patterns are different.
Clock rate (Dennard) scaling actually slowed down somewhat earlier;
already my step from a 1200MHz K7 in 2000 to a 2000MHz K8 in 2003 was
a slowdown compared to the advances of the 1990s (from 133MHz (for me)
in 1995 to 1200MHz in 2000).
Concerning RAM, the PC (both consumer and company-use) desktop
mainstream has had between 1 DIMM and 2 DIMMs, with 8 or 16 RAM
devices each for about 2 decades, so the RAM growth directly reflects
the growth of the RAM devices, i.e., the advance in semiconductor
density. For me it was
RAM CPU clock cores
2003 1 GB 2000MHz 1
2008 4 GB 3000MHz 2
2015 16 GB 4200MHz (Turbo) 4
2024 64 GB 5100MHz (Turbo) 8
I just checked the first and the last of these, and they both have 2
DIMMs with 16 devices each. We might interpret a slowdown into the increasing time distances between these steps, but the step size is
probably too coarse-grained to draw such conclusions. In any case, we
see that while RAM has grown by a factor of 64, CPU clock rate has
grown by a factor of 2.5. Cores have grown at the square root of RAM,
with each core taking many more transistors in recent CPUs than in
2003.
Concerning persistent storage, somehow I have not run into the limits
of the HDD and SSD sizes for a while. This is different for people
who collect films and games. Anyway, the advances in sizes led to me replacing the HDDs with 250GB+500GB SSDs in 2015 (originally, I
planned to use 250GB plus the existing HDDs, but the HDDs were so loud
in the new setup that I replaced them with a 500GB SSD). And I
replaced both with a 1TB SSD in 2024. From that we can see that the
SSDs have had a significant growth in those years. For HDDs, there
are good numnbers elsewhere in this discussion, but the slowdown only
seems to have happened in the 2010s.
Instead it has slowly joined up with the smartphone band,
both because smartphones have substantially increased their performance
and because laptops&desktops have slowly shrunk and reduced their
power consumption.
It very much depends on the usage. Gamers tend to buy more
power-hungry graphics cards and processors with each generation, and consequently, the power supply capacities have gone up, too.
- anton
On Sat, 15 Aug 2026 20:32:54 +0100
"Kerr-Mudd, John" <admin@127.0.0.1> wrote:
On Fri, 14 Aug 2026 16:20:49 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
Michael S <already5chosen@yahoo.com> writes:FFI check afc and any post by Lynn Wheeler.
On Fri, 14 Aug 2026 14:24:11 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
S/38->S400 has had a long life. However it was supposed to take
over from 360->series Z--which it has not.
Supposed by whom?
Certainly not by IBM officials.
If you go back far enough,
<https://en.wikipedia.org/wiki/IBM_Future_Systems_project> says:
|The new systems were intended to replace the System/370 in the
market |some time in the late 1970s.
...
|The single-level store was implemented in the System/38 in 1978 and
|moved to other systems in the lineup after that
In particular, the S/38 was succeeded by the much more successful
AS/400, also with a single-level store.
I heard (from Heinz Zemanek) and recently also read somewhere that
IBM expected to be broken up due to anti-trust action, and that
they had several architectures in preparation for this, and that
AS/400 is an outcome of this. However, reading
<https://cs.stanford.edu/people/eroberts/cs181/projects/corporate-monopolies/government_ibm.html>,
the danger seems to have been over by the time AS/400 was introduced
(the case was dropped in 1982, AS/400 was introduced in 1988), but
S/38 could have been a result of that. If that is the case, S/38
definitely was not intended to replace S/370 (and the fact that S/38
addressed a lower-cost market also speaks against such an
intention), even if Future Systems originally was.
I have troubles comprehanding many posts of Lynn Wheeler
On Fri, 14 Aug 2026 21:52:05 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 8/13/2026 10:45 AM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/12/2026 8:59 PM, BGB wrote:-------------------------
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
Your analysis is flawed as it is based on personal computer use.
Think of large databases used by industry or government. Some
examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic
identifying information (perhaps a hundred bytes), it has the
earnings record for every year that each of them worked, perhaps
averaging several hundred bytes each. So that is something like
150 GB for that one file.
it is 300M files not 1, and one indexing directory.
And, yes, the total size is TB+ level, but each individual has
his/her own file.
Disclaimer. I used to work for the Social Security Administration,
but that was a long time ago, and I am sure things have changed a lot
since then, but it certainly didn't use to be like that.
I am not saying you are wrong, but do you have a reference to that,
or personal knowledge? ISTM that is a very odd way of doing it. You
are spending a lot of storage on the directory information, etc. for
300M files, and I don't see the advantage of that versus something
like a database management system or even one or a small number of
simple direct access files.
BTW, just the concept of 300M files on a single system boggles my
mind. From my, admittedly limited, experience, most systems have a
few thousand or a few tens of thousand files at most. With 300M
files, how many I/Os to directories does it take to get to the file?
Old small (250GB) SSD on my old home PC contains ~925,000 files.
I wuld think that nowadays it's atypically small amount.
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/13/2026 10:45 AM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/12/2026 8:59 PM, BGB wrote:-------------------------
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
Your analysis is flawed as it is based on personal computer use. Think >>>> of large databases used by industry or government. Some examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic identifying
information (perhaps a hundred bytes), it has the earnings record for
every year that each of them worked, perhaps averaging several hundred >>>> bytes each. So that is something like 150 GB for that one file.
it is 300M files not 1, and one indexing directory.
And, yes, the total size is TB+ level, but each individual has his/her
own file.
Disclaimer. I used to work for the Social Security Administration, but
that was a long time ago, and I am sure things have changed a lot since
then, but it certainly didn't use to be like that.
I am not saying you are wrong, but do you have a reference to that, or
personal knowledge? ISTM that is a very odd way of doing it. You are
spending a lot of storage on the directory information, etc. for 300M
files, and I don't see the advantage of that versus something like a
database management system or even one or a small number of simple
direct access files.
Take a very rich person's tax "file"; D J Trump filed tax returns of
1,4xx pages of information and calculations, while joe schmoe files
2 pages. I don't see how to make both fit in a single sized entry
in a single file. In addition there is at least another pages of
information linking this entry to previous entries, addresses,
companies worked for, and other perinate history.
But it seems to me that *.gov would want at least 1 file per person
living and recently dead (last 50 years) actively available at a few
key strokes of effort. Tying together income, tax, police, civil, and
other personal information.
I am not saying you are wrong, but do you have a reference to that, or
personal knowledge? ISTM that is a very odd way of doing it. You are
spending a lot of storage on the directory information, etc. for 300M
files, and I don't see the advantage of that versus something like a
database management system or even one or a small number of simple
direct access files.
Take a very rich person's tax "file"; D J Trump filed tax returns of
1,4xx pages of information and calculations, while joe schmoe files
2 pages. I don't see how to make both fit in a single sized entry
in a single file. In addition there is at least another pages of
information linking this entry to previous entries, addresses,
companies worked for, and other perinate history.
Take a very rich person's tax "file"; D J Trump filed tax returns ofThe US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic identifying [...]
1,4xx pages of information and calculations, while joe schmoe files
2 pages. I don't see how to make both fit in a single sized entry
in a single file. In addition there is at least another pages of
information linking this entry to previous entries, addresses,
companies worked for, and other perinate history.
But it seems to me that *.gov would want at least 1 file per person
living and recently dead (last 50 years) actively available at a few
key strokes of effort. Tying together income, tax, police, civil, and
other personal information.
Concerning RAM, the PC (both consumer and company-use) desktop
mainstream has had between 1 DIMM and 2 DIMMs, with 8 or 16 RAM
devices each for about 2 decades, so the RAM growth directly reflects
the growth of the RAM devices, i.e., the advance in semiconductor
density. For me it was
RAM CPU clock cores
2003 1 GB 2000MHz 1
2008 4 GB 3000MHz 2
2015 16 GB 4200MHz (Turbo) 4
2024 64 GB 5100MHz (Turbo) 8
I was thinking of more "consumer" devices, where AFAIK laptops would
have had typically ~256MB in 2003 and ~16GB in 2026, but yes 64x sounds
about right. That's 6bits in 23 years, so about 4years per bit.
[ It is striking tho that it was common for laptops to support a max of
8GB of RAM in 2007/2008, and we still have laptops coming out in 2026
with 8GB of RAM (and not even upgradable). ]
On Fri, 14 Aug 2026 21:52:05 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 8/13/2026 10:45 AM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/12/2026 8:59 PM, BGB wrote:-------------------------
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
Your analysis is flawed as it is based on personal computer use.
Think of large databases used by industry or government. Some
examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic
identifying information (perhaps a hundred bytes), it has the
earnings record for every year that each of them worked, perhaps
averaging several hundred bytes each. So that is something like
150 GB for that one file.
it is 300M files not 1, and one indexing directory.
And, yes, the total size is TB+ level, but each individual has
his/her own file.
Disclaimer. I used to work for the Social Security Administration,
but that was a long time ago, and I am sure things have changed a lot
since then, but it certainly didn't use to be like that.
I am not saying you are wrong, but do you have a reference to that,
or personal knowledge? ISTM that is a very odd way of doing it. You
are spending a lot of storage on the directory information, etc. for
300M files, and I don't see the advantage of that versus something
like a database management system or even one or a small number of
simple direct access files.
BTW, just the concept of 300M files on a single system boggles my
mind. From my, admittedly limited, experience, most systems have a
few thousand or a few tens of thousand files at most. With 300M
files, how many I/Os to directories does it take to get to the file?
Old small (250GB) SSD on my old home PC contains ~925,000 files.
I wuld think that nowadays it's atypically small amount.
few thousand or a few tens of thousand files at most. With 300M
files, how many I/Os to directories does it take to get to the file?
On 8/15/2026 1:12 PM, Michael S wrote:
FFI check afc and any post by Lynn Wheeler.
I have troubles comprehanding many posts of Lynn Wheeler
Iirc, her has a nice database.
Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
Concerning RAM, the PC (both consumer and company-use) desktop
mainstream has had between 1 DIMM and 2 DIMMs, with 8 or 16 RAM
devices each for about 2 decades, so the RAM growth directly reflects
the growth of the RAM devices, i.e., the advance in semiconductor
density. For me it was
RAM CPU clock cores
2003 1 GB 2000MHz 1
2008 4 GB 3000MHz 2
2015 16 GB 4200MHz (Turbo) 4
2024 64 GB 5100MHz (Turbo) 8
I was thinking of more "consumer" devices, where AFAIK laptops would
have had typically ~256MB in 2003 and ~16GB in 2026, but yes 64x sounds
about right. That's 6bits in 23 years, so about 4years per bit.
[ It is striking tho that it was common for laptops to support a max of
8GB of RAM in 2007/2008, and we still have laptops coming out in 2026
with 8GB of RAM (and not even upgradable). ]
... but certainly unusable under Windows 11. Although Microsoft
wants to get rid of some bloat to make it usable with 8GB again,
I'm not holding my breath, and am hoping to at least get 16 GB
in all of my business laptops.
(So maybe you can have 8GB on "stock" Windows 11. Add Outlook
Teams, Word, Edge, the usual security software, ...)
Michael S <already5chosen@yahoo.com> writes:
On Fri, 14 Aug 2026 21:52:05 -0700
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
On 8/13/2026 10:45 AM, MitchAlsup wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 8/12/2026 8:59 PM, BGB wrote:-------------------------
On 8/12/2026 9:48 AM, Stefan Monnier wrote:
Your analysis is flawed as it is based on personal computer use.
Think of large databases used by industry or government. Some
examples:
The US Social Security Administration has a file with a record for
basically every American, say 300 Million. Besides basic
identifying information (perhaps a hundred bytes), it has the
earnings record for every year that each of them worked, perhaps
averaging several hundred bytes each. So that is something like
150 GB for that one file.
it is 300M files not 1, and one indexing directory.
And, yes, the total size is TB+ level, but each individual has
his/her own file.
Disclaimer. I used to work for the Social Security Administration,
but that was a long time ago, and I am sure things have changed a lot
since then, but it certainly didn't use to be like that.
I am not saying you are wrong, but do you have a reference to that,
or personal knowledge? ISTM that is a very odd way of doing it. You
are spending a lot of storage on the directory information, etc. for
300M files, and I don't see the advantage of that versus something
like a database management system or even one or a small number of
simple direct access files.
BTW, just the concept of 300M files on a single system boggles my
mind. From my, admittedly limited, experience, most systems have a
few thousand or a few tens of thousand files at most. With 300M
files, how many I/Os to directories does it take to get to the file?
Old small (250GB) SSD on my old home PC contains ~925,000 files.
I wuld think that nowadays it's atypically small amount.
$ locate \* | wc -l
4,814,444
few thousand or a few tens of thousand files at most. With 300M
files, how many I/Os to directories does it take to get to the file?
On unix/unix-like systems, the filesystem is a tree structure,
so absent any OS directory caching, the number of directory I/O's is
a function of the depth. Not many, in other words.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 8/15/2026 1:12 PM, Michael S wrote:
FFI check afc and any post by Lynn Wheeler.
I have troubles comprehanding many posts of Lynn Wheeler
Iirc, her has a nice database.
Lynn, in this case, is male.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 45:26:57 |
| Calls: | 1,100 |
| Files: | 1,339 |
| Messages: | 275,372 |
