Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Thomas Koenig Newsgroups: comp.arch Subject: Re: Retirement hobby (was Re: 80286 protected mode) Date: Tue, 29 Oct 2024 19:57:25 -0000 (UTC) Organization: A noiseless patient Spider Lines: 54 Message-ID: References: <2024Oct6.150415@mips.complang.tuwien.ac.at> <7c8e5c75ce0f1e7c95ec3ae4bdbc9249@www.novabbs.org> <2024Oct8.092821@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> Injection-Date: Tue, 29 Oct 2024 20:57:25 +0100 (CET) Injection-Info: dont-email.me; posting-host="ce01d9f855c34171a802bcc652f731c2"; logging-data="1794043"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19vZSL14MQviUaDDfPplG+cn9pbpnNhjK8=" User-Agent: slrn/1.0.3 (Linux) Cancel-Lock: sha1:TM4epKp61Ybg1CASSWGtziz+OpQ= Bytes: 4353 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. IBM format had one sign bit, seven exponent bits and six or fourteen hexadecimal digits for single and double precision, respectively. (Insert fear and loathing for hex float here).