[Info-vax] VMS and the embedded world, was: Re: PowerX Roadmap - Extended beyond 2020

[Simon Clubley]

On 2016-09-17, Chris <xxx.syseng.yyy at gfsys.co.uk> wrote:
> On 09/17/16 02:57, David Froble wrote:
>
>> But, it's not going to happen because of business reasons, not technical
>> reasons.
>
> No, for good technical reasons as well. At minimum, any os that could 
> compete in the embedded space needs a hardware abstraction layer or
> similar for portability reasons, whereas VMS has always been closely
> tied to and uses specific features of the underlying processor
> architecture. There are dozens of different embedded cpu architectures,
> each with their own quirks and requirements, modes of operation and more.
>

If the above argument (and my own arguments) are not enough to
convince David, then he should consider one other thing:

VSI was setup in the middle of 2014. Their early release version
of x86-64 VMS is currently scheduled for 2018. Even if that's
January 2018, then that's still 3.5 years and that is a hideously
long time for a port to a new architecture by today's standards.

This shows how utterly non-portable the VMS code base is by today's
standards and how, amongst other things, there is way too much deep
architecture knowledge embedded within all layers of VMS instead of
being abstracted out into a cleanly seperate layer. If this were
Linux (for example) or another OS written with portability in mind,
you would have had something in the hands of the customers way
before now.

I want to make it very clear that this is merely an observation and
is absolutely NOT a criticism of the original design of VAX/VMS.
At the time, the deeply embedded knowledge of the VAX architecture
in VAX/VMS was rightly seen as an advantage in those days. However,
times change (and so do architectures) and those same good at the
time original design decisions are now having a major negative
impact on the time it's taking to port VMS to x86-64.

Don't get me wrong, VSI appear to be doing a good job with the code
base that they are forced to work with but at the same time it also
shows how completely and utterly unsuitable VMS is for today's
embedded world where both portability across different architectures
and the ability to run on a custom designed board with a customer
supplied BSP is absolutely critical.

VMS simply isn't cut out for the BSP based embedded OS model and any
version of VMS which did match that model would effectively be a
rewrite of VMS based around modern OS abstraction concepts with
any assembly language interaction with VMS thrown down into the
architecture specific part of VMS only and which would not be a
factor in how a rewritten VMS's user level APIs would be designed.

(This does not mean object orientated BTW. This merely means, among
with various other things, portable data types being used in customer
code which is written to interact with those VMS user level APIs).

> VMS is a very good general purpose OS designed for data center
> applications. Not optimised for speed, small footprint, power
> efficiency, nor memory requirements, the exact opposite of those
> for for most embedded work. Not to mention that there are already
> dozens of real time os's specifically designed for embedded work,
> many with a long and successful track record.
>

I also agree with all that as well.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world