Re: Retirement hobby (was Re: 80286 protected mode)

On Tue, 29 Oct 2024 19:57:25 +0000, Thomas Koenig wrote:

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:

Thomas Koenig wrote:

EricP <ThatWouldBeTelling@thevillage.com> schrieb:

Thomas Koenig wrote:

MitchAlsup1 <mitchalsup@aol.com> schrieb:
>

In posits, a quire is an accumulator with as many binary digits
as to cover max-exponent to min-exponent; so one can accumulate
an essentially unbounded number of sums without loss of precision
--to obtain a sum with a single rounding.

>
Not restricted to posits, I believe (but the term may differ).
>
At university, I had my programming
courses on a Pascal compiler which implemented
https://en.wikipedia.org/wiki/Karlsruhe_Accurate_Arithmetic ,
a hardware implementation was on the 4361 as an option
https://en.wikipedia.org/wiki/IBM_4300#High-Accuracy_Arithmetic_Facility

>
These would be very large registers. You'd need some way to store and
load
the these for register spills, fills and task switch, as well as move
and manage them.
>
Karlsruhe above has a link to
http://www.bitsavers.org/pdf/ibm/370/princOps/SA22-7093-0_High_Accuracy_Arithmetic_Jan84.pdf
>
which describes their large accumulators as residing in memory, which
avoids the spill/fill/switch issue but with an obvious performance hit:
>
"A floating-point accumulator occupies a 168-byte storage area that is
aligned on a 256-byte boundary. An accumulator consists of a four-byte
status area on the left, followed by a 164-byte numeric area."
>
The operands are specified by virtual address of their in-memory
accumulator.

>
Makes sense, given the time this was implemented.  This was also a
mid-range machine, not a number cruncher.  I do not find the
number of cycles that the instructions took.

>
At the time, memory was just a few clock cycles away from the CPU, so
not really that problematic. Today, such a super-accumulator would stay
in $L1 most of the time, or at least the central, in-use cache line of
it, would do so.
>

>
But this was also for hex floating point.  A similar scheme for IEEE
double would need a bit more than 2048 bits, so five AVX-512 registers.

>
With 1312 bits of storage, their fp inputs (hex fp?) must have had a
smaller exponent range than ieee double.

Terje--IEEE is all capitals.

IBM format had one sign bit, seven exponent bits and six or fourteen
hexadecimal digits for single and double precision, respectively.

The span of an IEEE double "quire" would be the exponent-2 + fraction.
a) The most significant non-infinity has an exponent of +1023
b) The least significant non-underflow has an exponent of -1023
Leaving a span of 2046 bits plus 52 denormalized bits or 2098-bits
or 262 bytes.
One note: When left in memory, one indexes the accumulator with
the (exponent>>6) and fetches 2 doublewords. A carry out requires
accessing the 3rd doubleword (possibly transitively).

(Insert fear and loathing for hex float here).

Heck, watching Kahan's notes on FP problems leaves one in fear of
binary floating point representations.