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> <86y12uy8ku.fsf@linuxsc.com> <86zfmwvs5w.fsf@linuxsc.com> <86sesmvqu1.fsf@linuxsc.com> <58fcd0a722acd8a6e2426596e006d86c@www.novabbs.org> <11a33395baec9abee86a556c799f5318@www.novabbs.org> 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 schrieb: >> Thomas Koenig wrote: >>> EricP schrieb: >>>> Thomas Koenig wrote: >>>>> MitchAlsup1 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.