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

[johnwallace4 at yahoo.co.uk]

On Friday, 5 June 2015 16:05:00 UTC+1, Jan-Erik Soderholm  wrote:
> johnwallace4 at yahoo.co.uk skrev den 2015-06-05 16:27:
> > 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...
> 
> And so what?
> The KVM has to (if it isn't "bare metal") run on top of *someting*.
> 
> I think you are mixing up host/guest OS here.
> It's at the guest level that VMS comes into play.
> 
> Or are you saying that KVM should run on top of VMS?
> That is, having VMS as *both* host and client OS?
> 
> As I have understood, VSI is only targeting KVM with VMS
> as a guest OS, not to port KVM to VMS hosts in itself...
> 
> Jan-Erik.
> 
> 
> 
>   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.
> >

I assume you're right, Linux host with VMS as a KVM guest. But
generally I don't like assuming.

Clair knows, but has other things to think about right now. Doesn't
matter for this stuff, it isn't time critical.

Hence the boot camp question, where there is time to explain in a
bit more depth (and time to prepare the explanation).