Did any hardware-supported floating-point format ever fast-track integers?

Question

The floating-point format on the ZX Spectrum has the unusual feature of special-casing small integers: Why does Sinclair BASIC have two formats for storing numbers in the same structure?

There are excellent and sufficient reasons for this. Basic programming tends to be casual about types; many variables that could hold a floating-point number, in fact only hold small integers. The machine had no FP hardware; floating-point calculations were much slower than integer calculations. The upshot was that this design decision made many programs run a lot faster.

No one repeats it nowadays because there's no point. All modern general-purpose computers have floating-point hardware.

It seems to me there was an intermediate time, in the sixties for mainframes, seventies for minicomputers, eighties for microcomputers, when it could've made sense because floating-point hardware was possible but unusual. For example the IBM PC could have an 8087 installed, but most of them didn't.

The common strategy in this situation was to just go ahead and use IEEE format as though a coprocessor were expected: https://en.wikipedia.org/wiki/Standard_Apple_Numerics_Environment

Some programs used a different format designed for software floating-point: Did any PC software floating point use non-IEEE format?

But as far as I can tell, nothing else used a format that treated integers as a special case and made an effort to run them faster.

In many contexts, this makes sense; there would be no point treating integers as a special case if you expect numbercrunching workloads to consist of things like fluid dynamics simulations, as the likes of Cray did. The two kinds of workloads that do tend to have lots of integers where floating-point numbers were expected, are Basic programming and spreadsheets (well, scripting languages in general; JavaScript is a modern example, but was invented after all CPUs started including IEEE hardware), and IEEE 754 was not developed with those primarily in mind.

Was there ever any floating-point format designed (unlike the Spectrum) on the basis that hardware support was possible but uncommon, that was designed to fast-track operations when the operands happened to be small integers?

Answer 1

Computer architectures designed by Sergey Lebedev did not have a separate integer unit. Integers were represented as unnormalized floating point values with the exponent chosen to make the LSB have the value of 1.

E. g. on the BESM-6, the normalized representation of the value 1.0 is (in octal) 4050 0000 0000 0000 (7 bit exponent, sign, 41 bit mantissa, no hidden bit) that is 0.1₂ * 2^65-64. The integer 1 was 6400 0000 0000 0001, with the 1 bit in the least-significant position and the exponent incremented accordingly, which allowed to use the value in floating point operations unmodified, except as a divisor, which had to be normalized.

Fast-tracking of additive and multiplicative integer operations consisted of suppressing post-normalization (and given that the exponents of integer values are always the same, pre-normalization for additive operations was not required), and, for multiplication, of copying the low bits of the product from the special register to the result register (the accumulator).

Also see this old question of mine. While the theoretical maximum latency of a floating point operation was quite high, the average, thanks to "fast-tracking", was more than an order of magnitude lower.

Answer 2

In addition to the modern software implementation I mentioned, the LISP machines (from LMI and Symbolics) were notable for their hardware support for dynamic typing, including the ability to store either fixed-point or floating-point numbers and distinguish between them at runtime, with support in the ISA (implemented with microcode). Later machines in the series even had instructions that would trap if a datum were not the correct type.

The Cray-1 supercomputer from the same time period was also notable for being able to store either 64-bit integers or floating-point numbers, or vectors of up to eight of either, in the same registers and perform either kind of operation on them. The hardware itself did not define a single format comprising both, but it would be easy to test for a particular pattern of bits using its logical instructions. It also had an instruction to convert between an address register (such as a loop index or array offset) and an un-normalized floating-point number.

Answer 3

The question may be flawed due three misleading shortcuts:

1. Sinclair doesn't do hardware float, it's storage issue resulting in selection of according math routines for speed optimization on a restricted 8 bit CPU. Systems utilizing hardware FPU are usually way less constrained.

2. The difference between hardware based float and hardware based integer isn't as noticeable (if at all) once a hardware FPU is available - not to mention that integer is, within boundaries, a strict subset of float.

3. Next to all CPU have dedicated instruction sets for integer and float. Architectures that allows the handling of integer within their floating point units, like the 8087 and it's ofsprings, do so by converting them to and from float (*1) and using float instructions thereafter.

Oh, and a fourth one (*2):

4. Float vs. Integer is a use case szenario. The assumed 'there was an intermediate time, in the sixties for mainframes' never existed. For one, the huge majority of mainframe applications were integer (*3) not needing float at all (*4), or they were float based, needing Integer only for program flow which is best handled in the (integer part of the) CPU anyway.

Which directly leads to the special case of BASIC:

5. The Spectrum is a very specific case growing out of a need for optimization in a language that does handle integer only as second class citizen. Originally every numerical value in BASIC is float (*5). But while float may be only a bit slower on a machine with an FPU (*6), it's a disaster whens handled by an 8 bit integer CPU. Adding a few tests for integer values and using integer function whenever possible costs little compared to the possible performance gain. In fact, it saves, in addition, the need for an integer type.

Classic Win-Win.

---

*1 - Well, it's a bit more complex like that conversion is done into and from an internal 80 bit float, which guarantees 18 decimal digits without rounding, thus effectively acting as if it's an 18 digit decimal or 64 bit integer - at least as long as only likewise numbers are handled. Every operation with a float outside 64 bit Integer range will result in FP based rounding artefacts.

*1 - that's a classic off-by-one, isn't it?

*3 - Or more exactly integer and BCD

*4 - Well, I know some using float registers as scratchpad :))

*5 - Dartmouth BASIC and many other (early) BASICs of the 1970s did not have Integers at all. Even a function like INT() returned a float. String was the first different type to be added, Integer came only very late and not much supported.

*6 - Something the low cost Sinclairs for sure never had coming :))

Answer 4

SQLite to this day uses a dynamic type system in which integers, IEEE floating-point numbers, and other things are possible datatypes, selected by a storage class field in the format.

It’s common for languages with dynamic typing to hold data in this kind of discriminated union, but SQLite might be the only general-purpose database in wide use to write its data to disk in this format. Other databases associate a static type with each column.

I am not aware of any architecture with hardware acceleration for this, though.