[llvm-dev] LLVM COBOL front end question [Re: A friendly question]

pawel k. via llvm-dev llvm-dev at lists.llvm.org
Mon May 10 15:00:36 PDT 2021


Hello,
Interested in works on pascal.

Best regards,
Pawel Kunio

czw., 6.05.2021, 17:54 użytkownik John Reagan <john.reagan at vmssoftware.com>
napisał:

>
> On 5/6/2021 11:21 AM, paul.robinson at sony.com wrote:
>
> >
> > As for who's interested in a COBOL front-end:
> > The OpenVMS people (vmssoftware.com) are definitely headed in the
> direction
> > of a native LLVM-speaking COBOL frontend, although I'm sure it would
> remain
> > proprietary.  That direction would presumably include adding DIBuilder
> > features for the COBOL data types, and getting LLVM to emit the proper
> DWARF
> > descriptions.  Haven't seen any signs of that happening upstream, though.
> >
> > --paulr
> >
>
> Yes, we have our Digital legacy COBOL frontend hooked to LLVM.  That
> frontend generates our legacy GEM IR which is then converted to LLVM IR.
> It is currently an Itanium-hosted cross-compiler but we're bootstrapping
> our compilers to native OpenVMS x86 right now (we have clang "working"
> on OpenVMS x86 on Virtual Box today).
>
> The frontend (and much of the companion library to process the DEC4/DEC8
> datatypes) still has Digital copyrights which are own owned by HPE and
> licensed to us.  I would be unable to opensource it without their
> permission.  And you'd get a nice vintage COBOL 85 compiler written in
> BLISS. :) :) :)
>
> As for the DIBuilder COBOL support, since our cross-compilers are based
> on an ancient LLVM 3.4.2 (due to the ancient Itanium C++ we have on our
> host systems), we have to refresh all of that with our native
> bootstrapping before I could even consider upstreaming any of that.  And
> we are just starting on our symbolic debugger so I don't know if
> anything we've done even works yet.  And I haven't even explained level
> 88 condition names to the debugger engineers yet. :)
>
> For those keeping score at home, what we have so far is our legacy
> compilers for BASIC, BLISS, C, COBOL, Fortran95, Macro-32 VAX assembly,
> and Pascal.  All but BASIC are in good shape.  BASIC and its RTL do some
> un-natural acts.  And now we just bootstrapped clang 10 (we had to pick
> something to start) by compiling on Linux using a mixture of OpenVMS and
> Linux headers and then moving the objects to OpenVMS for linking (using
> the OpenVMS linker of course).
>
>
>
> This e-mail (including any attachments) may contain privileged,
> confidential, proprietary, private, copyrighted, or other legally protected
> information. The information is intended to be for the use of the
> individual or entity designated above. If you are not the intended
> recipient (even if the e-mail address above is yours), please notify us by
> return e-mail immediately, and delete the message and any attachments. Any
> disclosure, reproduction, distribution or other use of this message or any
> attachments by an individual or entity other than the intended recipient is
> prohibited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210511/c6fc77b8/attachment.html>


More information about the llvm-dev mailing list