Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Making Lemonade (Floating-point format changes) Date: Sun, 12 May 2024 20:12:22 +0000 Organization: Rocksolid Light Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="902883"; mail-complaints-to="usenet@i2pn2.org"; posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A"; User-Agent: Rocksolid Light X-Rslight-Site: $2y$10$sJa4AkRwu417JhWQrg/iF.5T2lJtK6B0h4VVFtz5TaZSl9PMB4lda X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8 Bytes: 2360 Lines: 35 John Savard wrote: > On Sun, 12 May 2024 13:46:28 -0000 (UTC), Thomas Koenig > wrote: >>John Savard schrieb: >> >>> 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. >> >>Why not the IEEE binary256 (interchange) format? >> >>https://en.wikipedia.org/wiki/Octuple-precision_floating-point_format > Oh, drat. I had not realized that they had also defined this. > Now that means I need to make the exponent field in my internal > format larger, define a 512-bit floating point number which is in the > internal format, so that it can be unnormalized, and a 1024-bit > doubled-up float... instead of what I just did! > The enlarged exponent field won't make the internal form of the > 128-bit float go over 160 bits, so register allocation for th at won't > change... but now I will have to figure out a scheme of register > allocation applicable to the 256-bit floats! > I am not amused. Question:: why are you all so gung-ho on having a format without a hidden bit. It is trivially easy to reconstruct:: h = expon != 0; Taking little time of even gates; and is something you HAVE to do anyway. > John Savard