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

[Jan-Erik Soderholm]

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.
>