COBOL for GCC Development | Hacker News Reader

COBOL for GCC Development

cobolworx.com

72 pointspantalaimon21 comments

This is pretty neat, I'm not a huge COBOL fan but actually got paid once to write code that generated outreach mail for political correspondence using voter registration data. For that, it worked really well and I could certainly appreciate the appeal for business process work.

Weirdly though, I get put off by their name, as my brain wants to pronounce it with a long o sound instead of the 'eh' sound from 'works' (werx as a spelling works better for me than worx, no pun intended). It has me wondering if people pronounce 'Torx' screws as 'Turks' screws.

Isn't the first "o" is a long o?

As for the 2nd "o", I don't know. Whatever the case, you should say the entire word slowly and loudly since they are all capital letters.

Like, imagine yourself as an inept alien spy. You walk up to a group at a party and interrupt someone in the middle of their story. "HELLO, I AM BOB FROM CORPORATE. I PROGRAM IN COBOL. HOW ARE ALL OF YOU TODAY?"

That's how you should pronounce it.

I've heard that GCC is notoriously difficult to create a front end for and that is one of the reasons people liked using LLVM. Has this improved recently or are people just powering through the internal code to get this working?

This was one of LLVM’s explicit design criteria, but with its long head start gcc still has more front ends. It’s had so many that some (like chill) have even been removed! It’s not extraordinary that someone would use gcc as a back end for a new language.

I have only looked at the GCC Fortran frontend. I would not say it is necessarily difficult but rather very ad-hoc and disconnected from the rest of gcc. I don't see many tools for specifying a grammar or tokens. Instead, there are a lot of constructs custom-written to handle Fortran. Looking around, the Go and Rust frontends feel equally disconnected.

I'm told that you eventually make your way to the "GCC IR", but it seems like you are largely on your own with how to get there.

I did not invest a lot of time here, so I could be wildly off base, but thought I'd at least try to give a very-slightly-hands-on perspective.

Oracle Linux packages GNU COBOL in their EPEL distribution. The package is mature.

https://www.gnu.org/software/gnucobol/

  $ rpm -q gnucobol
  gnucobol-3.2-1.el9.x86_64

  $ rpm -qi gnucobol | tail -2
  COBOL compiler, which translates COBOL
  programs to C code and compiles them using GCC.

It will output intermediate C; one interesting thing is that the MOVE directive is mostly turned into memcpy().

I have been able to get the Oracle Pro*COBOL preprocessor to fully compile and run a demo database connection that connects to the "scott/tiger" schema and runs simple queries. Oracle packages both Pro*C and Pro*COBOL here (look for " Additional files for Pro*C and Pro*COBOL"):

https://www.oracle.com/database/technologies/instant-client....

It built with the two commands:

  procob MODE=ANSI INAME=procobdemo.pco ONAME=procobdemo.cob
  cobc -x -fixed procobdemo.cob /instantclient_21_12/cobsqlintf.o /instantclient_21_12/libclntsh.so

There is a similar "embedded SQL" implementation for PostgreSQL.

https://github.com/opensourcecobol/Open-COBOL-ESQL

There are a few other free COBOL compilers.

http://mainframeking.blogspot.com/2012/01/free-cobol-compile...

I want to look at the parser for the COBOL syntax, but I'm not sure if I'll ever be in a place emotionally to do so.

Kudos to the folks that are writing the parser!

Parsing cobol is actually not bad. The grammar is pretty simple; the "rail road" diagrams correspond to the recursive descent parser very directly.

https://www.ibm.com/docs/en/cobol-zos/6.1?topic=division-ide...

Interesting, I remember it be harder than that. But, when I had to write a basic parser during the Y2K storm, I was still a bit green in my programming skillsets.

Hmm, yea. I guess I'll have to take a look and see how they handled it. Thanks for the link!

Yeah, IFAIK it's not LL1, LL2, nor even LL3.

Glad to see gcc getting support for more languages!

It's nice to be able to use the same compiler for everything (not that I use cobol, or plan to use it...)

Pretty surprised to see this given GnuCOBOL (previously OpenCOBOL) has been part of the GNU project for a little while. https://gnucobol.sourceforge.io/

It makes sense as OpenCOBOL isn't part of GCC as a front-end, it generates C code that is compliant to various COBOL standards and extensions. That C code can subsequently be audited and/or compiled with GCC/clang.

How does one debug with GnuCOBOL?

Using gdb. On the GnuCobol site you see a Screenshot of a debugging session in VS Code https://gnucobol.sourceforge.io/ https://gnucobol.sourceforge.io/images/VSC_ScreenShot.png

How much COBOL runs on platforms other then the Mainframe? My limited COBOL experience was while working for a Mainframe software vender. I have not scene anything about people running COBOL in production on non Mainframe platforms, doesn't mean it isn't happening though.

There is no .NET for mainframes, and yet,

https://www.microfocus.com/en-us/products/visual-cobol/overv...

TIL there is COBOL support in the DWARF standard. I wonder if this gcc FE generates it.

DWARF supports quite a few languages: https://dwarfstd.org/languages.html

COBOL on Dreamcast when?

Oh, I've mistakenly read that as "Develop GCC using COBOL".

And this is not the existing GnuCobol compiler https://gnucobol.sourceforge.io/

Yeah it's a pretty unfortunate headline. Reads as "COBOL for (GCC Development)" when it's being used to mean "(COBOL for GCC) Development".

Reply on news.ycombinator.com