Re: Making Lemonade (Floating-point format changes)

On 5/12/2024 7:00 PM, John Savard wrote:

On Sun, 12 May 2024 20:12:22 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:
 

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.

 The explanation here is, I am afraid, probably once again ignorance on
my part. I knew that processing the hidden bit would take _some_ time
and effort, since, after all, in the early days computers didn't use
formats that had one.
 So I assumed that converting to an internal format without a hidden
bit - even the 8087 did that - would yield a significant speed up.
(And, as noted, I'm following Seymour Cray in sacrificing everything
for speed, so even if the speedup is small, I am inclined to chase
it.)
 

Only way it can save much is by not requiring immediate renormalization.
But, then one adds a new problem:
   Where, then, do they perform the renormalization?...
One option is on the Load/Store or Convert ops, but then one has mostly moved the cost from one place to another (and potentially more cost in total; if the number of internal format converters is larger than the number of FADD/FMUL units, which is generally the case).
Or, one may require explicit renormalization via an instruction prior to converter ops or similar, which adds clock-cycles to the process of using the FPU (though, granted, could potentially reduce the latency of the FPU ops slightly). Frequent renormalization would be needed in any case to limit loss of precision if values drift too far out of range.
However, if one still uses the IEEE formats in memory, this will add overhead to using the FPU in general.
Doesn't really seem like a win IMO.
Most potential small wins would be counterbalanced by adding more issues elsewhere.
So, as I saw it, the IEEE formats seemed better on this front.
Though, can note that the largest hardware-supported format is still Binary64 (because even truncated Binary128 was still too expensive, and had noted that it was better left to doing full-precision Binary128 in software).
Since, can note that "long double" is not generally used except in cases where it is actually needed.
And, the C "math.h" functions are defined as "double" by default in the C standard.
Can note though that a "Binary32 only" FPU would be much more limiting. In a general case, demoting everything to Binary32 would not be viable, but did at least at one point poke around with writing code on something which had been using 32-bit" double" (in this case, the underlying CPU was a Cortex-M, but this seemed to be non-standard even for Cortex-M).
Oh well, on my own side of things:
It seems there are still bugs with the preemptive multitasking, and hunting them down is being a pain. Seems like stuff is getting corrupted somehow, but not consistently.
Did recently start working on some stuff to support sockets, but probably local-only for now.
Current plan is to support TCPv4/UDPv4/TCPv6/UDPv6. Internally, ended up normalizing addresses to 128-bit, with IPv4 as a sub-range.
Unix sockets may also be supported (but which use string based addresses), but the current thinking is to normalize the strings also into the 128-bit space via hashing. Seems the traditional practice was to name the sockets with VFS file paths, just with an apparent 100 character name limit. The hashing will be invisible at the sockets API level.
...

John Savard