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

[Simon Clubley]

On 2016-10-24, clairgrant71 at gmail.com <clairgrant71 at gmail.com> wrote:
> On Saturday, September 17, 2016 at 6:41:13 PM UTC-4, Simon Clubley wrote:
>> On 2016-09-17, Chris <xxx.syseng.yyy at gfsys.co.uk> wrote:
>> > On 09/17/16 02:57, David Froble wrote:
>> >
>> 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.
>>
>
> Yes, that is a long time. When VSI was announced we had 6 employees,
> no code, and no customers.  We have spent these two years putting
> together an engineering team and figuring out how to become a viable
> business, both of which are still works in progress but we are finally
> starting to gain a little momentum. If we had started with the
> appropriate number of people and no other work to do, we would be
> running on x86 today, maybe not ready for final release but certainly
> well into it.
>

Just to make it clear that thread was in the context of embedded
operating systems where portability is held to be _very_ important
indeed and is even more important than normal operating systems
written in C.

The context for my comments was to show, as a simple statement of
fact, how unsuitable VMS is for the embedded world. Reading the
rest of my response puts my comments into context.

>> 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.
>> 
>
> This was all true years ago but after porting to Alpha and
> especially to Itanium, architecture-specific knowledge is in very few
> places and extremely little of the OS is aware of architecture and
> that is centralized. At this point it is not so much the design of VMS
> that makes it time consuming to port, it is the fact that it was
> written in VAX assembler and BLISS and uses the GEM code
> generator. (Yes, we have explored converting to C three times and
> rejected that approach each time). Moving to ELF for Itanium has
> eliminated a lot of work this time and in the future and moving to
> LLVM this time will eliminate even more work in the future.
>

I see thanks and I stand corrected then.

So it's much less the architecture specific knowledge this time
around and much more the implementation languages which is making
it a several year project.

> Porting VMS is a huge job but we are making it easier each
> time. Will it ever be like porting a portable OS written in C? No,
> absolutely not, but it is a lot more "turn the crank" than you might
> think.
>

That's quite understandable. As I said in my original response, what
I perceive this as is the difference between an operating system
designed in the 1970s and which needed to work in that era versus
operating systems designed today and that's simply how it is.

> No excuses; it takes a long time. It is difficult but it is so much
> better than it was in 1989 when we had little idea what we were
> getting into.
>

:-)

Simon.

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