4 ms·
I worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. I would be a bit surp
by IainIreland 6y ago
I worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. I would be a bit surprised if they open-sourced it; OpenJ9 is open-sourced, but the COBOL compiler for Z is one of those rare compilers that is still being sold to paying customers.
- aparsons 6y agoThanks for the insight. I strongly suspect the COBOL compiler buyers are really just buying ongoing support and updates. Open sourcing should result in minimal revenue impact, but shared code might make it quite problematic license wise. Wouldn’t blame them for turning down that headache.
- CountHackulus 6y agoDid I work with you!? I also worked on the COBOL backend for TR. And yeah, I'd also be HIGHLY surprised if it ever got open-sourced.
- IainIreland 6y agoWe must have just missed each other. I started in January 2014.
- skissane 6y ago> I worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. Does it have anything in common with XL C? Does it use W code as an intermediate language? And what language is it written in? (PL/X? PL.8? C/C++?)
- IainIreland 6y agoAssuming nothing's changed since I left, the front-end is taken from the old COBOL compiler, and is written in PL/X. It emits WCode for the backend, which is written in C++. XL C is a separate codebase, with very little shared code IIRC.