[llvm-dev] LLVM COBOL front end question [Re: A friendly question]

[via llvm-dev]

> I think there are a bunch of somewhat conflated here and it's probably
> worth unpicking them a bit.  They seem to be:
> 
>   - Is anyone interested in writing a COBOL front end for LLVM?
>   - Would a COBOL front end be considered for integration with the LLVM
> repository?
>   - Would projects to work on an LLVM COBOL front end be considered for
> the GSoC or similar?

Actually my first reaction was, retarget gnucobol to emit LLVM IR instead
of C, and run the LLVM backend on it.  (I'd speculated to myself about
doing this as a fun post-retirement project.)  There's probably licensing
questions to resolve there first.  I could see compilation speed getting
better as a result, although runtime performance is unlikely to be better
than routing through C.  Not clear what the effect would be on debugging;
it looks like there are a couple of packages out there that let you debug
COBOL using the existing gnucobol setup, and gdb doesn't understand COBOL
so if anything the debugging situation is likely to get worse.

I've retargeted a COBOL front-end in the past (not to LLVM), and I'd
estimate that it is significantly more work than one GSoC project.
(Not that I've actually looked inside gnucobol to see how it works.)

As for who's interested in a COBOL front-end:
The OpenVMS people (vmssoftware.com) are definitely headed in the direction 
of a native LLVM-speaking COBOL frontend, although I'm sure it would remain
proprietary.  That direction would presumably include adding DIBuilder 
features for the COBOL data types, and getting LLVM to emit the proper DWARF 
descriptions.  Haven't seen any signs of that happening upstream, though.

--paulr