[LLVMdev] Introduction for new consumer of LLVM

[Robinson, Paul]

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
> Behalf Of Herbie Robinson
> Sent: Thursday, January 15, 2015 9:50 AM
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Introduction for new consumer of LLVM
> 
> On 1/15/15 4:46 AM, David Chisnall wrote:
> > Hi John,
> >
> > It's great to hear that OpenVMS is not dead!
> >
> > On 14 Jan 2015, at 22:34, John Reagan <johnrreagan at earthlink.net> wrote:
> >> That includes BASIC, COBOL, Fortran, Pascal, C, BLISS (one of the
> OpenVMS implementation languages), and Macro32 (a compiler that accepts
> VAX assembly source code and emits object code for the appropriate target,
> either Alpha or Itanium).  On Alpha and Itanium, we use our own multi-
> language, retargetable backend called GEM.  Our strategy will be to write
> a converter between the GEM IL and the LLVM IL.  We will first be hosting
> the x86-target compilers as cross-compilers running on OpenVMS Itanium to
> bootstrap the OS and eventually the compilers themselves onto a future
> OpenVMS x86 platform. I suspect we will be contributing several
> interesting enhancements as we go along. We also intend to provide clang
> as well for our C++ offering.
> > Do you have any plans to resurrect the LLVM Alpha and Itanium back ends,
> to reduce the variation in compiler output across your platforms?  I
> imagine that doing GEM optimisations and then generating native code, vs
> doing GEM optimisations and then generating LLVM IR, doing LLVM
> optimisations, and then generate native code will give quite different
> performance characteristics (and very different interpretations of
> undefined behaviour).
> >
> > Also, I wondered if you'd considered (assuming that you are legally able
> to) open sourcing your Fortran front end.  There are a number of LLVM
> consumers who are interested in a high-quality Fortran front end for LLVM
> and several efforts in this direction.  There are probably some people
> interested in COBOL too, though that's a somewhat terrifying thought.
> >
> > For COBOL, I suspect that you will run into limitations with LLVM's
> (lack of) support for decimal floating point.  This is also theoretically
> a limitation for the C front end, but I don't actually know of any real-
> world C code that uses decimal floats.
> Cobol doesn't have floating point at all, unless there is a new
> standard...  It does have fixed decimal, but that can be done with
> binary integers -- although, you do need a 64 by 64 bit multiply with a
> 128 bit result and a 128 x 64 divide.  The former is a really fun
> challenge for SIMD :-)

COBOL-1985 certainly didn't have floating point, I'm pretty sure -2006 didn't
add it but won't swear to it.  (Binary floating point is a common extension.)
Decimal float hardware would be a hugely useful implementation aid, though.

The architectures I've used had a "multiply high" instruction that would
return the high 64 bits of the true 128-bit result of a 64x64 multiply.
I suppose you could make do with a 128x128->128 multiply. :-)

The biggest things a COBOL compiler would need from LLVM is debug-info support
for describing scaled integers, decimal types, and condition names.
--paulr