A GCC COBOL status report [LWN.net]

A GCC COBOL status report

Posted Feb 11, 2023 8:46 UTC (Sat) by Wol (subscriber, #4433) [Link] (3 responses)

> So this looks like something trivial to implement. Is there any hidden gotchas that my untrained eye didn't spot? or this is difficult because COBOL is not cool and there are no enthusiasts to hack on a compiler for it?

Probably this.

If the user and dev communities are the same, open source of one form or another flourishes. As soon as the user and dev communities diverge, like eg word processors (real programmers use TeX, Sphinx, etc not mere word processors), then open source struggles.

And COBOL is seen as horribly verbose and not pleasant to work with. Features that also, I believe, lead to its reliability because you have to specify everything ...

Cheers,
Wol

A GCC COBOL status report

Posted Feb 11, 2023 14:05 UTC (Sat) by joib (subscriber, #8541) [Link] (2 responses)

Disclaimer: I've never used COBOL myself and I don't work in the field.

An addition to the user and dev communities being distinct, I think there's a couple other factors making open source COBOL difficult:

- COBOL typically runs on a mainframe that comes with a support contract and an officially supported compiler, so little incentive to work on a FOSS compiler.

- The applications are typically bespoke in-house applications tailored to each organization. So you don't get megacompany X putting their payroll processing system up on GitHub, and suddenly COBOL programmers around the world descend on it and start improving it, so that anyone can download it and start doing payrolls for their company with it.

I guess the niche where Gnu COBOL could make an impact would be in migrations from a mainframe environment to a 'standard' Linux system, possibly even in the cloud.

A GCC COBOL status report

Posted Feb 13, 2023 21:15 UTC (Mon) by skissane (subscriber, #38675) [Link] (1 responses)

> COBOL typically runs on a mainframe that comes with a support contract and an officially supported compiler, so little incentive to work on a FOSS compiler.

There's a lot of COBOL apps out there that don't run on mainframes. Micro Focus' COBOL products for Windows and Unix go back a long way – in the late 1970s thru early-mid 1990s, Microsoft rebadged Micro Focus' COBOL products for CP/M, DOS, OS/2 and Windows 3.x as "Microsoft COBOL", and IBM similarly offered a rebadged Micro Focus as "IBM COBOL" for PC-DOS. Some of these apps started life out on a mainframe or minicomputer, but were ported off decades ago, and are still alive; others were written to run on a PC platform to begin with. Imagine it is 1985, and you are an MIS manager at some bank, and you manage a room full of mainframe COBOL programmers, and you want to get them started on writing some apps to run on PCs – a COBOL compiler for DOS would be an easy sale. And maybe, close to 40 years later, one of those DOS COBOL apps is still in use, running on Windows or even Linux, with an expensive Micro Focus COBOL runtime license (they don't just license the development tools on a per-seat basis, they do that for the runtime too.) Recompiling it with an open-source COBOL compiler, ditching the need to keep on paying those licensing costs, may have a certain attraction.

A GCC COBOL status report

Posted Feb 27, 2023 21:18 UTC (Mon) by nix (subscriber, #2304) [Link]

Aside: COBOL is really Micro Focus's strength (they've been doing it forever, like since before the 80s, they're older than Oracle and even less sexy), but they were also long known as the place old tired companies went to die: Borland, CompuWare, Novell... when they accidentally got hold of something actually exciting they got rid of it (SuSE).

As usual for the UK we couldn't hold on to it after the political excitements of the last few years (and the rollercoastering pound): the company has just been purchased by OpenText, a Canadian company only slightly more exciting than Micro Focus. I can't really imagine them changing much.

A GCC COBOL status report

Posted Feb 11, 2023 18:24 UTC (Sat) by khim (subscriber, #9252) [Link]

> Is there any hidden gotchas that my untrained eye didn't spot?

Yes. It's language from 1959, thus predates the language theory by a couple of decades. Grammar is pile of ambiguities and rules of resolutions are unclear and unwritten.

It's relatively easy to use it if you found out how resolution works for your usecases (via trial and error approach), but to write a compiler that actually passes the certification tests is hard and to make it work with real apps… we'll see how it'll work, but I applaud the audacity of these guys.

A GCC COBOL status report

Posted Feb 13, 2023 10:59 UTC (Mon) by maxfragg (guest, #122266) [Link] (17 responses)

That very much depends on one question:
do you want to execute COBOL with a COBOL execution model or with a C execution model.
Normally COBOL assumes a predefined memory layout, no call stack and no recursion. Not sure how easy those things are to support within GCC.
Also, Cobol has quirky features like division which returns result and remainder, multidimensional switch case and so on, if you want to support those features in a proper way and not "transform" them out of your way, so that you don't have to touch the backend, you are probably right

A GCC COBOL status report

Posted Feb 13, 2023 13:12 UTC (Mon) by pbonzini (subscriber, #60935) [Link] (16 responses)

Division which returns result and remainder are not a problem for gcc, it already supports them very well.

The most complicated part in any COBOL compiler front-end would be performing arithmetic on ASCII and BCD data types, with multiple encodings that made sense 50-60 years ago (e.g. embedding the sign in the first or last character). COBOL compilers were probably the only real-world users of the AAA/AAS/DAA/DAS instructions on the x86!

A GCC COBOL status report

Posted Feb 13, 2023 14:48 UTC (Mon) by Wol (subscriber, #4433) [Link]

> COBOL compilers were probably the only real-world users of the AAA/AAS/DAA/DAS instructions on the x86!

Dunno ... Certainly the INFORMATION variant of DataBASIC used BCD. Okay, that ran on 50-series hardware, but when it was ported to x86 as PI/Open, it may well have made use of those instructions (or not, as the case may be ...)

Cheers,
Wol

A GCC COBOL status report

Posted Feb 13, 2023 18:39 UTC (Mon) by mmaug (subscriber, #61003) [Link] (12 responses)

Being a "data" guy, the primary distinction of COBOL was its focus on DECIMAL arithmetic rather than binary. Since very few modern processors (if any) have native support for BCD encoded numerics, the operations must be done in library functions. That will lead to poor performance relative to pure binary numeric processing. However, for fiscal data (Payroll, billing, accounting, ...), there are no IEEE floats to approximate results and lead to Office Space-style penny rounding. But with 128-bit integers, you could do handle most problems with scaled integers and avoid floating point.

Aside: the MicroVAX was a single chip implementation of the VAX architecture which implemented about 100 of the most common/needed by VMS instructions, out of the 300+ possible, in hardware. The rest were software interrupts to emulate the instruction in VAX code. The instructions left off were the complex string and BCD instructions. Sales people were very careful to warn you not to buy a MicroVAX-based machine if you used COBOL (or DIBOL [DEC's Business language])

A GCC COBOL status report

Posted Feb 13, 2023 19:44 UTC (Mon) by Wol (subscriber, #4433) [Link]

> there are no IEEE floats to approximate results and lead to Office Space-style penny rounding. But with 128-bit integers, you could do handle most problems with scaled integers and avoid floating point.

Which is why Pick/MV natively handles *fixed* point numbers.

Okay, that brings its own set of challenges, but it certainly makes handling rounding problems easier when dealing with objects like pennies and Chinook helicopters.

Cheers,
Wol

A GCC COBOL status report

Posted Feb 13, 2023 20:58 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

This seems like a good example of needing to understand the problem space in order to understand the solution. It turns out that payroll and accounting have specific needs different from most computer programs. Their programs have to calculate numbers according to accounting rules, which are sufficiently different from standard floating point math that you can't just use floats and assume everything will come out right. COBOL is built to handle those financial calculations, so people who really need that accuracy use it. Those are the user requirements, and they are really non-negotiable.

A GCC COBOL status report

Posted Feb 13, 2023 23:15 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

Additions and divisions are not that bad; on 16-bit machines it takes about 10 instructions to do an add of a 4-digit value, but on 64-bit machines you can use the same number of instructions for 16 digits[1]. Multiplications and divisions are very slow. But in practice programs would spend more time doing I/O than decimal arithmetic.

(Many many years ago I spent quite some time admiring the decimal arithmetic routines that were generated by the Realia COBOL compiler. The compiler itself was pretty fast, and written itself in COBOL!)

[1] http://web.archive.org/web/20180831035425/http://hackersd... search for "arithmetic on BCD values"

A GCC COBOL status report

Posted Feb 16, 2023 7:34 UTC (Thu) by smurf (subscriber, #17840) [Link] (7 responses)

Well, if you want reasonable speed *and* payroll accuracy , today you'd probably use rational numbers (i.e. fractions) as your basic data type. Or 1/1000th cent or whatever (i.e. fractions with a fixed denominator). In fact, that's what I'd expect a reasonable optimizing compiler to convert all these pesky DECIMALs to. Even with inflation / govenments throwing money about like crazy, today's 64-bit integers should remain sufficient for that.

A GCC COBOL status report

Posted Feb 16, 2023 9:56 UTC (Thu) by geert (subscriber, #98403) [Link] (6 responses)

Always using 1/1000th of a cent is overkill, and may even be wrong.
When it comes to money, there are strict rounding rules to follow.
E.g. everything is rounded to a cent. Except for fuel prices, which must use an accuracy of 0.1 cent.
Cash amounts may have to be rounded to 5 cent.
1/1000th of a cent might be useful when calculating the BOM price of your new electronics device, when you order SMD resistors by the container ;-)

A GCC COBOL status report

Posted Feb 16, 2023 15:39 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

Do you round up or down?

If it's .5, which way do you go (and some places rule that you round to the nearest EVEN (or odd) number).

Okay, fixed decimal doesn't cover rounding rules, but it copes very nicely with correcting different mandatory precisions.

And don't throw significant figures into the mix! When we had the ERM, all calculations had to be done to six significant figures. THAT was fun! Not.

Cheers,
Wol

A GCC COBOL status report

Posted Feb 27, 2023 21:49 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

> And don't throw significant figures into the mix! When we had the ERM, all calculations had to be done to six significant figures. THAT was fun! Not.

Seriously? So for amounts higher than £9,999.99, you started losing precision?! I'd have expected dp at the very least.

A GCC COBOL status report

Posted Feb 27, 2023 22:33 UTC (Mon) by Wol (subscriber, #4433) [Link]

Sorry no.

All exchange rates had to be specified to six figures eactly. Iirc, being about 4 orders of magnitude apart, Sterling to Lire and back wasn't pleasant. Mostly on the display side, not the calculation, admittedly.

And then if you are calculating random exchange rates, rounding before quoting wasn't pleasant either.

Cheers,
Wol

A GCC COBOL status report

Posted Feb 19, 2023 20:15 UTC (Sun) by ssmith32 (subscriber, #72404) [Link] (1 responses)

Stock price quotes are not to the penny. They go out to ten-thousandths of a dollar:

https://www.investopedia.com/terms/d/decimal-trading.asp

So even 1/1000 isn't good enough.

A GCC COBOL status report

Posted Feb 21, 2023 19:42 UTC (Tue) by calumapplepie (guest, #143655) [Link]

1/1000 of a *cent* is

A GCC COBOL status report

Posted Feb 28, 2023 1:38 UTC (Tue) by mrugiero (guest, #153040) [Link]

And then you need to convert currencies. 1ARS is worth U$S0.005. There are cents for ARS too and you need to be able to account for them.
I risk guessing financial institutions do deal with multiple currencies.

A GCC COBOL status report

Posted Feb 23, 2023 12:46 UTC (Thu) by mrugiero (guest, #153040) [Link]

> That will lead to poor performance relative to pure binary numeric processing.
>

It's not just performance tho. I don't think that was even what the language designers were thinking of when they went for that, but I may be wrong.
When a language makes it easier to do the right thing than it makes doing the wrong thing, you make fewer mistakes. If I need to use a library for proper decimal arithmetic, there's a (high) chance that '0.11' will slip by accident both in my code and in review. Because that's the intuitive thing to write. Now, if '0.11' is actually the right thing and you don't need to give it extra thought, you do the right thing by default, almost by accident.

A GCC COBOL status report

Posted Feb 15, 2023 0:37 UTC (Wed) by amcrae (guest, #25501) [Link] (1 responses)

The 68000 had the ABCD and SBCD (add/subtract BCD values) so it was definitely expected around the early 80's that new MPU architectures must support COBOL/DIBOL orientated arithmetic.
I remember using RMCOBOL on the Radio Shack TRS-XENIX, which was a heck of a lot better option than BASIC.
IIRC this had a Z80 so it could run the Model II BASIC interpreter, and a 68K which ran Xenix (and used the Z80 for I/O).
RMCOBOL actually had lots of nice features that allowed some serious development for commercial s/w (multi-key database, record locking etc.).

A GCC COBOL status report

Posted Feb 27, 2023 21:51 UTC (Mon) by nix (subscriber, #2304) [Link]

The 6502 had a beautiful design: a flag bit (the D bit, bit 3) which changed the normal arithmetic instructions so they operated on BCD instead.

This design went nowhere because MOS patented it, so it was never reused in any architecture I'm aware of.