Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Making Lemonade (Floating-point format changes)
Date: Wed, 15 May 2024 12:07:13 +0300
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <20240515120713.00001904@yahoo.com>
References: <abe04jhkngt2uun1e7ict8vmf1fq8p7rnm@4ax.com>
	<v1qga3$2odn2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 15 May 2024 11:07:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a04c505c0ffc85f287570d2b16f50c6f";
	logging-data="820301"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/V3kVaxzoBdy/ij7mt7dkr6hWBgtjDdZQ="
Cancel-Lock: sha1:FZesio0jGZ5J5Rzwg345kxPw7B4=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3054

On Sun, 12 May 2024 15:30:40 +0200
wolfgang kern <nowhere@never.at> wrote:

> On 12/05/2024 05:44, John Savard wrote:
> > I've made another long-overdue change in the Concertina II
> > architecture on the page about 17-bit instructions.
> > 
> > Since I describe the individual instructions there, with their
> > opcodes and what they do, I've illustrated the floating-point
> > formats of the architecture on that page.
> > 
> > The good people in charge of the IEEE 754 standard had seen fit to
> > define a standard 128-bit floating-point format which included a
> > hidden first bit.
> > 
> > This annoyed me greatly, because I was going to take the 8087's
> > temporary real format, and extend the mantissa for my 128-bit
> > format.
> > 
> > I've decided that it's necessary to fully accept the 128-bit
> > standard and support it in a consistent manner.
> > 
> > Therefore, I have taken the following actions:
> > 
> > I have dropped the option of supporting 80-bit temporary reals
> > entirely, as they are now incompatible as an internal format.
> > 
> > I have instead defined a 256-bit format for floats which does not
> > have a hidden first bit, which looks like the old temporary reals,
> > except that the exponent field is one bit wider.
> > 
> > And in addition, just as the IBM 704 used two single-precision
> > floats to make a double-precision float, and the IBM System/360
> > Model 85 started using two double-precision floats to make an
> > extended precision float... I've defined how the 256-bit internal
> > format floats can be doubled up to make a 512-bit float.
> > 
> > I'm not really sure such floating-point precision is useful, but I
> > do remember some people telling me that higher float precision is
> > indeed something to be desired. Well, the IEEE 754 standard has
> > forced my hand.  
> 
> YES, I'd use something similar:
> I never cared nor supported any odd 10 byte formats and I give a fart
> to all these weird IEEE standards.
>

I suppose, it's mutual.