A GCC COBOL status report

Posted Feb 13, 2023 10:59 UTC (Mon) by maxfragg (guest, #122266)
In reply to: A GCC COBOL status report by vasvir
Parent article: A GCC COBOL status report

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.