News for hackers. Stuff that matters.
Re:OpenVMS State of the Port to x86_64 [pdf] by protomyth on Monday July 17, 2017 @12:38AM (#14785697)
OpenVMS supports nine programming languages,six of which use a DEC-developed, proprietary back-end code generator on both Alpha and Itanium. We are creating a converter to internally connect these compiler front-ends to the open source LLVM back-end code generator, which targets x86_64 as well as many other architectures. (The other three compilers have their own individual pathways to the new architecture.)

This should be interesting when they get done. OpenVMS had a reputation of not going down and having amazing storage clustering. I found it a bit odd when I used it in college and years later on a job. I wish it had been open sourced, but I guess it makes me feel good to know it’s still going regardless.

Re:OpenVMS State of the Port to x86_64 [pdf] by trelliscoded on Monday July 17, 2017 @05:45AM (#14786938)
If you worked for one of their bigger customers, chances are someone paid for source access and it was available on an internal server :)

I browsed through a copy a few jobs ago and it's honestly kind of boring.

Re:OpenVMS State of the Port to x86_64 [pdf] by mtanski on Monday July 17, 2017 @08:04AM (#14787697)
Boring in this context sound correct.
Re:OpenVMS State of the Port to x86_64 [pdf] by ddp on Monday July 17, 2017 @08:27AM (#14787837)
VAX/VMS was always open sourced and available first on microfiche and later on CD. I don't know if this continued after Compaq and then HP came to own the code but that's how it started life. The only censored code was the license management facility, which realistically, was trivially subvert-able if you knew VAX assembly language.
Re:OpenVMS State of the Port to x86_64 [pdf] by iamcamiel on Monday July 17, 2017 @09:15AM (#14788177)
This isn't quite correct. What was - and still is - made available to customers willing to pay for it were listings, generated by the compilers, not the original sources. There are more bits and pieces besides LMF that are excluded, sometimes for security reasons, sometimes for legal reasons. Also not made available, are any of the build procedures. What was never done, is release the sources under an open-source license. The source listings are intended as a debugging aid, not as a way to rebuild the OS.
Re:OpenVMS State of the Port to x86_64 [pdf] by eej71 on Monday July 17, 2017 @08:53AM (#14787990)
While a factually correct description of what was made available, I don't think that's quite the intended meaning of "open source".
Re:OpenVMS State of the Port to x86_64 [pdf] by avian on Monday July 17, 2017 @09:14AM (#14788167)
"Open source" historically meant just that: that you could look at the source, in contrast to machine code-only software.

Only later did the term got confused with "free software" idea from Stalman and the "preferred form for making modifications" as he put it.

Re:OpenVMS State of the Port to x86_64 [pdf] by ams6110 on Monday July 17, 2017 @12:11PM (#14789837)
While "source listings as an aid to debugging" was definitely done, and still is (e.g. Microsoft Windows source is available to researchers), Wikipedia disagrees with the use of the term "open source" as ever meaning this.

The term "open source" was first proposed by a group of people in the free software movement who were critical of the political agenda and moral philosophy implied in the term "free software"

https://en.wikipedia.org/wiki/Open-source_model

Re:OpenVMS State of the Port to x86_64 [pdf] by avian on Monday July 17, 2017 @12:42PM (#14790173)
Interesting. I'm probably confusing some things. I was under the impression that the term "open source" was older than both the free software movement and "open source" as defined by Eric Raymond et al. Not sure where I remember that from. Thanks for correcting me.
Re:OpenVMS State of the Port to x86_64 [pdf] by eej71 on Monday July 17, 2017 @09:46AM (#14788421)
That's an interpretation that I had not seen before. You would probably need to provide some more references to evidence for that claim in order to combat the down voting.
Re:OpenVMS State of the Port to x86_64 [pdf] by mariuolo on Monday July 17, 2017 @04:37AM (#14786645)
> (The other three compilers have their own individual pathways to the new architecture.)

Is one of them for VAX or is binary support for that architecture being dropped?

Re:OpenVMS State of the Port to x86_64 [pdf] by ch_123 on Monday July 17, 2017 @04:45AM (#14786678)
Based on some of the prior documents, I believe they are:

MACRO-32 (The compiler for VAX assembly), C++, Ada

MACRO-32 works at a lower level than the other languages, and needs to generate assembly directly instead of an IR. The C++ compiler is being replaced by Clang, and the previous VMS releases used Adacore's compilers, so Adacore will need to be convinced to port their compiler to x86 VMS.

Re:OpenVMS State of the Port to x86_64 [pdf] by iamcamiel on Monday July 17, 2017 @02:41PM (#14791241)
Close. Macro-32 on x86 will use a lower-level interface to the same LLVM backend used by the other languages.
Re:OpenVMS State of the Port to x86_64 [pdf] by seasoned_geek on Thursday July 20, 2017 @09:58AM (#14812467)
Adding more OpenSource to OpenVMS is __NOT__ a good thing. Especially adding it at the compiler level.

Moving to a common back end, especially for BASIC, would be a truly wretched decision. It would also be the final nail in the coffin of the interactive BASIC environment which VAX had and the industry begged for on Alpha. When it to the Itanium (Itanic) hardware we were all too busy begging for a processor that wouldn't combust like Samsung Galaxy or one of those hoverboards.

The interactive BASIC environment wasn't just for students. It provided a great sandbox to test out algorithms quickly, much like today's script kiddies would call a modern IDE.