A GCC COBOL status report

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

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!

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.

> 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.

> 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

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])

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.).