[Info-vax] Update Kit for OpenVMS 9.1 released today

[^P]

On Monday, August 23, 2021 at 2:00:45 AM UTC+2, xyzz... at gmail.com wrote:
> On Sunday, August 22, 2021 at 10:12:42 AM UTC-4, ^P wrote: 
> > On Sunday, August 22, 2021 at 3:45:07 PM UTC+2, Mark Daniel wrote: 
> > > On 22/8/21 10:37 pm, Craig A. Berry wrote: 
> > > > 
> > > > On 8/22/21 7:24 AM, ^P wrote: 
> > > >> 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. 
> > > >> 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 
> > > 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. https://www.youtube.com/watch?v=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!