Deutsch   English   Français   Italiano  
<2498f2668ce4a728dbae17d5bf5e8d80@www.novabbs.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Retirement hobby (was Re: 80286 protected mode)
Date: Tue, 29 Oct 2024 20:21:11 +0000
Organization: Rocksolid Light
Message-ID: <2498f2668ce4a728dbae17d5bf5e8d80@www.novabbs.org>
References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <ve6oiq$2pag3$1@dont-email.me> <ve6tv7$2q6d5$1@dont-email.me> <86y12uy8ku.fsf@linuxsc.com> <jwv34kx5afd.fsf-monnier+comp.arch@gnu.org> <venpin$241bk$2@dont-email.me> <veu2uv$3cluq$1@dont-email.me> <veudt1$3ep62$1@dont-email.me> <vf3qgi$ijah$1@dont-email.me> <vf4u1t$qo5f$2@dont-email.me> <vf4ve7$rtqt$1@dont-email.me> <86zfmwvs5w.fsf@linuxsc.com> <vf7gk0$1ce7n$1@dont-email.me> <86sesmvqu1.fsf@linuxsc.com> <f76d30e07a848362c2ce912ee8d62479@www.novabbs.org> <vfbhpv$26trl$2@dont-email.me> <58fcd0a722acd8a6e2426596e006d86c@www.novabbs.org> <vfcmj9$2h0pg$1@dont-email.me> <11a33395baec9abee86a556c799f5318@www.novabbs.org> <vfoe7m$12m27$1@dont-email.me> <fyRTO.738628$_o_3.579395@fx17.iad> <vfpvke$1f0j6$1@dont-email.me> <vfq1k6$1fabu$1@dont-email.me> <vfren5$1mnvr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="50311"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$eECn7gO5lSncY1XWOGplqe1c1FL/zV0ny.WG/jPvppFDy.RGT9wCm
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5030
Lines: 73

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.