On Wednesday, May 18, 2022 at 4:28:23 AM UTC-4, hb wrote:
> On x86, by default the linker puts code into P2; on request the linker
> can move code into P0. On x86 the function pointer is a code address of
> a single code instruction, which uses a 64 bit address to jump to the
> "real" code. The linker creates this code instruction. On IA64, by
> default the linker puts code into P0; on request, the linker can move
> code into P2. On IA64 the function pointer is the address of a data
> structure, a Function Descriptor (FD), which contains a 64 bit address
> of the "real" code. The linker creates the FD.

My C code often assumes auto storage class variables (i.e. the stack) are in
32-bit space, but I don't recall seeing that explicitly documented anywhere. I
define a macro, RMS_MALLOC, as an alias for _malloc32 since RMS structs
are the main thing I deal with plagued with 32-bit pointers.

On Wednesday, May 18, 2022 at 5:20:22 AM UTC-4, hb wrote:
> On 5/18/22 00:05, Craig A. Berry wrote:
> > ...
> > Or you've got a LIB$INITIALIZE routine to set the DECC$ features at
> > start-up time; I may not be explaining this right but I think that
> > routine has to be referenced by a 32-bit pointer because that's where
> > the image activator will look for it.
> The image activator doesn't care about the pointer size. Only for
> shareable images, the image activator calls the code in the
> LIB$INITIALIZE module, which was (by request) linked into the shareable.
> Its entry point was written by the linker and that's what the image
> activator is looking for. The code in LIB$INITIALIZE expects an array of
> 32-bit pointers in the LIB$INITIALIZE PSECTs. They are function pointers
> which are always 32 bit. This array is set up by the developer and
> filled with the pointers. If the source module for setting this up was
> compiled with 64 bit pointers, an array of pointers has 64 bit entries.
> With the function pointers being 32 bits, the array from
> LIB$INITIALIZE's point of view contains zero pointers. For the
> LIB$INITIALIZE code a zero pointer is the end of the list. With 64-bit
> pointers, that stops you from having more than one init routine called
> "from the image activator". When the image activation is done, the main
> image is started with SYS$IMGSTA, which calls the code in the
> LIB$INITIALIZE module, ...
>
> That also explains, why you can debug init code of a main image, but you
> can't debug the init code of a shareable image (other than you run it as
> a main image).
>
> Some people may think SYS$IMGSTA (or even LIB$INITIALIZE) is part of the
> image activator. From my point of view, it is not.
>
> This all applies to the traditional VMS image initialization with the
> LIB$INITIALIZE PSECTs. On x86 the ELF .init_array sections are
> supported. They contain 64-bit pointers.
>
> FWIW, the linker on/for x86 was enhanced to include the LIB$INITIALIZE
> module from STARLET.OLB, whenever it encounters a LIB$INITIALIZE PSECT
> or .init_array section.

One small comment on hb's perfect response. The addition of .init_array support
on x86 is there only to be used by C++ code. The normal OpenVMS mechanism is the
array of 32-bit pointers in LIB$INITIALIZE.

And while hb doesn't consider IMG$IMGSTA as part of the "image activator", I would
say that most people do. It is part of the OS that "loads and starts" a program.

On Wednesday, May 18, 2022 at 7:59:58 AM UTC-4, osuv...@gmail.com wrote:
> On Wednesday, May 18, 2022 at 4:28:23 AM UTC-4, hb wrote:
> > On x86, by default the linker puts code into P2; on request the linker
> > can move code into P0. On x86 the function pointer is a code address of
> > a single code instruction, which uses a 64 bit address to jump to the
> > "real" code. The linker creates this code instruction. On IA64, by
> > default the linker puts code into P0; on request, the linker can move
> > code into P2. On IA64 the function pointer is the address of a data
> > structure, a Function Descriptor (FD), which contains a 64 bit address
> > of the "real" code. The linker creates the FD.
> My C code often assumes auto storage class variables (i.e. the stack) are in
> 32-bit space, but I don't recall seeing that explicitly documented anywhere. I
> define a macro, RMS_MALLOC, as an alias for _malloc32 since RMS structs
> are the main thing I deal with plagued with 32-bit pointers.
Yes, the stack is in 32-bit memory. The Calling Standard doesn't directly say
that but says the stack starts where the OS says. Since the addresses of
stack variables are used in descriptors, itemlists, RMS structs have 32-bit
pointers in them, the stack says in 32-bit space.

And yes, even a RAB64 has a mixture of 64-bit pointers and 32-bit pointers.
I've always been frustrated with that feature. A RAB64 should have been
fully extended to 64-bit pointers. Of course RAB64 is just the start of those
ugly data structures.

On 2022-05-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/17/2022 1:26 PM, Simon Clubley wrote:
>> This is utterly unlike anything you will be used to in Linux (for example),
>> where the size of the pointer is abstracted away from you as a C pointer
>> type. In VMS, due to the original assembly language nature of VMS, pointer
>> sizes are directly visible in the source code.
>
> Some compatibility decisions was made 3 decades ago that has long
> lasting impact.
>
> That the usage of Macro-32 for applications was a major reason
> is something you have claimed many times. But there are no
> proofs that was more important than the other potential reasons,
> so it is speculation.
>

So why do you think that VMS APIs continued to have the size of pointers
directly visible in data structures instead of being hidden behind
a HLL pointer data type whose size could be changed on demand with
compiler options without any major source code changes required ?

Unix works in this way. Why couldn't VMS move to that model when moving
to a 64-bit architecture ?

It would have been a lot easier to do that instead of all the convoluted
stuff VMS ended up doing to support 32-bit pointers and data structures
in existing applications.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-17, Dave Froble <davef@tsoft-inc.com> wrote:
>
> I'm just wondering how many VMS uses actually need the 64 bit addressing? At
> least Basic, and perhaps other languages, were never modified to take advantage
> of 64 bit addressing.
>
> Sure, there can be some uses that have such a requirement. If it doesn't exist
> (VAX) then VMS cannot be used in such cases.
>
> But, for the most part, is this a serious issue, or, something to dispare over?
>

Yes, it's a serious issue.

There's a reason why everyone is moving from 32-bit to 64-bit processors
for anything outside of embedded type systems.

In fact, it's been an issue for decades with servers. The original PRISM
design flipped between being a 32-bit or 64-bit architecture so even back
in the late 1980s, this was already becoming an issue.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/18/2022 1:35 PM, Simon Clubley wrote:
> On 2022-05-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/17/2022 1:26 PM, Simon Clubley wrote:
>>> This is utterly unlike anything you will be used to in Linux (for example),
>>> where the size of the pointer is abstracted away from you as a C pointer
>>> type. In VMS, due to the original assembly language nature of VMS, pointer
>>> sizes are directly visible in the source code.
>>
>> Some compatibility decisions was made 3 decades ago that has long
>> lasting impact.
>>
>> That the usage of Macro-32 for applications was a major reason
>> is something you have claimed many times. But there are no
>> proofs that was more important than the other potential reasons,
>> so it is speculation.

Correct. And remember, some strictly 32 bit apps are supported, as per initial
planning. Perhaps addresses are extended. That's not part of an app, as far as
I can see.

> So why do you think that VMS APIs continued to have the size of pointers
> directly visible in data structures instead of being hidden behind
> a HLL pointer data type whose size could be changed on demand with
> compiler options without any major source code changes required ?

Because this is VMS, not Unix, and some jobs just might need the flexibility?

> Unix works in this way. Why couldn't VMS move to that model when moving
> to a 64-bit architecture ?

Because this is VMS, not snake oil Unix?

> It would have been a lot easier to do that instead of all the convoluted
> stuff VMS ended up doing to support 32-bit pointers and data structures
> in existing applications.

Tell me what you think would have happened if Alpha would not have run VAX
applications? Yeah, DEC died anyway, but it would have been a lot quicker.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/18/2022 1:51 PM, Simon Clubley wrote:
> On 2022-05-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> I'm just wondering how many VMS uses actually need the 64 bit addressing? At
>> least Basic, and perhaps other languages, were never modified to take advantage
>> of 64 bit addressing.
>>
>> Sure, there can be some uses that have such a requirement. If it doesn't exist
>> (VAX) then VMS cannot be used in such cases.
>>
>> But, for the most part, is this a serious issue, or, something to dispare over?
>>
>
> Yes, it's a serious issue.

Ok, then just what is the issue? Calling it "serious" doesn't define it.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-05-17, chris <chris-nospam@tridac.net> wrote:
>
> Disappointing, but still doesn't amswer the question. Namely, if the
> code is 32 bit, how does vms know where to put that in 64 bit space ?.
>
> The question is relevant, since code has to be loaded at an address,
> usually defined at link time, unless fully position independent code
> is used, which can be quite inefficient. Perhaps the run time libraries
> deal with the that, but not clear. Also, how do the P0, P1, S0, S1
> segments relate to that ?...
>

The loader has no knowledge of whether the image uses 32-bit pointers
or a mixture of 32-bit and 64-bit pointers. On VMS, that, and whether
the program calls 32-bit VMS APIs only or a mixture of 32-bit and 64-bit
APIs is purely an internal matter within the VMS executable image.

Every image, regardless of how it uses pointers internally, gets loaded
at the same point within the process address space by the loader.

On Alpha VMS, all VMS APIs are 32-bit only unless they were extended to
have a 64-bit version, which many of them (but not all of them) were.

You need to stop thinking of VMS 64-bit capable programs as being
something nice and clean like the way it works on other operating systems.

64-bit capable programs on VMS are an ugly compromise because VMS had
to deal with 32-bit backwards compatibility issues that other operating
systems simply don't have to worry about.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-18, Dave Froble <davef@tsoft-inc.com> wrote:
> On 5/18/2022 1:35 PM, Simon Clubley wrote:
>> So why do you think that VMS APIs continued to have the size of pointers
>> directly visible in data structures instead of being hidden behind
>> a HLL pointer data type whose size could be changed on demand with
>> compiler options without any major source code changes required ?
>
> Because this is VMS, not Unix, and some jobs just might need the flexibility?
>

So you admit the need to support Macro-32 applications was a requirement ? :-)

>> It would have been a lot easier to do that instead of all the convoluted
>> stuff VMS ended up doing to support 32-bit pointers and data structures
>> in existing applications.
>
> Tell me what you think would have happened if Alpha would not have run VAX
> applications? Yeah, DEC died anyway, but it would have been a lot quicker.
>

Alpha needed to run VAX applications, but because of how VMS was designed,
DEC had to make some very ugly design decisions for VMS on Alpha.

These are things that Unix systems mostly don't need to worry about.

About the only time you need to worry about such things on Unix is when
(for example) you are writing device drivers and the driver needs to use
bounce buffers because of hardware limitations.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-18, Dave Froble <davef@tsoft-inc.com> wrote:
> On 5/18/2022 1:51 PM, Simon Clubley wrote:
>> On 2022-05-17, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> I'm just wondering how many VMS uses actually need the 64 bit addressing? At
>>> least Basic, and perhaps other languages, were never modified to take advantage
>>> of 64 bit addressing.
>>>
>>> Sure, there can be some uses that have such a requirement. If it doesn't exist
>>> (VAX) then VMS cannot be used in such cases.
>>>
>>> But, for the most part, is this a serious issue, or, something to dispare over?
>>>
>>
>> Yes, it's a serious issue.
>
> Ok, then just what is the issue? Calling it "serious" doesn't define it.
>

Applications increasingly need access to the additional address space
that 64-bit processors gives them.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <62842f29$0$698$14726298@news.sunsite.dk>, arne@vajhoej.dk
(Arne Vajh�j) wrote:

> Many custom scientific applications (Fortran, Python).

Also many kinds of mathematical modellers, simulation systems and
graphics programs. They can be done as 32-bit programs, but they just
can't hold enough data in a 32-bit address space for big jobs.

> For custom business application (Cobol, Basic, Pascal,
> Java or in some cases C) there must still be a lot of applications
> that don't need it (as in "really don't need it" not just
> "can live without it").

Certainly are.

> And if/when VSI start courting ISV's not currently on VMS to
> support VMS, then the vast majority will expect good 64 bit
> support.

They will.

John

On 5/18/2022 12:25 AM, Dave Froble wrote:
> On 5/17/2022 7:26 PM, Arne Vajhøj wrote:
>> On 5/17/2022 6:51 PM, Dave Froble wrote:
>>> I'm just wondering how many VMS uses actually need the 64 bit
>>> addressing?  At
>>> least Basic, and perhaps other languages, were never modified to take
>>> advantage of 64 bit addressing.
>>>
>>> Sure, there can be some uses that have such a requirement.  If it
>>> doesn't
>>> exist (VAX) then VMS cannot be used in such cases.
>>>
>>> But, for the most part, is this a serious issue, or, something to
>>> dispare over?
>>
>> There is a reason why Alpha was made 64 bit and not 32 bit
>> those 3 decades ago.
>>
>> There are definitely application types that need 64 bit
>> capability.
>
> I just wonder what percentage of current VMS users need 64 bit addresses.
>
>> Databases are one case. And I believe that was the case
>> driving the Alpha decision all these years ago.
>>
>> There are other memory hungry application types.
>>
>> Some platform software: cache servers, Java EE application
>> servers, message queue servers etc..
>>
>> Many custom scientific applications (Fortran, Python).
>>
>> For custom business application (Cobol, Basic, Pascal,
>> Java or in some cases C) there must still be a lot of applications
>> that don't need it (as in "really don't need it" not just
>> "can live without it").
>>
>> But application tend to grow over time so more applications
>> will want to use the full 64 bit space as times goes by.
>>
>> And if/when VSI start courting ISV's not currently on VMS to
>> support VMS, then the vast majority will expect good 64 bit
>> support.
>
> Agreed, it's a "check box" item, better have it.

I obviously don't know what all VMS systems are used for.

:-)

But if I use my crystal ball and my best RNG and divide with
the current local temperature and multiply with the
date I see the following.

current VMS users:

20% use 64 bit capabilities in their code
60% use 64 bit capabilities either in their code or in dependencies

future new VMS users:

66% use 64 bit capabilities in their code
95% use 64 bit capabilities either in their code or in dependencies

Arne

On 2022-05-18 08:28:20 +0000, hb said:

> On 5/17/22 23:31, Stephen Hoffman wrote:
>> On 2022-05-17 21:00:39 +0000, Arne Vajhj said:
>> ...
>>> I thought they had started moving code up to P2.
>>
>> Code which is inaccessible to 32-bit addresses, so don't try to pass a
>> function pointer to that code.
>
> On x86 and IA64 function pointers are always 32 bit.
>
> On x86, by default the linker puts code into P2; on request the linker
> can move code into P0. On x86 the function pointer is a code address of
> a single code instruction, which uses a 64 bit address to jump to the
> "real" code. The linker creates this code instruction. On IA64, by
> default the linker puts code into P0; on request, the linker can move
> code into P2. On IA64 the function pointer is the address of a data
> structure, a Function Descriptor (FD), which contains a 64 bit address
> of the "real" code. The linker creates the FD.

Though AFAIK the user works with a 64-bit value for the function
pointer, and doesn't ever see the internal limitations nor the use of a
trampoline where that's needed.

I don't have an Itanium handy to test and E9.2 isn't playing nicely at
the moment, so here is OpenVMS Alpha code showing a 64-bit function
pointer being used.

Since I haven't used the non-default ALLOC_64BIT or /SEGMENT=CODE=64
(I64 and x86-64 only), which means the generated code resides in P0
32-bit and not in P2 64-bit.

Which ties back to the surprising complexity awaiting new developers here.

$ cc/point=64 ptr64
$ lin ptr64
$ r ptr64
Hi!
sizeof(foo) = 8
$ ty ptr64.c
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
void bar() {
printf("Hi!\n");
return;
} int main( int argc, int *argv[] ) {
void (*foo)();
foo = bar;
foo();
printf("sizeof(foo) = %d\n", sizeof(foo));
exit( EXIT_SUCCESS );
}

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-05-18 09:20:19 +0000, hb said:

> On 5/18/22 00:05, Craig A. Berry wrote:
>> ...
>> Or you've got a LIB$INITIALIZE routine to set the DECC$ features at
>> start-up time; I may not be explaining this right but I think that
>> routine has to be referenced by a 32-bit pointer because that's where
>> the image activator will look for it.
>
> The image activator doesn't care about the pointer size. Only for
> shareable images, the image activator calls the code in the
> LIB$INITIALIZE module, which was (by request) linked into the
> shareable. Its entry point was written by the linker and that's what
> the image activator is looking for. The code in LIB$INITIALIZE expects
> an array of 32-bit pointers in the LIB$INITIALIZE PSECTs. They are
> function pointers which are always 32 bit. This array is set up by the
> developer and filled with the pointers. If the source module for
> setting this up was compiled with 64 bit pointers, an array of pointers
> has 64 bit entries. With the function pointers being 32 bits, the array
> from LIB$INITIALIZE's point of view contains zero pointers. For the
> LIB$INITIALIZE code a zero pointer is the end of the list. With 64-bit
> pointers, that stops you from having more than one init routine called
> "from the image activator". When the image activation is done, the main
> image is started with SYS$IMGSTA, which calls the code in the
> LIB$INITIALIZE module, ...

More than a little of which is code necessary to work around other
backward-compatibility efforts, not the least of which is defensive app
coding around against the DECC$ feature logical names.

> That also explains, why you can debug init code of a main image, but
> you can't debug the init code of a shareable image (other than you run
> it as a main image).
>
> Some people may think SYS$IMGSTA (or even LIB$INITIALIZE) is part of
> the image activator. From my point of view, it is not.

That case could be made.

From out here in the peanut gallery, $IMGACT, $IMGSTA, $IMGFIX,
LIB$INITIALIZE, and the C run-time activation are all are part of image
activation. Without regard to how the code within the image activator
and related pieces is partitioned. All the stuff that happens before
the user code gets control. The LIB$INITIALIZE and LIB$INITIALIZE PSECT
stuff and the C main stuff and the DECC$ feature logical names are all
hacks seeking to establish and modify the run-time environment for the
code being activated, and all that before the user code gets control.
(And yes, I'm very deliberately pushing LIB$INITIALIZE code written by
ISVs and developers into this same bog with the image activator, as
that code only exists because of the limitations of image activation
implementation. If I didn't have to defend against DECC$* stuff, I
wouldn't have the code or the PSECT.)

The design of image activation code has been ignored, but then changes
here can and will break stuff, and either fixing this stuff or
overhauling the whole area—checking app signatures, telemetry,
provisioning, pledge-/promise-/unveil-like mechanisms, better app
packaging, are each substantial investments, and what's here usually
works.

Here's how another platform architected and stores this sort of
information:
https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html#//apple_ref/doc/uid/TP40009254-SW1
Is that perfect? Far from it. It is, however, a little more easy to
figure out what's going on, and to add and extend what the image (app)
activation provides. In OpenVMS terms, that property list file is a
combination of what is stored the image header, as well as the
initialization-related stuff, the DECC$* feature logical names, and
details and features not implemented on OpenVMS.

--
Pure Personal Opinion | HoffmanLabs LLC

On 5/18/22 22:22, Stephen Hoffman wrote:
> On 2022-05-18 08:28:20 +0000, hb said:
>
>> On 5/17/22 23:31, Stephen Hoffman wrote:
>>> On 2022-05-17 21:00:39 +0000, Arne Vajhj said:
>>> ...
>>>> I thought they had started moving code up to P2.
>>>
>>> Code which is inaccessible to 32-bit addresses, so don't try to pass
>>> a function pointer to that code.
>>
>> On x86 and IA64 function pointers are always 32 bit.
>>
>> On x86, by default the linker puts code into P2; on request the linker
>> can move code into P0. On x86 the function pointer is a code address
>> of a single code instruction, which uses a 64 bit address to jump to
>> the "real" code. The linker creates this code instruction. On IA64, by
>> default the linker puts code into P0; on request, the linker can move
>> code into P2. On IA64 the function pointer is the address of a data
>> structure, a Function Descriptor (FD), which contains a 64 bit address
>> of the "real" code. The linker creates the FD.
>
> Though AFAIK the user works with a 64-bit value for the function
> pointer, and doesn't ever see the internal limitations nor the use of a
> trampoline where that's needed.
>
> I don't have an Itanium handy to test and E9.2 isn't playing nicely at
> the moment, so here is OpenVMS Alpha code showing a 64-bit function
> pointer being used.
>
> Since I haven't used the non-default ALLOC_64BIT or /SEGMENT=CODE=64
> (I64 and x86-64 only), which means the generated code resides in P0
> 32-bit and not in P2 64-bit.
>
> Which ties back to the surprising complexity awaiting new developers here.
>
>
> $ cc/point=64 ptr64
> $ lin ptr64
> $ r ptr64
> Hi!
> sizeof(foo) = 8
> $ ty ptr64.c
> #include <stddef.h>
> #include <stdio.h>
> #include <stdlib.h>
> void bar() {
> printf("Hi!\n");
> return;
> }
> int main( int argc, int *argv[] ) {
> void (*foo)();
> foo = bar;
> foo();
> printf("sizeof(foo) = %d\n", sizeof(foo));
> exit( EXIT_SUCCESS );
> }

OK, I should have said, on x86 and IA64 function pointers always contain
32-bit values.

Or, whenever you take the address of a function, you will get a 32-bit
address.

On 5/18/2022 2:17 PM, Simon Clubley wrote:
> On 2022-05-18, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 5/18/2022 1:35 PM, Simon Clubley wrote:
>>> So why do you think that VMS APIs continued to have the size of pointers
>>> directly visible in data structures instead of being hidden behind
>>> a HLL pointer data type whose size could be changed on demand with
>>> compiler options without any major source code changes required ?
>>
>> Because this is VMS, not Unix, and some jobs just might need the flexibility?
>>
>
> So you admit the need to support Macro-32 applications was a requirement ? :-)

Sure was for me, cause I still have a Macro-32 application (database) in use.
Without that I would never used Alpha or itanic.

>>> It would have been a lot easier to do that instead of all the convoluted
>>> stuff VMS ended up doing to support 32-bit pointers and data structures
>>> in existing applications.
>>
>> Tell me what you think would have happened if Alpha would not have run VAX
>> applications? Yeah, DEC died anyway, but it would have been a lot quicker.
>>
>
> Alpha needed to run VAX applications, but because of how VMS was designed,
> DEC had to make some very ugly design decisions for VMS on Alpha.
>
> These are things that Unix systems mostly don't need to worry about.
>
> About the only time you need to worry about such things on Unix is when
> (for example) you are writing device drivers and the driver needs to use
> bounce buffers because of hardware limitations.
>
> Simon.
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-05-18 20:58:25 +0000, hb said:

> OK, I should have said, on x86 and IA64 function pointers always
> contain 32-bit values.
>
> Or, whenever you take the address of a function, you will get a 32-bit address.

Or more specifically, I'll get an opaque 64-bit value that looks and
works like a virtual address, but may or may not represent the actual
virtual address of the target instruction.

An opaque 64-bit virtual-address-like value which may then be folded,
spindled, and trampoline'd (or otherwise procedure-descriptor'd) as
needed, due to software and/or hardware addressing limitations.

Or an address-like value variously tagged, as some platforms are now
doing for improved data integrity and security.

https://www.anandtech.com/show/16759/sponsored-post-keep-your-apps-memory-safe-with-arm-memory-tagging-extension-mte

Which also means that every function pointer trampolines in a P2-based
64-bit app.

The trampolines are obvious targets for run-time "fun", too.

Presumably, those structures are at least moderately protected against
"rogue" or "creative" writes.

But it's an opaque 64-bit value, with an internal design that permits
somewhat less than the full 64-bit virtual address range available for
functions.

--
Pure Personal Opinion | HoffmanLabs LLC

On Thursday, May 5, 2022 at 4:37:42 PM UTC-5, Jan-Erik Söderholm wrote:
> Maybe others have seen this, but I just got this announcement from VSI.
> Regards, Jan-Erik.
>
>
>
> After analyzing customer feedback, VMS Software Inc. has made the decision
> to move hypervisor support on OpenVMS V9.2 to the top of our priority list.
> We plan to extend support for the following: VMWare, KVM and Hyper-V. Kevin
> Shaw, the CEO of VMS Software, Inc. and Stephen Nelson, VP Engineering will
> present this update of the VSI x86 rollout strategy at the webinar on May
> 11th. [Registration at https://vmssoftware.com/about/webinars/]
>
> Better hypervisor support will mean being able to run OpenVMS on any x86
> hardware, which is a priority for many customers. However, this also means
> that bare metal support will be delayed – although eventually the DL380 and
> several other server models are planned to be supported. The first limited
> production release of OpenVMS on x86, V9.2, is scheduled for July 2022.

I was on vacation but today at work I was told that Broadcom had bought VMWare and they plan to make it a subscription to run product as quickly as they can.

Wonder how that will impact. Suddenly running a subscription VMS on VMWare might (might! I don't know the prices) be getting more costly.

On Wednesday, June 1, 2022 at 2:21:46 PM UTC-7, Rich Jordan wrote:
>
> I was on vacation but today at work I was told that Broadcom had bought VMWare and they plan to make it a subscription to run product as quickly as they can.
>
> Wonder how that will impact. Suddenly running a subscription VMS on VMWare might (might! I don't know the prices) be getting more costly.

The crapification of computing technology continues unabated. Broadcom is such a bottom-feeder they bought CA. According to Broadcom, VMWare has too many customers. Broadcom's publicly stated intention (via El Reg) is to mine the customer base, extracting the most valuable veins. Those chumps^H customers are so locked-in to VMWare, they won't be able to switch. If they're also using VMS, cost increases are baked-in as just another cost-of-business to be passed on the taxpayer. For the rest, it's a reminder of why CA grew big enough to be a meal for Broadcom. They can always switch to another hypervisor!
"This port should be no problem, since their computers as the same color as ours."

On 2022-06-01, plugh <jchimene@gmail.com> wrote:
> On Wednesday, June 1, 2022 at 2:21:46 PM UTC-7, Rich Jordan wrote:
>>
>> I was on vacation but today at work I was told that Broadcom had bought VMWare and they plan to make it a subscription to run product as quickly as they can.
>>
>> Wonder how that will impact. Suddenly running a subscription VMS on VMWare might (might! I don't know the prices) be getting more costly.
>
> The crapification of computing technology continues unabated. Broadcom is such a bottom-feeder they bought CA. According to Broadcom, VMWare has too many customers. Broadcom's publicly stated intention (via El Reg) is to mine the customer base, extracting the most valuable veins. Those chumps^H customers are so locked-in to VMWare, they won't be able to switch. If they're also using VMS, cost increases are baked-in as just another cost-of-business to be passed on the taxpayer. For the rest, it's a reminder of why CA grew big enough to be a meal for Broadcom. They can always switch to another hypervisor!
> "This port should be no problem, since their computers as the same color as ours."

Not to worry. You can just ask Broadcom for a _full_ datasheet when
you run into problems...

Simon.

PS: In fairness, it's not just them. Ever tried getting a full datasheet
out of FTDI (for example) ?

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.