> -----Original Message-----
> From: Andrew Pinski <pins...@gmail.com>
> Sent: Wednesday, February 19, 2025 02:13
> To: James K. Lowden <jklow...@schemamania.org>
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] COBOL v3: 8/14 516K api: GENERIC interface
>
> On Tue, Feb 18, 2025 at 10:52 PM James K. Lowden
> <jklow...@schemamania.org> wrote:
> >
> > From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:11
> > PM EST
> > From: "James K. Lowden" <jklow...@symas.com>
> > Date: Tue 18 Feb 2025 04:19:11 PM EST
> > Subject: [PATCH] COBOL 8/14 516K api: GENERIC interface
>
> A few comments about this:
>
> > +static
> > +void
> > +treeplet_fill_source(TREEPLET &treeplet, cbl_refer_t &refer)
> > + {
> > + treeplet.pfield = gg_get_address_of(refer.field->var_decl_node);
> > + treeplet.offset = refer_offset_source(refer);
> > + treeplet.length = refer_size_source(refer);
> > + }
>
> This function (and many others) are missing a comment in the front
> describing what it does with each argument.
>
> > + _Float128 src = (_Float128)sourceref.field->data.value;
>
> Is this in the front-end or is this in the target library. Either way I
> see it is used unconditionally.
It's not in the library. That's front-end code. That particular code
fragment is taking a 128-bit floating point value calculated in the host
machine and generating the GENERIC to convert it to a 16-byte string that is
a 128-bit floating point number on the target machine.
The equivalent in C would be
_Float128 value = <floating point literal>;
> For the front-end, you should use the real.h interface for floats. For the
> target you need to use it only conditionally otherwise it won't work on
> targets which don't have _Float128.
> I noticed __int128 use in this file too. The same thing applies here
> except for the front-end, you should use the wide-int.h interface. And
> only define it conditionally for target code.
>
> Also you can't use 128bit integer as a tree type either unless you check
> the target supports it. There is at least one 64bit GCC target which does
> NOT support 128bit integers (HPPA64).
>
> I see strfromf128 is used here but that was only added to glibc in
> 2017 and GCC still supports older glibc that don't have full _Float128
> support. see above about using real.h.
>
And I can't tell you how much I appreciate this information, and we will be
acting on it. But right now our goal is to get the front end incorporated
into GCC-15.
There is an evolutionary timeline here. Jim and I have been working to get
a COBOL front end to GCC working. I work on a Dell x86_64 linux box. He's
been using an Apple aarch64 machine. Jim's focus has been the parsing of
COBOL, which is not, repeat not, a straightforward proposition. My focus
has been figuring out how to create the GENERIC tree that is fed to the
middle end. And I started with *nothing*. On the one hand, I had a
bazillion lines of code in the existing front ends, and on the other I had
some extraordinarily cryptic, incomplete, and (I later learned) inaccurate
information on the Internet. It's only because I have come through the
forest of reverse-engineering GENERIC creation that I can have this
conversation at all.
We are in pretty good shape on the x86_64 and the aarch64. And since those
are the only ones we currently can support, I have rigged up configure.ac so
that cobol just won't compile on anything else. I did that to avoid
breaking any build that might try (through, for
instance, --enable-languages=all) to compile cobol where it might not work.
We are only starting to turn our attention to the larger issue of the much
broader capabilities of the Gnu Compiler Collection, with the larger set of
build/host/target possibilities, and issues of cross-compiling.
That all said: The reason for using _Float128 is because the COBOL
specification requires a minimum of 32 digits of floating-point precision,
and for that one needs 128-bit floating-point numbers. And for fixed-point
we have implemented 38 digits of precision, hence the use of __int128.
And, indeed, now that I know about wide-int.h and real.h, I will be
investigating how to use them. I haven't done that yet because our focus
has been to take what we have working and get it into GCC, and then to
expand upon it.
Thanks again,
Bob Dubner
> Thanks,
> Andrew Pinski
