On Thu, Mar 13, 2025 at 06:33:08PM -0400, James K. Lowden wrote: > I guess the most controversial engineering choice was to rely on > __int128 and _Float128. Those gave us native processing and binary <-> > string conversion. Having been advised of real.cc, we're taking a > look. If we can get 128-bit hardware computation more portably, that's > all to the good.
One thing is the compiler and another thing the target library and what the compiler emits. gmp was an alternative for wide_int (see https://gcc.gnu.org/PR119242 for a partial patch, which proves it can be just done in wide_int pretty easily when the conversion from _Float128 inside of the compiler source is finished). I see there _Float128 value used to store various values in the FE, is it used to store not just floating point but also integers? E.g. all possible __int128 or unsigned __int128 values certainly can't be represented in _Float128 (while 64-bit integers can). Another is use of gmp in libgcobol, I think there is no need for that there. I'd suggest just to use tree as storage for the values in the FE (at least where it currently mallocs some memory and stores the values directly in there) REAL_CSTs for floating point and INTEGER_CSTs for integers. For REAL_CSTs, the real.cc APIs allow to convert a string to REAL_VALUE_TYPE (see real_from_string{,2,3}), do rounding, arithmetics, convert REAL_VALUE_TYPE to string (see real_to_decimal) or convert from wide_int (real_from_integer). I saw there multiplication of _Float128 by __int128 (the latter being some power of 10, from 1e0 to 1e38), not really sure how is that supposed to work in general because the few largest powers of 10 are not exactly representable in _Float128. > But I don't see the point, in 2025, of gmp. it's more important that > COBOL take advantage of current hardware than run on a VAX. > That's where users are. Hardware computation has real benefits, and > software math has measurable impact. When the IT budget has a line > item for electricity, that's what matters. Note, __int128 support isn't implemented in hardware almost anywhere, on 64-bit targets it is typically implemented using 64-bit arithmetics, sometimes with help of 64x64->128bit multiply (or highpart 64x64->64 multiply) and/or 128/64->64bit division/modulo. Similarly, _Float128 is implemented in hardware only on a few targets, I think mainly s390x and more recent powerpc (sparc has it in the ISA but I think it used to be software emulated), so e.g. on x86_64 or I think on aarch64 too _Float128 is just software emulated. Jakub
