Timeline for Did any hardware-supported floating-point format ever fast-track integers?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 22, 2022 at 18:29 | comment | added | Leo B. | @supercat Only the 15 LSBs were considered, no need to denormalize if their value was known to be the right one. It is possible that some early machine code programmers used that trick, but I have not heard of it. And when programming in a high-level language, it is better to have variables typed according to the programmer's intent, and not use floating point variables for address calculations. | |
| Jun 22, 2022 at 17:12 | comment | added | supercat | Would there be any need to denormalize 15-bit addresses if they were represented by numerical values in the range 0x10000000000000 to 0x10000000007FFF? Or was denormalization easier than simply using numbers in a range that would cause the bottom 15 bits of the mantissa to coincide with the bottom 15 bits of the integer representation? | |
| Jun 22, 2022 at 16:53 | comment | added | Leo B. | @supercat To use a number as an address, it has to be denormalized. The 15 least-significant bits of mantissa are used as the address. | |
| Jun 22, 2022 at 16:43 | comment | added | supercat | Out of curiosity, do you know if addresses are all in numerical ranges that would allow hardware to ignore the exponent when performing memory accesses? I'd been thinking using floating-point addresses would be impractical because of the need to perform shifting, but thinking about it more that's not the case. To the contrary, using floating-point addresses would make indexing of objects with power-of-two sizes especially convenient, since when working with objects of any such size, one could use addresses that were scaled so that the size of the object in question would be 1. | |
| Jun 21, 2022 at 23:17 | comment | added | Leo B. | @supercat For addition and multiplication it is never an issue, as the number of significant bits in typical index values is way less than the number of mantissa bits in the numbers. There is a special provision in the circuitry of the (non-restoring) divider to ensure that if the dividend is an exact multiple of the divisor, the quotient is correct. | |
| Jun 21, 2022 at 23:03 | comment | added | supercat | In many circumstances, performing floating-point math with sufficient precision will be "just as good" as doing integer math, but array indexing--which forms a non-trivial fraction of many programs' execution time, requires whole numbers and is thus a case where "real" integer math would be better than floating-point, though it's interesting to note how different compilers handle the situation. | |
| Jun 21, 2022 at 22:50 | vote | accept | rwallace | ||
| Jun 21, 2022 at 22:42 | comment | added | Leo B. | @supercat As the compiler knows the types of index expressions, it is its job to apply the necessary type conversions in a proper order to compute the linear array offset according to the language semantics. This has nothing to do with number representation. | |
| Jun 21, 2022 at 22:36 | comment | added | supercat | Based on your last comment, I hope you figured out how my comment relates to the issue: multi-dimensional array indexing inherently involves integer multiplication and would be a bit awkward if all that existed were floating-point values, though I guess if one had a machine where all addresses were within the same power-of-two range it may be possible to treat the bottom portion of the mantissa as an address without having to do anything special to force the exponent value. | |
| Jun 21, 2022 at 22:11 | comment | added | Leo B. |
@supercat As Fortran is column-major, I had to change the indexing to exhibit the issue. The oldest Fortran compiler is silly: ARR(3, 2.5) returns the value assigned to ARR(8, 2); another one takes ARR(3, 2.5) as ARR(3, 2); the third one (written in the GDR) errors out with SUBSCRIPT OF ARRAY HAS NOT INTEGER TYPE. This has nothing to do with representation of floating point or integers, it is purely a compiler issue.
|
|
| Jun 21, 2022 at 21:46 | comment | added | Leo B. | @supercat I don't see how it relates to the topic. Please clarify your question. Moreover, in Fortran (to which you presumably allude), there were no bound checks. | |
| Jun 21, 2022 at 16:40 | comment | added | supercat | How was array indexing handled? If using row-major subscripts, would one have to expend special efforts to ensure that given ARR{10,4) an attempt to access ARR(2.5,3) wouldn't access ARR(3,1)? | |
| Jun 21, 2022 at 9:56 | history | edited | Omar and Lorraine | CC BY-SA 4.0 |
added 9 characters in body
|
| Jun 21, 2022 at 2:29 | history | answered | Leo B. | CC BY-SA 4.0 |