Introduction for new consumer of LLVM

Hello,

I’d like to introduce myself, my company, and our upcoming use of LLVM.

My name is John Reagan. I’ve been working on compilers and assemblers since 1983 (yes, 31 years). Most of that time was spent on compilers for VAX/VMS (later renamed to OpenVMS), then OpenVMS on Alpha, and OpenVMS on Itanium. I’ve also worked with the HP NonStop platform and was directly involved with the compilers for its upcoming port to x86.

OpenVMS ended up at Hewlett-Packard after Digital was sold to Compaq, and Compaq was sold to Hewlett-Packard. HP transitioned OpenVMS to an engineering organization in India. A new company called VMS Software Inc (VSI) was founded and we’ve licensed back the OS and layered products for future enhancement. That includes a port to the x86-64 platform. We have chosen to use the LLVM compiler infrastructure for our port to x86.

OpenVMS has a large family of compilers that we will be porting onto x86. 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.

I’ve been reading as much as I can and doing lots of preliminary design and prototyping. I’ve been very impressed with the online documentation (only found one broken link so far) and the infrastructure in general.

I might be asking lots of simple questions, but I hope everybody can put up with me. J

I also plan on submitting a paper for this fall’s developer’s conference.

Please feel free to ask questions, etc.

John Reagan

John dot Reagan at vmssoftware dot com

Hi John,

Welcome to LLVM!

I have many (mostly fond, I promise!) memories of assembly programming on VAXen. It will be fun seeing that come full circle with clang and LLVM.

In addition to the development lists, you may also find the IRC channel useful.

-Jim

Howdy, John! Small world and all that…

From what I remember of GEM IL, translating to LLVM IR should be reasonable. Looking forward to your presentation in the fall!

–paulr

Hi John,

It's great to hear that OpenVMS is not dead!

Please feel free to ask questions, etc.

Did you plan to add support for non-call exceptions ? That looks almost needed by VMS but not yet present in LLVM (although already discussed).

Tristan.

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

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. :slight_smile:

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

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

I have no special insight into VMSSoftware's plans in general or John's
in particular, but as a former DEC and HP employee I think it's safe to
say that the risk of adopting new compiler technology for *existing*
platforms is too high for sensitive corporate nervous systems to take.
And that "new" technology consists of resurrecting some pretty old
backends (they were removed in what, LLVM 3.0?). Not saying it could
never happen, but stability of existing platforms is very important in
the enterprise space.
--paulr