[Info-vax] VMS process communication

[Ian Miller]

On Wednesday, March 22, 2023 at 5:37:07 PM UTC, John Reagan wrote:
> On Wednesday, March 22, 2023 at 1:13:20 PM UTC-4, Ian Miller wrote: 
> > On Wednesday, March 22, 2023 at 2:50:17 PM UTC, Arne Vajhøj wrote: 
> > > On 3/22/2023 7:18 AM, Ian Miller wrote: 
> > > > On Tuesday, March 21, 2023 at 11:34:04 AM UTC, Arne Vajhøj wrote: 
> > > >> On 3/20/2023 5:37 AM, Andreas Gruhl wrote: 
> > > >>> Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1: 
> > > >>>> On 3/16/2023 5:05 AM, Andreas Gruhl wrote: 
> > > >>>>> Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31 
> > > >>>>> UTC+1: 
> > > >>>>>> On 3/10/2023 4:01 PM, Arne Vajhøj wrote: 
> > > >>>>>>> https://www.vajhoej.dk/arne/articles/vms64.html 
> > > >>>>>> 
> > > >>>>>> Updated to version 1.0 based on comments. 
> > > >>>>> Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change 
> > > >>>>> the compiler's treatment of pointers. Interpreting pointers 
> > > >>>>> as unsigned values has to be provided by the programmer. The 
> > > >>>>> qualifier only allows for P2 structures to be used as actual 
> > > >>>>> routine parameters via descriptor, which otherwise would be 
> > > >>>>> flagged as a compile time error. 
> > > >>>> So it does not change the treatment of pointers. 
> > > >>>> 
> > > >>>> It disables a compiler check. 
> > > >>> That's correct. 
> > > >> 
> > > >> I have updated. 
> > > > On VMS E9.2-1 x86-64 all code by default is put into P2 by the linker 
> > > > but you can put /SEGMENT=CODE=P0 to stop that. I suspect this is 
> > > > going to cause some issues when porting. For kernel mode code the 
> > > > recommendation is to change from locking specific parts of the code 
> > > > into the working set to locking the whole image as this works on I64 
> > > > and x86 VMS by calling LIB$LOCK_IMAGE. 
> > > So is a function pointer always 64 bit? 
> > > 
> > > Arne 
> > from the release notes "The LINKER creates small stub routines in 32-bit P0 space to allow the address of a routine to be stored in a 32-bit variable."
> For the most part, few people have noticed that the code now resides in 64-bit space. The linker-created trampolines hide the details. The trampoline IS the routine's address. Shareable image symbol-vectors feel more like VAX these days since they also are an array of trampolines. 
> 
> What I've seen more is VAX-era code (mostly Macro-32 and BLISS) that goes out of the way to place readonly data into the $CODE$ PSECT or mark $PLIT$/$LITERAL$/etc as EXE. On VAX, getting those literals near the code can result in byte or word-relative addressing modes which might save a few bytes. On Alpha or Itanium, having that data near the code didn't do anything (perhaps a little benefit for locality or reducing image segment counts?). On x86, marking those PSECTs as EXE moves that static data into 64-bit space as well. There are no "trampolines" to help so you can't take their 32-bit address for things like descriptors, item lists, etc. You get strange looking ACCVIOs from using just 32-bits of a larger than 32-bit address. Again, this is 99% a Macro-32 and BLISS technique to save a byte on VAX. Code written in C, C++, Fortran, etc. does the right thing by letting the compiler figure it out. And people who modify PSECT attributes in linker options files can shoot themselves in the foot (I just fixed one of those yesterday!) 
> 
> And you can move code into P2 space on Itanium too but it isn't the default. That linker has /SEGMENT=CODE=P2 if you want to try it (doesn't work well with C++ however). 
> 
> The benefit of moving code out of P0 space is to free up more 32-bit heap, etc. 
> 
> It has been this way with x86 since day-1. Our original design model was to put code in P2 space (and likewise more of the OS is now in S2 space) 
> 
> John

I've only noticed when porting some MACRO32 ;-)