[Info-vax] VSI: "Official 8.4-1H1 Launch"

[johnwallace4 at yahoo.co.uk]

On Friday, 5 June 2015 15:09:00 UTC+1, Jan-Erik Soderholm  wrote:
> johnwallace4 at yahoo.co.uk skrev den 2015-06-05 15:43:
> > On Friday, 5 June 2015 12:45:39 UTC+1, clairg... at gmail.com  wrote:
> >> On Friday, June 5, 2015 at 4:14:51 AM UTC-4, Phillip Helbig (undress
> >> to reply) wrote:
> >>> In article <mkqudh$s1c$1 at dont-email.me>, "Robert A. Brooks"
> >>> <FIRST.LAST at vmssoftware.com> writes:
> >>>
> >>>> If there is any portion of VMS that is going to be rewritten in a
> >>>> new language for the purposes of removing the requirement of the
> >>>> original language, it would be stuff that's written in Ada.
> >>>>
> >>>> That said, we recognize the importance of Ada for many of our
> >>>> customers, so we will have an answer at some point (and I have no
> >>>> idea when that point will be).
> >>>
> >>> Is there a list of compilers which VSI plans to support?  Is there
> >>> a list which they plan to support better, which means supporting
> >>> the latest standard completely within, say, two years of
> >>> publication?
> >>>
> >>> VAX FORTRAN was the gold standard of compilers.  It was Fortran77.
> >>> The VMS Fortran95 compiler is also good.  Unfortunately, that's the
> >>> latest supported standard.  While I am very much "old school"
> >>> regarding Fortran programming, I do use new stuff if a) it is better
> >>> (it usually is) and b) it is something I need.  With regard to the
> >>> latter, Fortran90 brought in a lot, and Fortran95 (a much smaller
> >>> revision) brought in a few more things.  Since then, I haven't
> >>> looked at the standards in detail.  Once, however, I ran across
> >>> something which is possible in Fortran95 but in an ugly-workaround
> >>> sort of way, which is elegantly solved in a later standard.  I'm
> >>> sure there are at least a few more things I could use, and even
> >>> other old-school programmers can make use of many new features which
> >>> I don't use.
> >>>
> >>> I also remember, back when I was working in academia, that someone
> >>> wanted to use the CXX compiler on VMS since it was better than the
> >>> one on SUN.  (Really!  Standard code wouldn't compile with the SUN
> >>> compiler.)
> >>>
> >>> It would be nice if VSI could bring VMS compilers back to the
> >>> cutting edge.
> >>>
> >>> Make Steve Lionel an offer he cannot refuse.  :-)
> >>
> >> There are many questions here and I think I could answer them all
> >> right now but some topics I talk about in public presentations so here
> >> are few answers.
> >>
> >> VMS has nine language compilers: Ada, BASIC, BLISS, C, C++, COBOL,
> >> FORTRAN, MACRO, and PASCAL. Plus, we need the assembler for each
> >> architecture. Our thought is to concentrate on keeping C, C++, and
> >> FORTRAN up to date standards-wise and evaluate the needs of the others
> >> as they arise.
> >>
> >> Even if we eliminate our own use of Ada we will still need to provide
> >> a compiler for the customers so all nine compilers will be on x86
> >> regardless of our own internal needs.
> >>
> >> For our GEM-based compilers (BASIC, BLISS, C, COBOL, FORTRAN, PASCAL)
> >> we will continue with the current frontends and integrate them with
> >> the LLVM (LLVM.ORG) backend code generator. MACRO is a little
> >> different but will also connect to LLVM. One of the many nice things
> >> about LLVM is that it targets multiple architectures.
> >>
> >> VMS_LOADER.EFI is written C and reasonably standard for any platform.
> >> (We get if from UEFI.ORG.) We added a few modules in assembler (for
> >> Itanium). Our VMS_LOADER.EFI calls the primary VMS loader IPB.EXE and
> >> it is also mostly C with a bit of assembler. These two files do most
> >> of the configuration setup and when IPB brings in and starts SYSBOOT
> >> we are off an running. That is the short version of booting, of course
> >> there are a million things happening to make this all work.
> >>
> >> Not emulators but VMs. We need to run directly on x86 and as a VM
> >> guest and we plan to take advantage of the debugging environment of
> >> KVM whenever we can along the way. I'm getting lots on "advice" from
> >> the KVM folks on the advantages.
> >
> > Some interesting snippets there, probably with far more behind them than
> > can sensibly be discussed here and now, perhaps both technically and
> > commercially.
> >
> > Is there a boot camp this year?
> >
> > Is this kind of thing (primarily languages, maybe tools where they
> > impact languages) a suitable topic for a session (or two) there, which
> > can then be recycled around the world as appropriate?
> >
> > There may also be people who will soon have a new-found interest in LLVM
> > and/or KVM; some readers will already know about these things but others
> > would likely appreciate pointers...
> 
> You mean, apart from: http://llvm.org/ ??
> 
> And I guess that KVM is this:
> http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
> 
> 
> > to OS-independent stuff which might be relevant to the VMS world in due
> > course.
> >
> > Thanks for the update.
> >

Well yes. And yet no.

I was hoping for OS-independent stuff for folk who haven't seen these
things before.

The Wiki article for KVM starts by saying "KVM (Kernel-based
Virtual Machine) is a virtualization infrastructure for the Linux
kernel that turns it into a hypervisor, which was merged into the
Linux kernel mainline in February 2007.[1][snip] KVM has also been
ported to FreeBSD[3] and Illumos[4] in the form of loadable kernel
modules.

KVM originally supported x86 processors and has been ported to
S/390,[5] PowerPC,[6] and IA-64. An ARM port was merged during the
3.9 kernel merge window.[7]"

It's not really what I'm hoping for (I may not get what I'm hoping
for).

A bootcamp-style session on KVM and VMS might well fit what I'm
hoping for. A Digital Technical Journal-style article or two might
well fit what I'm hoping for. Neither of those exist at the moment,
so is there anything along those lines that isn't specifically
focused on KVM in a UNIX-like kernel environment? I've been 
following KVM occasionally for ages and I've no recollection of
seeing anything fitting that description. Those closer to the 
subject may have pointers, or may know that such info does not
yet exist.

Re open source compilers: not sure it's been mentioned here, but
apart from any differences in technical capability between LLVM
and (let's be blunt) gcc, the licences are noticably different.

Even in the world of open source licensing, one size does not fit all.