Discussion:
Update Kit for OpenVMS 9.1 released today
Add Reply
John Dallman
2021-08-20 16:59:00 UTC
Reply
Permalink
https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf

15 total fixes, if I understand the documentation correctly. Packaged as
a PCSI kit, but cannot be removed once installed.

John
Jan-Erik Söderholm
2021-08-20 21:51:04 UTC
Reply
Permalink
Post by John Dallman
https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
15 total fixes, if I understand the documentation correctly. Packaged as
a PCSI kit, but cannot be removed once installed.
John
It doesn't say, but this is not the 9.1A kit announced for August?
It doesn't look like that, more of an UPDATE-2 kit for V9.1.
Robert A. Brooks
2021-08-20 22:27:40 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by John Dallman
https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
15 total fixes, if I understand the documentation correctly. Packaged as
a PCSI kit, but cannot be removed once installed.
John
It doesn't say, but this is not the 9.1A kit announced for August?
It doesn't look like that, more of an UPDATE-2 kit for V9.1.
This is NOT V9.1-A; that will be in late September.
--
-- Rob
Marc Van Dyck
2021-08-21 10:34:50 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by Jan-Erik Söderholm
Post by John Dallman
https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
15 total fixes, if I understand the documentation correctly. Packaged as
a PCSI kit, but cannot be removed once installed.
John
It doesn't say, but this is not the 9.1A kit announced for August?
It doesn't look like that, more of an UPDATE-2 kit for V9.1.
This is NOT V9.1-A; that will be in late September.
Is this the one that will be an ISO image instead of an appliance ?
--
Marc Van Dyck
Clair Grant
2021-08-21 18:18:46 UTC
Reply
Permalink
Post by Marc Van Dyck
Post by Robert A. Brooks
Post by Jan-Erik Söderholm
Post by John Dallman
https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
15 total fixes, if I understand the documentation correctly. Packaged as
a PCSI kit, but cannot be removed once installed.
John
It doesn't say, but this is not the 9.1A kit announced for August?
It doesn't look like that, more of an UPDATE-2 kit for V9.1.
This is NOT V9.1-A; that will be in late September.
Is this the one that will be an ISO image instead of an appliance ?
--
Marc Van Dyck
V9.1 is a standard VMS ISO installation kit. Updates 1 and 2 are PCSI patch kits. V9.1-A will be an ISO installation kit. We stopped providing appliances as of the last V9.0 EAK.

Clair
^P
2021-08-22 12:24:16 UTC
Reply
Permalink
Post by Clair Grant
Post by Marc Van Dyck
Post by Robert A. Brooks
Post by Jan-Erik Söderholm
Post by John Dallman
https://vmssoftware.com/docs/VSI-X86VMS-V91_UPD-V0200.pdf
15 total fixes, if I understand the documentation correctly. Packaged as
a PCSI kit, but cannot be removed once installed.
John
It doesn't say, but this is not the 9.1A kit announced for August?
It doesn't look like that, more of an UPDATE-2 kit for V9.1.
This is NOT V9.1-A; that will be in late September.
Is this the one that will be an ISO image instead of an appliance ?
--
Marc Van Dyck
V9.1 is a standard VMS ISO installation kit. Updates 1 and 2 are PCSI patch kits. V9.1-A will be an ISO installation kit. We stopped providing appliances as of the last V9.0 EAK.
Clair
Is there any defined date when x86 version of VMS can be available to non-customer i.e hobbyist or similar?

In the meantime, can someone please provide a VMS x86 binary for analysis?

Regards, Peter
Craig A. Berry
2021-08-22 13:07:47 UTC
Reply
Permalink
Post by ^P
Is there any defined date when x86 version of VMS can be available to
non-customer i.e hobbyist or similar?
All of the field test docs refer only to "customers" so my unofficial
guess would be that the v9.2 production release is the earliest that's
likely to be available under the community license. You can read the
roadmap yourself for when that's scheduled to happen.
Post by ^P
In the meantime, can someone please provide a VMS x86 binary for analysis?
Not legally, no.
^P
2021-08-22 13:18:32 UTC
Reply
Permalink
Post by Craig A. Berry
Post by ^P
Is there any defined date when x86 version of VMS can be available to
non-customer i.e hobbyist or similar?
All of the field test docs refer only to "customers" so my unofficial
guess would be that the v9.2 production release is the earliest that's
likely to be available under the community license. You can read the
roadmap yourself for when that's scheduled to happen.
Post by ^P
In the meantime, can someone please provide a VMS x86 binary for analysis?
Not legally, no.
I already read the roadmap, nothing mentions the availability by "community license", why I asked openly

Thought so

Regards, Peter
Mark Daniel
2021-08-22 13:45:03 UTC
Reply
Permalink
Post by Craig A. Berry
Post by ^P
Is there any defined date when x86 version of VMS can be available to
non-customer i.e hobbyist or similar?
All of the field test docs refer only to "customers" so my unofficial
guess would be that the v9.2 production release is the earliest that's
likely to be available under the community license.  You can read the
roadmap yourself for when that's scheduled to happen.
Post by ^P
In the meantime, can someone please provide a VMS x86 binary for analysis?
Not legally, no.
Binaries are provided all the time, e.g. freeware ...

https://www.theberrymans.com

How is x86-64 any different?

https://wasd.vsm.com.au/wasd_tmp/

Usual disclaimers apply.
--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.
^P
2021-08-22 14:12:40 UTC
Reply
Permalink
Post by Mark Daniel
Post by Craig A. Berry
Post by ^P
Is there any defined date when x86 version of VMS can be available to
non-customer i.e hobbyist or similar?
All of the field test docs refer only to "customers" so my unofficial
guess would be that the v9.2 production release is the earliest that's
likely to be available under the community license. You can read the
roadmap yourself for when that's scheduled to happen.
Post by ^P
In the meantime, can someone please provide a VMS x86 binary for analysis?
Not legally, no.
Binaries are provided all the time, e.g. freeware ...
https://www.theberrymans.com
How is x86-64 any different?
https://wasd.vsm.com.au/wasd_tmp/
Usual disclaimers apply.
--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.
Many thanks you for the links, I haven't seen any x86 freeware until now
Post by Mark Daniel
How is x86-64 any different?
This is the question I want to know the answer to.

If anyone happen to know any freeware binary/executable that uses MMX, SSE, AVX instructions, please let me know.

Regards., Peter
John Reagan
2021-08-23 00:00:43 UTC
Reply
Permalink
Post by ^P
Post by Mark Daniel
Post by Craig A. Berry
Post by ^P
Is there any defined date when x86 version of VMS can be available to
non-customer i.e hobbyist or similar?
All of the field test docs refer only to "customers" so my unofficial
guess would be that the v9.2 production release is the earliest that's
likely to be available under the community license. You can read the
roadmap yourself for when that's scheduled to happen.
Post by ^P
In the meantime, can someone please provide a VMS x86 binary for analysis?
Not legally, no.
Binaries are provided all the time, e.g. freeware ...
https://www.theberrymans.com
How is x86-64 any different?
https://wasd.vsm.com.au/wasd_tmp/
Usual disclaimers apply.
--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.
Many thanks you for the links, I haven't seen any x86 freeware until now
Post by Mark Daniel
How is x86-64 any different?
This is the question I want to know the answer to.
If anyone happen to know any freeware binary/executable that uses MMX, SSE, AVX instructions, please let me know.
Regards., Peter
We use the base AMD64 calling convention

call->setCallingConv(CallingConv::X86_64_SysV);

In LLVM-speak.

On top of that, we use the AH register for an arg-count. Only AL is used in the base calling convention so our use of AH should be upward compatible.

Our memory model is a blend. It isn't exactly "short", "medium", or "large". Since we have static data and stacks in 32-bit space but code in 64-bit space, we access all static data through the GOT (which is more than what "medium" would suggest). And since routines in the same module might be in PSECTs that are far apart, we always go through the GOT for that as well. Same with literal pools (we move them into the code psect since our linker doesn't do SHT_MERGE).

But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).

I gave a presentation at an LLVM conference a few years back.


We only support PIC, use sse2.1 and higher for floating.

If you have questions, ask.
Joukj
2021-08-23 10:39:14 UTC
Reply
Permalink
Post by John Reagan
But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what
happens if you compile a fork implementation on linux and link it on
OpenVMS?

Jouk
John Reagan
2021-08-24 11:51:08 UTC
Reply
Permalink
Post by Joukj
Post by John Reagan
But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what
happens if you compile a fork implementation on linux and link it on
OpenVMS?
Jouk
A compiler on Linux sees a call to an external routine named "fork". It is placed in the ELF symbol table as an external name. Bring it to OpenVMS and the linker looks for a routine named "fork". It won't find it. You'll get an error message. Feel free to write you own routine named "fork".

The more interesting cases are CRTL names. On Linux, call "printf". The external name in the ELF symbol table is "printf". We don't have just a "printf" on OpenVMS, We prefix the names and have multiple versions due to all the different floating types. You'll see things like DECC$TXPRINTF. The C/C++ frontends on OpenVMS do that name mapping for you. The Linux compilers don't know about it. You either need lots of funky #define's, shim routines, or actually put some name mapping into the Linux compiler (we added crude name mapping).

You also have to watch what headers you use. The default set of Linux headers might allow certain names to be declared and used but those features might not be on OpenVMS. Our bootstrapping used a mixture of OpenVMS headers and Linux headers.

Going the other way, you just tell the C compiler not to prefix anything. We've compiled several files using the Itanium-hosted/x86-target C compiler (with no prefixing) and moved that .obj file to Linux to link and execute.
^P
2021-08-24 12:13:10 UTC
Reply
Permalink
Post by Joukj
Post by John Reagan
But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what
happens if you compile a fork implementation on linux and link it on
OpenVMS?
Jouk
A compiler on Linux sees a call to an external routine named "fork". It is placed in the ELF symbol table as an external name. Bring it to OpenVMS and the linker looks for a routine named "fork". It won't find it. You'll get an error message. Feel free to write you own routine named "fork".
The more interesting cases are CRTL names. On Linux, call "printf". The external name in the ELF symbol table is "printf". We don't have just a "printf" on OpenVMS, We prefix the names and have multiple versions due to all the different floating types. You'll see things like DECC$TXPRINTF. The C/C++ frontends on OpenVMS do that name mapping for you. The Linux compilers don't know about it. You either need lots of funky #define's, shim routines, or actually put some name mapping into the Linux compiler (we added crude name mapping).
You also have to watch what headers you use. The default set of Linux headers might allow certain names to be declared and used but those features might not be on OpenVMS. Our bootstrapping used a mixture of OpenVMS headers and Linux headers.
Going the other way, you just tell the C compiler not to prefix anything. We've compiled several files using the Itanium-hosted/x86-target C compiler (with no prefixing) and moved that .obj file to Linux to link and execute.
It is still default capitals?
Else using /name=as_is
John Reagan
2021-08-24 14:37:08 UTC
Reply
Permalink
Post by ^P
Post by Joukj
Post by John Reagan
But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
Sound interesting and easy, but I suspect a lot of pitfalls: i.e. what
happens if you compile a fork implementation on linux and link it on
OpenVMS?
Jouk
A compiler on Linux sees a call to an external routine named "fork". It is placed in the ELF symbol table as an external name. Bring it to OpenVMS and the linker looks for a routine named "fork". It won't find it. You'll get an error message. Feel free to write you own routine named "fork".
The more interesting cases are CRTL names. On Linux, call "printf". The external name in the ELF symbol table is "printf". We don't have just a "printf" on OpenVMS, We prefix the names and have multiple versions due to all the different floating types. You'll see things like DECC$TXPRINTF. The C/C++ frontends on OpenVMS do that name mapping for you. The Linux compilers don't know about it. You either need lots of funky #define's, shim routines, or actually put some name mapping into the Linux compiler (we added crude name mapping).
You also have to watch what headers you use. The default set of Linux headers might allow certain names to be declared and used but those features might not be on OpenVMS. Our bootstrapping used a mixture of OpenVMS headers and Linux headers.
Going the other way, you just tell the C compiler not to prefix anything. We've compiled several files using the Itanium-hosted/x86-target C compiler (with no prefixing) and moved that .obj file to Linux to link and execute.
It is still default capitals?
Else using /name=as_is
Yes, you would use /names=as_is to keep "print" as "print".

^P
2021-08-24 10:48:14 UTC
Reply
Permalink
Post by John Reagan
Post by ^P
Post by Mark Daniel
Post by Craig A. Berry
Post by ^P
Is there any defined date when x86 version of VMS can be available to
non-customer i.e hobbyist or similar?
All of the field test docs refer only to "customers" so my unofficial
guess would be that the v9.2 production release is the earliest that's
likely to be available under the community license. You can read the
roadmap yourself for when that's scheduled to happen.
Post by ^P
In the meantime, can someone please provide a VMS x86 binary for analysis?
Not legally, no.
Binaries are provided all the time, e.g. freeware ...
https://www.theberrymans.com
How is x86-64 any different?
https://wasd.vsm.com.au/wasd_tmp/
Usual disclaimers apply.
--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.
Many thanks you for the links, I haven't seen any x86 freeware until now
Post by Mark Daniel
How is x86-64 any different?
This is the question I want to know the answer to.
If anyone happen to know any freeware binary/executable that uses MMX, SSE, AVX instructions, please let me know.
Regards., Peter
We use the base AMD64 calling convention
call->setCallingConv(CallingConv::X86_64_SysV);
In LLVM-speak.
On top of that, we use the AH register for an arg-count. Only AL is used in the base calling convention so our use of AH should be upward compatible.
Our memory model is a blend. It isn't exactly "short", "medium", or "large". Since we have static data and stacks in 32-bit space but code in 64-bit space, we access all static data through the GOT (which is more than what "medium" would suggest). And since routines in the same module might be in PSECTs that are far apart, we always go through the GOT for that as well. Same with literal pools (we move them into the code psect since our linker doesn't do SHT_MERGE).
But in general, you can move things back and forth easily. You can take OpenVMS-created objects and link/execute them on Linux. The other way works as well (that is how we bootstrapped a recent clang/LLVM to OpenVMS x86).
I gave a presentation at an LLVM conference a few years back. http://youtu.be/fiZwCLbJNSI
We only support PIC, use sse2.1 and higher for floating.
If you have questions, ask.
Thank you for a very detailed answer, I've found a few more executables to study until I can generate my own, I've ported a few things to VMS on VAX, Alpha and I64 earlier and plan to do so also for x86_64, reason for my interest, always study the result, to understand the content.
We've actually met, I visited Nashua in 2007 with Anders J who was at Bugcheck at the time, I think.
I did a week of crash dump analysis with Rob Eulenstein
What days it were!
Craig A. Berry
2021-08-22 15:42:41 UTC
Reply
Permalink
Post by Mark Daniel
Post by Craig A. Berry
Post by ^P
In the meantime, can someone please provide a VMS x86 binary for analysis?
Not legally, no.
Binaries are provided all the time, e.g. freeware ...
https://www.theberrymans.com
How is x86-64 any different?
He asked for a VMS binary, which I took to mean a binary kit for the
operating system. If he just means any piece of software compiled for
VMS x86-64, then of course that's up to whoever builds the binary.
What's available now wouldn't be terribly informative for analysis
purposes, though, since it would be built with a cross-compiler having
all optimizations turned off using an older version of LLVM that will be
superseded in the process of producing the native compilers.
Loading...