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

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.
If I was implementing this I would probably want some redundant storage to limit carry propagation, so maybe 48 bits per 64-bit chunk, in which case I would need about 2800 bits or 6 of those 512-bit SIMD regs.

SIMD from hell?  Pretend that a CPU is a graphics card? :-)

Writing this as a throughput task could make it fit better within a GPU?
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"