# Re: C arithmetic, was Software proofs, was Are there different

## gah4 <gah4@u.washington.edu>

Fri, 10 Feb 2023 23:47:40 -0800 (PST)

*From comp.compilers*

Related articles |

[3 earlier articles] |

Re: C arithmetic, was Software proofs, was Are there different *gah4@u.washington.edu (gah4)* (2023-02-08) |

Re: C arithmetic, was Software proofs, was Are there different *anton@mips.complang.tuwien.ac.at* (2023-02-08) |

Re: C arithmetic, was Software proofs, was Are there different *DrDiettrich1@netscape.net (Hans-Peter Diettrich)* (2023-02-08) |

Re: C arithmetic, was Software proofs, was Are there different *gah4@u.washington.edu (gah4)* (2023-02-09) |

Re: C arithmetic, was Software proofs, was Are there different *gah4@u.washington.edu (gah4)* (2023-02-09) |

Re: C arithmetic, was Software proofs, was Are there different *DrDiettrich1@netscape.net (Hans-Peter Diettrich)* (2023-02-10) |

**Re: C arithmetic, was Software proofs, was Are there different ***gah4@u.washington.edu (gah4)* (2023-02-10) |

Re: C arithmetic, was Software proofs, was Are there different *gah4@u.washington.edu (gah4)* (2023-02-11) |

Re: C arithmetic, was Software proofs, was Are there different *anton@mips.complang.tuwien.ac.at* (2023-02-11) |

Re: C arithmetic, was Software proofs, was Are there different *drb@ihatespam.msu.edu* (2023-02-12) |

| List of all articles for this month |

**From: ** | gah4 <gah4@u.washington.edu> |

**Newsgroups: ** | comp.compilers |

**Date: ** | Fri, 10 Feb 2023 23:47:40 -0800 (PST) |

**Organization: ** | Compilers Central |

**References: ** | 23-01-092 23-02-003 23-02-019 23-02-025 23-02-026 23-02-029 23-02-033 23-02-037 |

**Injection-Info: ** | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="18810"; mail-complaints-to="abuse@iecc.com" |

**Keywords: ** | arithmetic, comment |

**Posted-Date: ** | 11 Feb 2023 15:02:38 EST |

**In-Reply-To: ** | 23-02-037 |

On Friday, February 10, 2023 at 10:18:49 AM UTC-8, Hans-Peter Diettrich wrote:

(snip)

*> Please explain the provenience or purpose of that hidden bit with*

*> integral numbers. How can integral values be *normalized* so that a*

*> previously required bit can be hidden? Sign extension to a higher number*

*> of bits does not increase the value or accuracy of an integral number.*

*> [He said "mantissa", so it's floating point. I've certainly seen scaled*

*> integer arithmetic, but normalized integers other than +/- zero in systems*

*> with signed zeros seems unlikely. -John]*

Normalized binary floating point, with hidden one, is pretty common.

I knew IBM S/360 floating point for some years before learning about

those, and it seemed surprising at the time.

As for integers, though, there are some processors with a floating

point format that does not left normalize values.

Some CDC processors, if the value can be shifted, normalized,

as an integer value without losing bits on either end, choose that.

Even more, the exponent is zero for that case. I think some

Burroughs processors also do that.

The result of doing that is that, for values in the appropriate range,

the floating point instructions work for integer values. No instructions

are needed to convert (in range) integers to floating point.

There is so much fun history to the different floating point

formats used over the years. Now almost forgotten.

[I am not aware of any hidden bit formats before IEEE but the 704

manual noted that normalized mantissas always have a 1 in the high

bit so it wasn't a big leap. -John]

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.