[LLVMdev] Introduction for new consumer of LLVM

Herbie Robinson
2015-01-15T17:49:42Z

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