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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/7dd875dd/attachment.html>
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> On Jan 14, 2015, at 2:34 PM, John Reagan <johnrreagan at earthlink.net> wrote: > > 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/62126d93/attachment.html>
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 From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of John Reagan Sent: Wednesday, January 14, 2015 2:34 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] 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. :) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150115/1d4bec08/attachment.html>
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. David
> 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.
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 :-)
> > 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> > 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. > > David > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Maybe Matching Threads
- [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
- [DebugInfo] DIBuilder missing interface to generate DWARF info for packed_decimal basic type.
- [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3