https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #6 from Robert Dubner <rdubner at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #5) > In my experiments with x86_64 Darwin and Linux, I have managed to convert > the library to use libquadmath. > > I started to try and apply Jakub's suggestions to the FE for this BZ, since > what it is doing at the moment clearly cannot work in the general case (I > think it will be limited to native builds in general at the moment). > > However, unfortunately I have not been able to figure out how all of this is > supposed to fit together: > > 1. the FE pulls in a lot of library headers > 2. the FE pulls in some of the library sources > 3. the functions that make use of host 128b FP do not seem to have head > comments describing their purpose. > > In short, I'm stuck (at least in the time I have available) in progressing > this - but suspect it's one of the most important changes to make in > supporting the "usual build process" for GCC. > > Is there any kind of "internals manual" for cobol? (apologies if it is under > my nose and I missed it). > > ... in the short-term I have some heinous hacks that allow it to build > (native) on x86_64 Darwin, without breaking Linux .. but ... No, there is nothing like an internals manual. There is a fair amount of functionality that is performed identically in both compile-time and in run-time. For example: COBOL needs to be able to run using both ASCII and EBCDIC as the run-time internal character set. In support of that, we do conversions between EBCDIC, ASCII, and UTF-8 (basic COBOL uses 8-bit characters, but in general we need to convert to and from a UTF-8 locale, because that's what the terminal could be running). Those conversions are done by both the compiler and the compiled executable, and so I rigged things up so that the front end uses the same source code as the library. Numerical calculations: In COBOL you can define a 32-digit integer named 32-DIGIT-INTEGER, and you can have statements like "ADD 123456789012345678901234567890 TO 32-DIGIT-INTEGER" (And, yes, 32-DIGIT-INTEGER is a perfectly legitimate COBOL user-declared identifier. I have started to forget why COBOL, at first glance, causes a modern programmer's eyes to glaze over, then I remember that stuff like that can happen.) So, the host needs to be able to do 128-bit arithmetic. I chose to do it with __int128 and _Float128, because I was young and ignorant and provincial. What's possibly perplexing you is at the borderline between the compiler making calculations of constants, and then the GENERIC that I generate to make those constants available to the run-time. And I had the advantage, and the disadvantage, of not knowing how anybody else has solved those problems. I just dived in. What might take some adjusting for experienced GCC programmers is that there is no such thing as a COBOL variable type, in the sense that int8_t, int32_t, and so on are C variable types. COBOL variables are implemented as structures, and I use GENERIC, where I can, to manipulate those structures as if the GENERIC were assembly language. More complex manipulations are done by calls to libgcobol.so. So, you might be looking at the GENERIC that's manipulating those cblc_field_t run-time structures. The matching compile-time structure is cbl_field_t, and one of its fields is the "tree var_decl_node" that is the reference to the cblc_field_t structure. (I get confused when I talk about this. I have no trouble programming it, but talking about it ties me up in knots. There's something about talking about writing C code that interprets COBOL and generates GENERIC that creates the assembly language that causes a processing queue in my brain to overflow.) I plan to make the switch to real.h and wide-int.h in the host code. What happens in the libgcobol code, I have yet to sort out. But I underestimated the number of moles that were going to pop up by having the COBOL front end added to GCC-15, and I overestimated the speed with which I would be able to whack them. And I also -- forgive me, for I am sinning -- am simply not used to other people diving in and changing code I've written. It's great, and I welcome it. But I am just not used to it. And I am not used to how the time evaporates like the last snowfall in a warm spring rain.
