[LLVMdev] Introduction for new consumer of LLVM

[Herbie Robinson]

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 :-)