<div dir="auto">Hello,<div dir="auto">Interested in works on pascal.</div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div dir="auto">Pawel Kunio</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 6.05.2021, 17:54 użytkownik John Reagan <<a href="mailto:john.reagan@vmssoftware.com">john.reagan@vmssoftware.com</a>> napisał:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 5/6/2021 11:21 AM, <a href="mailto:paul.robinson@sony.com" target="_blank" rel="noreferrer">paul.robinson@sony.com</a> wrote:<br>
<br>
><br>
> As for who's interested in a COBOL front-end:<br>
> The OpenVMS people (<a href="http://vmssoftware.com" rel="noreferrer noreferrer" target="_blank">vmssoftware.com</a>) are definitely headed in the direction<br>
> of a native LLVM-speaking COBOL frontend, although I'm sure it would remain<br>
> proprietary.  That direction would presumably include adding DIBuilder<br>
> features for the COBOL data types, and getting LLVM to emit the proper DWARF<br>
> descriptions.  Haven't seen any signs of that happening upstream, though.<br>
><br>
> --paulr<br>
><br>
<br>
Yes, we have our Digital legacy COBOL frontend hooked to LLVM.  That<br>
frontend generates our legacy GEM IR which is then converted to LLVM IR.<br>
It is currently an Itanium-hosted cross-compiler but we're bootstrapping<br>
our compilers to native OpenVMS x86 right now (we have clang "working"<br>
on OpenVMS x86 on Virtual Box today).<br>
<br>
The frontend (and much of the companion library to process the DEC4/DEC8<br>
datatypes) still has Digital copyrights which are own owned by HPE and<br>
licensed to us.  I would be unable to opensource it without their<br>
permission.  And you'd get a nice vintage COBOL 85 compiler written in<br>
BLISS. :) :) :)<br>
<br>
As for the DIBuilder COBOL support, since our cross-compilers are based<br>
on an ancient LLVM 3.4.2 (due to the ancient Itanium C++ we have on our<br>
host systems), we have to refresh all of that with our native<br>
bootstrapping before I could even consider upstreaming any of that.  And<br>
we are just starting on our symbolic debugger so I don't know if<br>
anything we've done even works yet.  And I haven't even explained level<br>
88 condition names to the debugger engineers yet. :)<br>
<br>
For those keeping score at home, what we have so far is our legacy<br>
compilers for BASIC, BLISS, C, COBOL, Fortran95, Macro-32 VAX assembly,<br>
and Pascal.  All but BASIC are in good shape.  BASIC and its RTL do some<br>
un-natural acts.  And now we just bootstrapped clang 10 (we had to pick<br>
something to start) by compiling on Linux using a mixture of OpenVMS and<br>
Linux headers and then moving the objects to OpenVMS for linking (using<br>
the OpenVMS linker of course).<br>
<br>
<br>
<br>
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.<br>
</blockquote></div>