> -----Original Message-----
> From: Joseph Myers <josmy...@redhat.com>
> Sent: Thursday, January 2, 2025 14:21
> To: Robert Dubner <rdub...@symas.com>
> Cc: James K. Lowden <jklow...@schemamania.org>; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] COBOL 1/8 hdr: header files
>
> On Thu, 19 Dec 2024, Robert Dubner wrote:
>
> > At compile-time (or on the host), we also do numeric calculations.
> > The ISO specification allows for compile-time computations specified
> > in the source code. In addition, at times I put initial values for
> > the COBOL variables into the run-time structures that are the COBOL
> > variables. In order to create those CONSTRUCTOR nodes we have to do
> > those calculations at compile time, hence the use of __int128 and
> _Float128 in the host code.
> >
> > In the run-time/host code, I have been using intTI_type_node for
> > __int128, and unsigned_intTI_type_node for __uint128. For floating
> > point, I've been using float32_type_node, float64_type_node, and
> float128_type_node.
> >
> > If there are recommendations as to what would work better across other
> > architectures, I am all ears.
>
> As has been noted, wide_int can be used for large integer arithmetic
> within the compiler.
My needs are modest; we use __int128 in only a few places in the host
code. If __int128 were supported by 32-bit GCC, we'd wouldn't be having
this conversation.
But since __int128 isn't available, what I need is a drop-in replacement
for __int128. What I don't see, yet, is how to use wide_int as a such a
replacement.
So, for example, in code that runs on the host I'll convert a string of
numerals to __int128 by doing something like
__int128 value = 0;
while(*p)
{
value = 10*value + *p++ & 0x0F;
}
And when I need to go back to a string, the loop likes like
{
ch = value % 10 + '0';
value /= 10;
}
If I could be pointed to a place to see how that's done, well, it'll save
me a lot of looking through the existing code.
> For floating-point arithmetic, there are the
> interfaces in real.h to handle floating point within GCC's internal
> representation (note that some of the operations might leave a result
with
> extra internal precision; see how fold-const.cc:const_binop calls
> real_arithmetic followed by real_convert to ensure correct rounding to
the
> desired format, for example).
Again, I am not sure we're talking about the same thing. We have host
code that uses _Float128 values. That's because there are COBOL compiler
directives that need floating point values that can be bigger than IEEE
binary64. And the COBOL programmer can create source code like
77 float-val USAGE FLOAT-BINARY-128 VALUE 1234.56789 .
and so our compile-time structure for such variables contains a _Float128
value to hold the initial value. So, again, we'll need a drop-in
replacement for _Float128 that runs on a 32-bit host.
>
> I don't know if you support decimal floating-point in your front end,
but
> the real.h interfaces deal with that as well (via calling out to
> libdecnumber for arithmetic on DFP values). Again, DFP support on the
> target (which is supported for a much more limited set of architectures
-
> just aarch64 / powerpc / x86 / x86_64 / s390) does not depend on DFP
> support on the host, since libdecnumber handles all the DFP arithmetic
> required within the compiler.
The latest ISO specification for the COBOL language allows the programmer
to specify DFP in the IEEE754 decimal64 and decimal128 flavors.
Implementing those is not even on our priority list. (My personal opinion
is that I would be astonished to discover there is a single COBOL program
in the world that utilizes those.)
>
> --
> Joseph S. Myers
> josmy...@redhat.com
