https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Robert Dubner from comment #6) > (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. OK. I am going to reply to parts of this - which does not mean I'm ignoring the rest, just that its going to take some digestion. > 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. I see - this sounds reasonable. > 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. Right .. so the main thing that needs to be clear is that the code and constants that are generated are for $target (and live in the same numerical spaces as the library and $target). (at the risk of teachin' one's grandma) The $host might have completely different characteristics from $target - it might not support the same numerical types or be the same endian-ness. Therefore one cannot, in general, use native host computations to produce literals for the target (at present, the code only happens to work when $host == $target or their numerical properties are identical). The things that Jakub pointed to are a series of tools that allow an arbitrary host to produce literals for an arbitrary target. The tricky bit is understanding how to wire those up and the deleted part of your reply is probably what needs to be digested to understand that. Keeping very clear separation between things $host and things $target will definitely save you sleepless nights later. > 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. It can be one of the more challenging parts of OSS... indeed .. but you are the maintainer(s) other people (mostly) cannot "just change your code" - they must present proposed changes for your review. I say "mostly" because there are some rules about obvious changes and permissions for global maintainers. I am sure we will be presenting you with proposed changes soon :) In some cases it will be for targets you might not have easy access to so possibly helpful. > And I am not used to how the time > evaporates like the last snowfall in a warm spring rain. doesn't it just.
