The use of 128-bit arithmetic in the library is completely integral to the
implementation.
Because a 128-bit integer can hold a 38-digit signed decimal number, I
decided to create a limit of 37 digits for user-defined variables, because
that gave me an additional digit to the right for rounding.
The ISO specification says 31 digits for fixed-point literals. Even that
requires 111 bits for signed values.
So, not only do I use __int128 for handling any values with more than 19
digits, I have to allow for the possibility that that somebody might want
to multiply a
PIC 9(36)V1 by a 9V9(36). They are both 37-digit numbers; one has 1
decimal place, and the other has 36 decimal places.
The product has 74 digits with 37 decimal places. That's an intermediate
value; the target location, if not big enough to hold the result after the
rightmost decimal places are trimmed away, results in a run-time error
condition that the programmer can choose how to handle. But if the target
is big enough, then the result is exact, after rounding rules are applied.
This meant I had to implement 128-by-128 bit multiplication, resulting in
a 256-bit product.
And it works fine. Could this be done with GMP? Sure. That was a can I
consciously and deliberately kicked down the road, partly because my boss,
who pays my salary, is of the opinion that 32-bit implementations don't
matter for COBOL as we enter the second quarter of the 21st century.
> -----Original Message-----
> From: Jakub Jelinek <ja...@redhat.com>
> Sent: Wednesday, March 26, 2025 08:30
> To: Robert Dubner <rdub...@symas.com>
> Cc: James K. Lowden <jklow...@cobolworx.com>; Richard Biener
> <rguent...@suse.de>; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] cobol: Get rid of __int128 uses in the COBOL FE
> [PR119242]
>
> On Tue, Mar 25, 2025 at 11:41:09PM -0500, Robert Dubner wrote:
> > I'll take a look at this tomorrow. Conditional compilation is one
> > possibility. Another is to bust that .h file into two; one that goes
> into
> > libgcobol and is accessed by gcc/cobol and libgcobol, and a second
that
> is
> > accessed solely by libgcobol. I'll want to look at the magnitude of
the
> > problem before deciding which.
>
> That would work fine too.
>
> Another question for later is if any of those APIs with __int128 are
> actually ever called from compiled COBOL code, or if after this change
> and your header split __int128 will be just a type internal to the
> library,
> with compiled COBOL code only storing stuff into memory as 16-byte
values.
>
> In that case, we could easily get rid of the __int128 dependency and
> enable
> COBOL support e.g. on many 32-bit architectures, by doing
> #ifdef __SIZEOF_INT128__
> typedef __int128 int128;
> #else
> class int128 {
> ...
> };
> #endif
> where the class would have overloaded operators such that it would work
> fully or mostly the same as native __int128 type. The library is
written
> in C++ so let's take some advantage of it. Guess it depends on
> what exactly is __int128 used for in the library and e.g. what C library
> functions are used with it if any.
>
> Jakub
