[Info-vax] The future of Ada on VMS

[gérard Calliet]

Le 24/05/2018 à 20:17, johnwallace4 at yahoo.co.uk a écrit :
> On Thursday, 24 May 2018 14:46:01 UTC+1, gérard Calliet  wrote:
>>>
>>> Your effort so far in building the Open source GNAT ADA compiler on OpenVMS appears to me to be the option that has made the most progress so it seems strange that VSI won't pursue this.
>>>
>> The best summary I read.
>>
>> I think VSI has a lot of difficulties dealing with the Open Source
>> strategies.
>>
>> Understandable in a culture of "everything is under control" (which is
>> good).
>>
>> But they don't understand that the survival of VMS depends sometimes on
>> best effort strategies, and that Open Source could be a very good
>> solution in specific cases, if the limits are known.
>>
>> They have to be more relax, and more opened to all efforts in the
>> community. The way they manage Open Source projects on which they are
>> doing (often very good) work is also problematic : not very opened, not
>> very integrated in the Open Sources communities. And I think there is
>> there also a cultural issue.
>>
>> About Ada, yes we hope we'll make other progresses, and perhaps VSI will
>> understand we are more relax than they imagine about collaboration:
>> sometimes, a little (mutual) help is worth it, without necessecity of
>> stone contracts.
>>
>> Gérard Calliet
>>
>> ---
>> L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
>> https://www.avast.com/antivirus
> 
> Gerard, with greatest respect, I still don't
> understand exactly who is expecting to provide
> what facilities to who in the picture you
> described, let alone what (if any) commercial
> implications might be involved.
I do appreciate your humbleness :) I'll try to explain.
> 
> Is there a different description somewhere else,
> perhaps with some background information on
> why VSI might expect this to be financially
> significant enough for them to devote resources
> to it? (Why does it have to be VSI?)
At different bootcamps, VSI presented its strategy about compilers when 
they'll go to x86.
Summary :
- everything is possible for the traditional langages (C, Cobol, 
Pascal...) using GEM on front, LLVM on back, making GEM able to speak 
with LLVM,
- we have special things for C++ because it was intel C++ for Itanium, 
we can do,
- for Ada we don't know, because, at the time of Itanium port, HP gave 
up and transmitted to Adacore.
The situation became worse when Adacore (about in the 2015 year, VSI 
experience began in 2014) stopped its support of Ada on Itanium. And, 
anyway, gnat Ada is gcc and gcc upon llvm is very difficult to imagine 
(there are some projects).
In summary, it is a pure question about compilers set for the  VMS 
portfolio. We have PAscal, Cobol,... but we don't have Ada. Perhaps, in 
our days with hundreds of new langages a year, it is not a big issue.
On Alpha, customers use DEC Ada. Problems are there when they are 
porting from Alpha to Itanium (my customer).
> 
> I have spent several decades on and off working
> with people doing variants on this kind of
> thing, developing on VMS and elsewhere,
> targeting VMS and elsewhere, targeting DEC and
> non-DEC kit, some using 'pure Ada' for design
> reasons and some using Ada as an 'intermediate
> language' because it's what's in the contract.
>   
Unerstood. For example, my customer was using:
- Alsys Ada on Vax to cross-compile to embedded,
- Dec Ada on Vax to have a simulator on the Vax of the cross-compiled code,
- Dec Ada on Alpha in the application for the center coordinating the 
emmbedded.
> I don't get out much these days, but questions
> that might help me (and/or VSI) understand the
> vision might include:
> 
> Where (e.g. what OS) do the Ada developers sit?
> On VMS, on a Linux box, on a Window box?
All development and source control are on VMS cluster (VAX, ALpha, and 
now Itanium)
> 
> Where does the application run? On VMS? On
> 'bare metal' ? Some other environment?
Alsys and Dec Ada VAX on embedded and on VAX
Central application on VMS (Alpha, and now Itanium)
> 
> What does the Ada source code look like?
> Is it user coded from scratch or is it
> autogenerated by a higher level tool, e.g.
> some kind of "Model Based Systems Engineering"
> tool which uses Ada output as a contractual
> obligation rather than another important part
> of the design verification chain.
Everything coded from scrach in the 90s
> 
> Is it pure Ada? Pure Ada plus calls to
> libraries (and if so, which)? Pure Ada plus
> libraries with system services (and if so,
> which target OS, and which particular
> services)?
Pure Ada for Alsys or DEC Ada VAX
Big usage of VMS system services for the "control environment" coded on 
DEC Ada on Alpha. It is this part we ported to Itanium, using our Gnat 
Ada compiler. (The other applications run on emulated VAX running on 
Itanium).
> 
> Without knowing those answers, it's hard
> to understand what will be required.
> 
> Regardless of those answers...
> I've also spent an embarrassing amount of time
> working with, maintaining (and occasionally
> rewriting) software test and validation tools
> and runtime environments for safety critical
> code and such, with object+debug formats from
> COFF/STABS in the 1980s through to ELF/DWARF
> more recently, and various instruction sets
> and runtimes too. Most recently, when I was
> trying to work with DWARF output from gnat,
> DWARF itself was a bit of a challenge, but any
> non-trivial use with output of Ada compilations
> seemed to require far too much knowledge of
> obscure gnat internals (e.g. use of 'proprietary'
> name-mangling conventions instead of facilities
> defined in the DWARF V3 standard). Maybe that's
> changed.
You are right, it is the challenge. I'm just at the beginning. My 
customer has somehow trivial data, and I hope I'll be able to help him. 
Recent versions of gnat gcc, perhaps, do better dwarf, and, perhaps, 
I'll try some sort of back-port to our gcc.
> 
> Basically, there's a lot of work here. Most
> of it isn't really related to 'open source'
> or even to VSIVMS's (lack of) standards
> compliance (e.g. POSIX).
Right. And i'm just doing things on an "old" Gnat Ada on gcc. It'll be a 
total different task to be able to work with llvm on VMS x86.
> 
> How much of it needs to be done ASAP to
> keep VMS in this picture? Which parts
> of the picture need VMS and/or VSI
> involvement? How much can other folks
> deliver with advice from experts elsewhere?
My opinion is: there are some (I don't know any figure) customers using 
Ada on VMS on very important applications who either are stuck on Alpha, 
because they use DEC Ada on Alpha, or have not any support for Ada on 
Itanium. To get these customers staying in VMS, my work could help. Or 
could have help: it seems because we didn't do anything on that the last 
4 years, these abandonate customers have already give up from VMS 
(Adacore said me that two months ago ; are they trustable, do they know 
things on Alpha segment ? Impossible to know).
My proposal is very simple: a one by one solution.You have a specific 
problem, we study it and propose a specific support, if we can, and what 
we can. Getting one by one support, I can survive and make grow my 
support perimeter, invest in funny things like VMS Debug for Ada, and 
the customers I help on Ada stay on VMS. The contrary of a superb 
universal solution.
I nether thought creating a new complete product, reselled by VSI. But I 
was thinking VSI could have help declaring its interest, speaking about 
us, collaborating with their knowledge (they have a pcsi Gnat Ada Pro, 
obtained before 2015), dreaming together on Ada future on VMS. No way. 
It is only about this total non openess I think they have a problem 
cooperating with survivor initiatives. And when a lot of barks are 
sinking, sometimes the flagship can become ill (pure opinion :) ).
> 
> Most of those questions are backward-facing.
> Some of the answers might be different five
> years from now. The costs and timescales
> and commercial implications of anything
> which results will depend on who 'owns'
> the various pieces of whatever the end
> product turns out to be.
Nobody knows.
> 
> 
> Predictions are hard at the best of times.
> 
> 
> 
> Further enlightenment very welcome.
I did my best, thank you for the questions.
>