Timeline for Did any hardware-supported floating-point format ever fast-track integers?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 21, 2022 at 23:16 | comment | added | Raffzahn | @Davislor It's not only that 'No one repeats it', but also no one did so in the past. Also, the question asks clearly for hardware support. It's already in the title. | |
| Jun 21, 2022 at 20:03 | comment | added | RonJohn | Most mainframes, being Big Blue and running COBOL, did Integer and BCD arithmetic. | |
| Jun 21, 2022 at 17:24 | comment | added | Davislor | I don’t see how the question is flawed in light of this. It states, “No one repeats it nowadays because there's no point. All modern general-purpose computers have floating-point hardware.” The question is asking whether any other systems have dynamic number formats | |
| Jun 21, 2022 at 16:36 | comment | added | supercat |
@Raffzahn: The other reason for using a 64-bit mantissa is that on a 16-bit or larger processor without an FPU, computations with a 64-bit mantissa that does not have an implied '1' will be just as fast as computations with any smaller size. IMHO, it's unfortunate that IEEE-754 didn't offer any recommendations for a 48-bit 'long float' type applying the same principle, since on many machines computations with such a type could be performed more efficiently than computations using float (and way faster than double) while offering more precision than the former type.
|
|
| Jun 21, 2022 at 14:11 | comment | added | Peter Cordes | I'm not sure why it's relevant, though. Choosing an actual integer type gives you a larger usable value-range for the same width. The obvious (to me) comparison is 32-bit int vs. 32-bit float, not 24-bit vs. 32-bit. That's why I had to guess what your "within bounds" was getting at, because that isn't the bound of the value-range of the float or a same-sized int. | |
| Jun 21, 2022 at 14:02 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 48 characters in body
|
| Jun 21, 2022 at 14:00 | comment | added | Raffzahn | @PeterCordes that's exactly the point of the 'within boundaries' constriction. The points made are generic. Note that no specific formats are mentioned, just the basic relation. Of course is a 32 bit float not able to hold a 32 bit int, but it can do so for any Integer 24 bit or less. And yes, it's exactly why Intel choose a 80 bit temporary float as it's 64 bit mantissa will be able to hold any 64 bit integer (and thus 18 digit BCD) without loss of precision. | |
| Jun 21, 2022 at 13:51 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 1 character in body
|
| Jun 21, 2022 at 13:48 | comment | added | Peter Cordes | My best guess is that you meant integer within the mantissa width of the float, like how the 80-bit x87 format can hold any value an int64_t can have. (So fild/fistp qword can round-trip any bit-pattern without changing it). Like in your footnote 1. | |
| Jun 21, 2022 at 13:45 | comment | added | Peter Cordes | integer is, within boundries, a strict subset of float. - Not sure what you mean by that. Not every int32_t is exactly representable as a 32-bit float, or int64_t as a 64-bit double. Their value-range overlaps, but large floats are farther than 1 apart from each other. So I don't think that's what you meant. Also, CPUs usually provide shift operations for integers, but rarely for FP bit-patterns, and only sometimes scaling another FP value by 2^trunc(x). (Like x87 fscale). But maybe you meant only consider operations that BASIC has? Please clarify, or footnote your simplification. | |
| Jun 21, 2022 at 12:06 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 75 characters in body
|
| Jun 21, 2022 at 12:00 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 49 characters in body
|
| Jun 21, 2022 at 11:44 | history | answered | Raffzahn | CC BY-SA 4.0 |