LWN: Comments on "A GCC COBOL status report"

A GCC COBOL status report

mrugiero — Tue, 28 Feb 2023 01:38:54 +0000

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

Wol — Mon, 27 Feb 2023 22:33:15 +0000

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

nix — Mon, 27 Feb 2023 21:51:15 +0000

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.

A GCC COBOL status report

nix — Mon, 27 Feb 2023 21:49:17 +0000

> 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

nix — Mon, 27 Feb 2023 21:18:08 +0000

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

mrugiero — Thu, 23 Feb 2023 12:46:48 +0000

> 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

calumapplepie — Tue, 21 Feb 2023 19:42:14 +0000

1/1000 of a *cent* is

A GCC COBOL status report

ssmith32 — Sun, 19 Feb 2023 20:15:10 +0000

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

flussence — Fri, 17 Feb 2023 19:22:13 +0000

Modern C++ provides a good approximation of it. Just sprinkle a few #defines in and nobody will be able to tell the difference.

A GCC COBOL status report

Wol — Thu, 16 Feb 2023 15:39:33 +0000

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

geert — Thu, 16 Feb 2023 09:56:01 +0000

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

smurf — Thu, 16 Feb 2023 07:34:06 +0000

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

amcrae — Wed, 15 Feb 2023 00:37:42 +0000

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

pbonzini — Mon, 13 Feb 2023 23:15:31 +0000

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

skissane — Mon, 13 Feb 2023 21:15:29 +0000

> 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

rgmoore — Mon, 13 Feb 2023 20:58:04 +0000

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

Wol — Mon, 13 Feb 2023 19:44:51 +0000

> 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

mmaug — Mon, 13 Feb 2023 18:39:54 +0000

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

Wol — Mon, 13 Feb 2023 14:48:07 +0000

> 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

pbonzini — Mon, 13 Feb 2023 13:12:56 +0000

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

pbonzini — Mon, 13 Feb 2023 13:08:45 +0000

Oh my God, that is insane. COBOL-85 finally made it possible to use structured programming as you would in other languages(*), and it had some virtues for what it was meant to do (batch processing on flat file databases, essentially). But now it's become essentially Java with a 1950s syntax?

(*) though some people, including my father, were worried that having loop bodies inside the PERFORM statements would cause too deep indentation, and preferred to keep those out of line!

A GCC COBOL status report

maxfragg — Mon, 13 Feb 2023 10:59:51 +0000

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

khim — Sat, 11 Feb 2023 18:24:02 +0000

> 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

ejr — Sat, 11 Feb 2023 18:09:13 +0000

IIRC, Cleve didn't know APL when he started his "FORTRAN interpreter". But agreed. I was able to learn APL2 in high school (late 80s), and it poisoned me for life. Ah, working on a PS/2 model 50 (yes, *that* burninating one) with the keyboard layout card just above the keyboard...

Numpy did draw from APL in a few ways. Designing these language/library systems is a pile of nasty trade-offs. Anyone else remember yorick?

Still pissed as USPS for losing my box containing Iverson's "A Programming Language," a first-ed K&R, and more.

Morgan-Stanley isn't as into A+ any more, alas. At least that's what I've gathered from recent conversations, but I could well be talking to a different slice.

A GCC COBOL status report

joib — Sat, 11 Feb 2023 14:05:28 +0000

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

Wol — Sat, 11 Feb 2023 08:46:18 +0000

> 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

vasvir — Sat, 11 Feb 2023 07:19:00 +0000

Honest question from someone that has only heard about COBOL.

Looking for COBOL in the internet I gather the impression that is a simple language to implement like BASIC or C. Certainly looks like way simpler that C++ or Rust. I didn't find macro system and they only peculiarity is the fixed size arithmetic.

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?

A GCC COBOL status report

donbarry — Sat, 11 Feb 2023 02:35:36 +0000

J and K are "parallel inspirations" you might say but in different directions. J was the work of the original designer of APL, Turing award winner Kenneth Iverson, in his last years. The implementation drew from the advice and work of Arthur Whitney, the designer of A+, K, and q, all inspired by APL. You might call them semi-intelligible dialects of one another, but Iverson's APL is the root of the tree.

If only J had become the "numpy engine" of Python. There would be a powerful combination. Instead numpy drew from Matlab, which copied a handful of features from APL -- badly -- and threw away the rest.

A GCC COBOL status report

felixfix — Sat, 11 Feb 2023 01:32:47 +0000

Oh well done Sir!

A GCC COBOL status report

magfr — Sat, 11 Feb 2023 00:16:25 +0000

One must say PLEASE and then it might COME FROM you.

A GCC COBOL status report

ejr — Fri, 10 Feb 2023 23:39:07 +0000

Oh, and Fortran officially no longer is an acronym. According to the evolving standard. Wish they'd commit to one matrix meta-data structure (side-eye at Damian).

While there is GNU APL, I don't think it's in sight for gcc. And the latest variant is K, iirc, as a successor to J.

A GCC COBOL status report

atai — Fri, 10 Feb 2023 22:02:08 +0000

sorry I meant 1985

A GCC COBOL status report

atai — Fri, 10 Feb 2023 22:01:38 +0000

so gcobol still has catch up to do (as it is only in 1965)

A GCC COBOL status report

flewellyn — Fri, 10 Feb 2023 21:38:06 +0000

Now, when can we expect GCC INTERCAL?

A GCC COBOL status report

dcg — Fri, 10 Feb 2023 21:00:23 +0000

Not sure if you are joking, but latest versions of cobol actually have generics... https://www.codeproject.com/Articles/56232/Enforced-Type-...

I miss dbase

mtaht — Fri, 10 Feb 2023 19:34:49 +0000

anyone remember when simple record at a time processing via a simply generated form was easy?

A GCC COBOL status report

dskoll — Fri, 10 Feb 2023 18:26:05 +0000

BASIC still lives on in a surprising place... Roku's BrightScript language is essentially BASIC.

A GCC COBOL status report

stumbles — Fri, 10 Feb 2023 17:56:55 +0000

Lol. Good one.

A GCC COBOL status report

jem — Fri, 10 Feb 2023 17:44:39 +0000

>And where's A Programming Language when you need it.

Take your pick from this list: https://aplwiki.com/wiki/List_of_open-source_array_languages

A GCC COBOL status report

Wol — Fri, 10 Feb 2023 16:55:47 +0000

Maybe the end of Beginners' All-purpose Symbolic Instruction Code is nigh.

Bring back FORmula TRANslation, I say!

And where's A Programming Language when you need it.

Cheers,
Wol