Does anyone here think that this is an option for people not willing or
able to move over to x86-64 yet?
An HP Integrity emulator, emulating something like an rx2800 i2 i4 or i6
(16 cores max)

I could imagine it would be useful if stuck with HP-UX or OpenVMS for
Integrity for some reason?!?

Why am I asking? Well, HPE Integrity servers are getting scarce. I have
probably purchased 80% of the ones on the market and some companies are
buying up whatever is available

Comments please.

David Turner

On Thursday, August 11, 2022 at 6:48:21 PM UTC-4, David Turner wrote:
> Does anyone here think that this is an option for people not willing or
> able to move over to x86-64 yet?
> An HP Integrity emulator, emulating something like an rx2800 i2 i4 or i6
> (16 cores max)
>
> I could imagine it would be useful if stuck with HP-UX or OpenVMS for
> Integrity for some reason?!?
>
> Why am I asking? Well, HPE Integrity servers are getting scarce. I have
> probably purchased 80% of the ones on the market and some companies are
> buying up whatever is available
>
>
> Comments please.
>
>
> David Turner
Since there is a performance penalty to pay when using an emulator on a system, there is likely to be no emulator that could approach Integrity performance levels with currently available hardware. I know of no emulator for Integrity systems at this time.

Dan

On Thursday, August 11, 2022 at 3:48:21 PM UTC-7, David Turner wrote:
> Does anyone here think that this is an option for people not willing or
> able to move over to x86-64 yet?

Without looking at it in much detail, it would seem to me not so good an idea.

IA-64 is specifically designed such that the instruction set optimizes the
ability of the hardware to execute instructions. All the out-of-order
hazards are solved at compile time, such that everything happens in
the right order. (Part of the reason for the complication of the design,
and especially of writing compilers for it.)

One problem with any RISC design, and especially with IA-64, is
how it scales over time. Things that made sense with the technology
one year, might be completely wrong not so many years later. (*)

Now, the thing that has made emulation work well over the years,
is that newer, faster, processors are enough faster, and also more
energy efficient, to overcome the cost of emulation. It might be
that is now true for IA-64. It does seem likely, though, that instructions
optimized for hardware are less optimized for emulation.

(*) One interesting idea from early RISC is the branch delay slot,
where one instruction is executed after the branch, while the
hardware figures out how to do the branch, and keep the pipeline
full. But as technology changed, that would have required more
and more instructions in the delay slot, inconvenient for existing
hardware, and also for compiler writers if it was done in new
hardware.

On 8/11/2022 6:48 PM, David Turner wrote:
> Does anyone here think that this is an option for people not willing or
> able to move over to x86-64 yet?
> An HP Integrity emulator, emulating something like an rx2800 i2 i4 or i6
> (16 cores max)
>
> I could imagine it would be useful if stuck with HP-UX or OpenVMS for
> Integrity for some reason?!?
>
> Why am I asking? Well, HPE Integrity servers are getting scarce. I have
> probably purchased 80% of the ones on the market and some companies are
> buying up whatever is available
>
> Comments please.

Based on previous discussions here then no Itanium emulator
currently exist.

In theory one could be made. It should be possible to emulate any
CPU where detailed enough documentation is available.

Several posters has raised the performance issue. And even though
it is obviously easier to get similar performance of a 1 core
@ 400-600 MHz Alpha than a 4/8 core @ 1.5-2.0 GHz Itanium on
a 16/24/32 core @ 3 GHz x86-64, then I think it could be
done. I don't expect a non-JIT emulator to be fast enough,
but I believe a JIT emulator could just be fast enough to
be usable.

But I also suspect that developing such an emulator would be
a lot of work (read: bloody expensive). Itanium is a complex
CPU - I suspect a lot more complex than Alpha, and that means
more expensive to develop.

So the feasibility will depend on how many licenses could
be sold.

If you are really interested then you could reach out to Stromasys
and EmuVM and ask how many licenses they would need to sell
for them to be willing to do an Itanium emulator.

Honestly I doubt the numbers will work out. I expect the
vast majority of VMS I64 users to have migrated to VMS x86-64 within
5-10 years. 5-10 years may sound like a long time, but it is not
a long time if it is the timespan where an expensive software
product will sell.

Anyway it will not cost you much to make a few phone calls
and ask people that really knows instead of listening to someone
like me that are just thinking out loud.

Arne

On Thursday, August 11, 2022 at 5:04:08 PM UTC-7, Arne Vajhøj wrote:

(snip)
> But I also suspect that developing such an emulator would be
> a lot of work (read: bloody expensive). Itanium is a complex
> CPU - I suspect a lot more complex than Alpha, and that means
> more expensive to develop.

The idea was that it would be simpler than a processor figuring out
on its own how to overlap and reorder instructions. The compiler
is supposed to do that (once) instead of the processor (every time
instructions are executed.

But yes, it is a very complicated processor.

Now, it is possible that there are people who don't need such a fast
processor, but instead need a large memory. (I just noticed that
the DS10 goes up to only 2GB.)

In the Cray-1 days, I wondered why there was no machine to compile
Cray programs on, without using expensive actual Cray-1 time.

A slow IA-64 emulator might not be so hard to write, but getting
reasonable speed should be a real challenge. Especially doing anything
in parallel.

On Thursday, August 11, 2022 at 9:15:44 PM UTC-4, gah4 wrote:
> On Thursday, August 11, 2022 at 5:04:08 PM UTC-7, Arne Vajhøj wrote:
>
> (snip)
> > But I also suspect that developing such an emulator would be
> > a lot of work (read: bloody expensive). Itanium is a complex
> > CPU - I suspect a lot more complex than Alpha, and that means
> > more expensive to develop.
> The idea was that it would be simpler than a processor figuring out
> on its own how to overlap and reorder instructions. The compiler
> is supposed to do that (once) instead of the processor (every time
> instructions are executed.
>
> But yes, it is a very complicated processor.
>
> Now, it is possible that there are people who don't need such a fast
> processor, but instead need a large memory. (I just noticed that
> the DS10 goes up to only 2GB.)
>
> In the Cray-1 days, I wondered why there was no machine to compile
> Cray programs on, without using expensive actual Cray-1 time.
>
> A slow IA-64 emulator might not be so hard to write, but getting
> reasonable speed should be a real challenge. Especially doing anything
> in parallel.
Realize that a system emulator is more involved that just emulating the instruction stream. The underlying hardware must be emulated as well. This may be as simple as translating an I/O stream into something that the host system can understand or as complex as emulating the functions of a file system within a "data file". There is much involved here.

Dan

On Thursday, August 11, 2022 at 4:02:07 PM UTC-7, gah4 wrote:
> IA-64 is specifically designed such that the instruction set optimizes the
> ability of the hardware to execute instructions. All the out-of-order
> hazards are solved at compile time, such that everything happens in
> the right order. (Part of the reason for the complication of the design,
> and especially of writing compilers for it.)
>
> One problem with any RISC design, and especially with IA-64, is
> how it scales over time. Things that made sense with the technology
> one year, might be completely wrong not so many years later. (*)

IA-64 isn't a RISC design, and the problem wasn't that it "didn't scale over time"; EPIC was a flawed premise for general-purpose computing. Turns out that it is impossible to solve out-of-order hazards at compile time for most workloads involving random memory accesses -- which makes it impossible to extract significant performance benefits from VLIW architectures for the vast majority of software.

VLIW architectures are very useful for streaming workloads with no dynamic latency, and strictly ordered execution -- they're very successful in DSP and GPU applications to this day. Bu

On Thursday, August 11, 2022 at 6:48:21 PM UTC-4, David Turner wrote:
> Does anyone here think that this is an option for people not willing or
> able to move over to x86-64 yet?
> An HP Integrity emulator, emulating something like an rx2800 i2 i4 or i6
> (16 cores max)
>
> I could imagine it would be useful if stuck with HP-UX or OpenVMS for
> Integrity for some reason?!?
>
> Why am I asking? Well, HPE Integrity servers are getting scarce. I have
> probably purchased 80% of the ones on the market and some companies are
> buying up whatever is available
>
>
> Comments please.
>
>
> David Turner
David,

I remember asking a similar question a ways back, with respect to the x86-64 port. The comment I received concerning a binary emulator on OVMS x86-64 was that there were features of the instruction set covered by Intel patents. If that response was correct, before doing a project like this, one would need to determine the accuracy of that statement.

Ignoring the patent issue, the instruction set is fully documented, albeit significant in size. Technically, it could be done, particularly with a scope limitation of the non-privileged instruction set. Unlike the question of the VAX, there is probably a smaller market, as recompiling the source code is a far better option.

There are those who are bound to other issues, e.g., regulated configurations, but that requires full system emulation, which has correctly been identified as a far wider scope than just user-mode execution.

- Bob Gezelter, http://www.rlgsc.com

On Thursday, August 11, 2022 at 7:01:14 PM UTC-7, abrsvc wrote:

(snip)

> Realize that a system emulator is more involved that just emulating the
> instruction stream. The underlying hardware must be emulated as well.
> This may be as simple as translating an I/O stream into something that
> the host system can understand or as complex as emulating the functions
> of a file system within a "data file". There is much involved here.

It is.

As a rough approximation, which mostly goes back to microprogrammed
machines from the 1960's and 1970's, but I believe also to software
emulated CISC processors is about 1/10 the speed. That is, about 10
instructions to emulate one, on average.

The idea behind RISC is simpler instructions, and the possibility that
more can be executed in the same time. One might hope that RISC
instructions are easier to emulate, but it isn't so obvious that the
RISC advantage still applies with emulation.

IA-64 is supposed to be able to execute 6 instructions per clock cycle.
My guess is that, at least the easier emulation, might still be 10 real
instructions per emulated instruction, so maybe 60 times slower.

And yes things like I/O all need to be emulated, but usually aren't
a big limit on execution speed. They might still take time to get
right, though.

On Friday, August 12, 2022 at 12:44:05 AM UTC-7, jimc...@gmail.com wrote:

(snip)

> IA-64 isn't a RISC design, and the problem wasn't that it "didn't scale over time";
> EPIC was a flawed premise for general-purpose computing. Turns out that it is
> impossible to solve out-of-order hazards at compile time for most workloads
> involving random memory accesses -- which makes it impossible to extract
> significant performance benefits from VLIW architectures for the vast majority of software.

Well it isn't so easy at run-time, either. Much of my early programming was on an
IBM 360/91, which was a favorite machine for books on pipelined processors.
(And one of the few that do out-of-order retirement.)

The goal of the 360/91 was one instruction per clock cycle on normal programs,
not specifically written for it. (That is, generated by usual compilers.)
Among others, the 360/91 can prefetch on two branch paths, in addition to the
non-branch path. Keeping the pipelines full isn't so easy, and often likely
didn't run as fast as one might have hoped.

As well as I know, no parallel processor, or pipelined processor, ever runs
as fast as its (over-optimistic) designers hoped.

But okay, memory access is always a problem. The 360/91 uses 16 way
interleaved memory, as memory access time is about 13 clock cycles.
But since you can't predict the access patterns, you don't know
how well interleaved memory works.

With cache, one hopes to have more uniform memory access times,
but yes it is not easy to predict. Yes it is not possible to solve hazards
at compile time, but it is also not possible at run time. One just does
as well as it can be done, and hopes it is good enough.

(One of the fun things about the 360/91 is imprecise interrupts.
When an interrupt occurs, the pipeline is flushed, and the address is
(usually) not the address of the source of the interrupt.)

On 8/12/2022 6:26 AM, gah4 wrote:
> As a rough approximation, which mostly goes back to microprogrammed
> machines from the 1960's and 1970's, but I believe also to software
> emulated CISC processors is about 1/10 the speed. That is, about 10
> instructions to emulate one, on average.
>
> The idea behind RISC is simpler instructions, and the possibility that
> more can be executed in the same time. One might hope that RISC
> instructions are easier to emulate, but it isn't so obvious that the
> RISC advantage still applies with emulation.
>
> IA-64 is supposed to be able to execute 6 instructions per clock cycle.
> My guess is that, at least the easier emulation, might still be 10 real
> instructions per emulated instruction, so maybe 60 times slower.

1/10th seems slightly optimistic for non-JIT emulation.

But the fastest Alpha emulators use JIT today and an IA-64
emulator would need to as well if it is to perform well.

And then we are talking closer to 1:1 instruction wise.

https://emuvm.com/support/faq/

<quote>
What is CPU server: basic, JIT1, JIT2, JIT3?

AlphaVM supports several CPU implementation back-ends. They all
implement the same Alpha CPU functionality, but in various ways.

Basic CPU is the simplest CPU implementation based on the
interpretation of Alpha instructions fetched from the memory. This CPU
serfver is the only CPU server available in AlphaVM-Basic.
JITx CPUs are based on the Just-In-Time compilation of Alpha code
to increase the performance.
JIT1 server compiles to byte code. Its performance is almost
double of the basic CPU.
JIT2 server compiles Alpha code to naive x86-64 code. Its
performance on most workloads is about a factor of 5 faster than the
basic CPU.
JIT3 server compiles Alpha code to naive x86-64 code. This CPU
server applies sophisticated optimization. It’s performance is a factor
of 10 faster than the basic CPU.

AphaVM-Pro is offered with JIT3 CPU. AlphaVM-Basic only supports the
basic CPU. Other CPU servers are used merely for debugging.
</quote>

Note that this is the vendors own description - not an
independent benchmark.

Arne

On 8/12/2022 3:44 AM, jimc...@gmail.com wrote:
> On Thursday, August 11, 2022 at 4:02:07 PM UTC-7, gah4 wrote:
>> IA-64 is specifically designed such that the instruction set optimizes the
>> ability of the hardware to execute instructions. All the out-of-order
>> hazards are solved at compile time, such that everything happens in
>> the right order. (Part of the reason for the complication of the design,
>> and especially of writing compilers for it.)
>>
>> One problem with any RISC design, and especially with IA-64, is
>> how it scales over time. Things that made sense with the technology
>> one year, might be completely wrong not so many years later. (*)
>
> IA-64 isn't a RISC design, and the problem wasn't that it "didn't
> scale over time"; EPIC was a flawed premise for general-purpose
> computing. Turns out that it is impossible to solve out-of-order
> hazards at compile time for most workloads involving random memory
> accesses -- which makes it impossible to extract significant
> performance benefits from VLIW architectures for the vast majority of
> software. >
> VLIW architectures are very useful for streaming workloads with no
> dynamic latency, and strictly ordered execution -- they're very
> successful in DSP and GPU applications to this day.
I am not fully convinced that VLIW was a bad idea.

Yes - it turned out to be extremely difficult to
get N VLIW execution units to be N times as fast
as traditional single execution unit.

But I think that is the wrong comparison.

The correct comparison is whether N VLIW
execution units are faster than N multi-core
execution units requiring multiple threads.

I suspect that may frequently be the case.

Arne

On 2022-08-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 8/11/2022 6:48 PM, David Turner wrote:
>> Does anyone here think that this is an option for people not willing or
>> able to move over to x86-64 yet?
>> An HP Integrity emulator, emulating something like an rx2800 i2 i4 or i6
>> (16 cores max)
>>
>> I could imagine it would be useful if stuck with HP-UX or OpenVMS for
>> Integrity for some reason?!?
>>
>> Why am I asking? Well, HPE Integrity servers are getting scarce. I have
>> probably purchased 80% of the ones on the market and some companies are
>> buying up whatever is available
>>
>> Comments please.
>
> Based on previous discussions here then no Itanium emulator
> currently exist.
>
> In theory one could be made. It should be possible to emulate any
> CPU where detailed enough documentation is available.
>

If you think this problem is about emulating the CPU, then you don't
understand the problem.

A good chunk of the CPU emulation work has already been done in Ski,
but that's only a userland binaries emulator for Linux and would be
useless as-is for running even userland VMS binaries.

In a full system emulator, the CPU is only one small part of the
emulation. You also have to emulate all the rest of the hardware to
a good enough accuracy that VMS can't tell the difference.

_That_ is where the majority of the work lies.

A full system emulator would also need access to the firmware loaded
onto the real hardware and that is now only available under a support
contract.

A userland binaries emulator OTOH would need to be run on top of
another VMS system on a different architecture as it works by calling
the system services in the underlying VMS system when a call to a VMS
system service is made in the Itanium binary.

If you run it on Alpha, you need to emulate any system services added
to Itanium that don't exist on Alpha VMS. If you run it on x86-64 VMS,
you need to hope that all the system services available on Itanium exist
on x86-64 VMS, or you have the same problem.

In addition, VMS has a major problem that simply doesn't exist in Linux
and that is whereas the vast majority of interaction between a Linux
userland binary and Linux itself is via a nice well-defined syscall
interface, VMS binaries have a nasty habit of looking at data cells
which exist directly in the VMS process's address space.

Such data cell access would have to be recognised and emulated in such
a userland level emulator.

In addition to this, you also have the problem of sharable images mapped
into user space during image activation. Such images would have to be
brought along from the Itanium system and run through the emulator
as well. I don't know what the licence implications of doing that would be.

In short, a userland binaries emulator would very likely be unsuitable
for anything other than simple VMS Itanium userland binaries so you are
looking at a full system emulator for running a real Itanium application
on another architecture.

Simon.

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

On 8/12/2022 9:10 AM, Simon Clubley wrote:
> On 2022-08-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 8/11/2022 6:48 PM, David Turner wrote:
>>> Does anyone here think that this is an option for people not willing or
>>> able to move over to x86-64 yet?
>>> An HP Integrity emulator, emulating something like an rx2800 i2 i4 or i6
>>> (16 cores max)
>>>
>>> I could imagine it would be useful if stuck with HP-UX or OpenVMS for
>>> Integrity for some reason?!?
>>>
>>> Why am I asking? Well, HPE Integrity servers are getting scarce. I have
>>> probably purchased 80% of the ones on the market and some companies are
>>> buying up whatever is available
>>>
>>> Comments please.
>>
>> Based on previous discussions here then no Itanium emulator
>> currently exist.
>>
>> In theory one could be made. It should be possible to emulate any
>> CPU where detailed enough documentation is available.
>>
>
> If you think this problem is about emulating the CPU, then you don't
> understand the problem.
>
> A good chunk of the CPU emulation work has already been done in Ski,
> but that's only a userland binaries emulator for Linux and would be
> useless as-is for running even userland VMS binaries.
>
> In a full system emulator, the CPU is only one small part of the
> emulation. You also have to emulate all the rest of the hardware to
> a good enough accuracy that VMS can't tell the difference.
>
> _That_ is where the majority of the work lies.

Possible.

But it is still a matter of documentation.

And unlike the IA-64 instruction set that is pretty unique, then
I would assume the hardware support is different but same style as
other emulators.

> A full system emulator would also need access to the firmware loaded
> onto the real hardware and that is now only available under a support
> contract.

The Alpha emulators get it from somewhere. HP(E) I presume. Anyone
doing an IA-64 emulator would need the same.

This is not a hobbyist weekend project. This would be a commercial
company deciding to invest millions of dollars.

Arne

On Friday, August 12, 2022 at 5:42:17 AM UTC-7, Arne Vajhøj wrote:
> The correct comparison is whether N VLIW
> execution units are faster than N multi-core
> execution units requiring multiple threads.

For certain workloads VLIW excels -- execution patterns that don't require non-deterministic memory access, don't benefit from out-of-order execution, and require massive vectorized instructions. It's why VLIW continues to receive investment and innovation in applications like digital signal processing and graphics acceleration.

For general-purpose workloads, they are not. Itanium eventually needed multiple cores, SMT, out-of-order execution, speculative processing in order to achieve reasonable performance -- all techniques that VLIW were intended to make unnecessary.

On Friday, August 12, 2022 at 3:48:47 AM UTC-7, gah4 wrote:
> Well it isn't so easy at run-time, either. Much of my early programming was on an
> IBM 360/91, which was a favorite machine for books on pipelined processors.

It's not easy at run-time, but the 50+ years since the 360/91 was designed have shown that run-time techniques are more effective for most workloads.

> Yes it is not possible to solve hazards > at compile time, but it is also not possible at run time. One just does
> as well as it can be done, and hopes it is good enough.

Successful hardware engineering usually doesn't come from "do the best you can with a technique and hope it's enough".

Hardware techniques to address execution hazards have always delivered more usable performance in general-purpose computing than EPIC offered -- and everything genuinely useful that came from EPIC designs (compiler innovations, large on-die caches, memory controllers, process shrinks) provided even more performance when applied to other instruction architectures.

Itanium only became usably performant by adding SMT, out-of-order execution, and speculative execution -- all of which had already pulled AMD64/x64 and other architectures ahead in pure performance, in speed-per-gate-count, as well as in thermal efficiency and power consumption.

For general-purpose computing, nearly everything of value that came from the billions of dollars poured into EPIC provided more benefit for other technologies.

On 2022-08-12, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> And unlike the IA-64 instruction set that is pretty unique, then
> I would assume the hardware support is different but same style as
> other emulators.
>

Yes and no.

Emulating various standard disk drive interfaces (for example) is one
thing, but the Itanium architecture itself has its own unique hardware
infrastructure of which the CPU instruction set is just one part.

Once again, emulating the instruction set is only one task that needs
to be done in a long list of tasks before you have a viable full system
emulator.

This hardware also needs to be emulated to a level of accuracy that means
VMS can't tell the difference. That's a _lot_ of work. Just look at the
bug reports that show up here every so often for Alpha that turn out to
be an emulation problem in the Alpha emulator in use.

That's for an architecture which is very well-known and _far_ less complex
than Itanium is. It may also interest you to know that nobody has put an
Itanium emulator in QEMU even through it supports this list of architectures:

https://www.qemu.org/docs/master/system/index.html

Writing an Itanium emulator is probably not viable these days, either as
a commercial project or a hobbyist project, given the amount of effort
required to create one and the need to access restricted firmware (for
hobbyists) or the limited user base (for commercial projects).

The fact Itanium is also both complex and dead counts against it when
trying to get people interested in it for a hobbyist project.

Simon.

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

On Friday, August 12, 2022 at 10:54:30 AM UTC-7, Simon Clubley wrote:

> The fact Itanium is also both complex and dead counts against it when
> trying to get people interested in it for a hobbyist project.

At some point, I predict being complex and an infamous business failure will ensure that hobbyists build a platform emulator for Itanium :) It will be too late for the scenario David's customers need, however

On 2022-08-11 22:48:16 +0000, David Turner said:

> Does anyone here think that this is an option for people not willing or
> able to move over to x86-64 yet?
>
> An HP Integrity emulator, emulating something like an rx2800 i2 i4 or
> i6 (16 cores max)

Nope. Not now, not particularly effectively, and not anytime soon.

Used Itanium server prices and availability will be a bellwether for
the success of VSI OpenVMS x86-64.

Though if somebody wants to try this:
http://iccd.et.tudelft.nl/Proceedings/2004/22310288.pdf

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-08-12 15:10, Simon Clubley wrote:
> In addition, VMS has a major problem that simply doesn't exist in Linux
> and that is whereas the vast majority of interaction between a Linux
> userland binary and Linux itself is via a nice well-defined syscall
> interface, VMS binaries have a nasty habit of looking at data cells
> which exist directly in the VMS process's address space.
>
> Such data cell access would have to be recognised and emulated in such
> a userland level emulator.

I find that claim incredibly hard to believe. Can you give some examples
of this? Because even RSX, which is just a primitive predecessor of VMS
do not have such behavior. Everything in the kernel is completely hidden
and out of scope for a process, and the only way to do or get to
anything is through system calls. And that is generally true of almost
any reasonable multiuser, timesharing, memory protected operating system.

There is absolutely nothing Unix/Linux specific about this.

Heck - how would such programs even survive upgrading to a new version
of the OS, when things might move around and change internally???

Johnny

On 2022-08-12 22:38:28 +0000, Johnny Billquist said:

> On 2022-08-12 15:10, Simon Clubley wrote:
>> In addition, VMS has a major problem that simply doesn't exist in Linux
>> and that is whereas the vast majority of interaction between a Linux
>> userland binary and Linux itself is via a nice well-defined syscall
>> interface, VMS binaries have a nasty habit of looking at data cells
>> which exist directly in the VMS process's address space.
>>
>> Such data cell access would have to be recognised and emulated in such
>> a userland level emulator.
>
> I find that claim incredibly hard to believe. Can you give some
> examples of this?

VAX stuff that does this will reference SYS$BASE_IMAGE during the link,
and Alpha and Integrity apps will use LINK /SYSEXE to resolve these
symbols.

As one of various examples of symbols that some few apps will poke at:
CTL$A_COMMON — and there are others.

We met a few back in the era of Y2K too, where some apps were reading
directly from the kernel clock storage quadword.

> Because even RSX, which is just a primitive predecessor of VMS do not
> have such behavior.

RSX and OpenVMS are different. (I'd have thought you'd already been
singed enough by this erroneous assumption, but here we are again.)

The four-rings UREW/URKW/etc design specifically permits developers to
allow these cross-mode access shenanigans, too. BTW: UREW wasn't
feasible on Itanium.

To make some of these cross-mode shenanigans somewhat more supportable,
OpenVMS also implements a P1 window into system space at CTL$GL_PHD,
allowing supervisor code to poke at kernel data. But I digress.

> Everything in the kernel is completely hidden and out of scope for a
> process, and the only way to do or get to anything is through system
> calls.

Nope.

--
Pure Personal Opinion | HoffmanLabs LLC

On Friday, August 12, 2022 at 3:38:31 PM UTC-7, Johnny Billquist wrote:

(snip)

> I find that claim incredibly hard to believe. Can you give some examples
> of this? Because even RSX, which is just a primitive predecessor of VMS
> do not have such behavior. Everything in the kernel is completely hidden
> and out of scope for a process, and the only way to do or get to
> anything is through system calls. And that is generally true of almost
> any reasonable multiuser, timesharing, memory protected operating system.

Does timesharing mean interactive?

It might not be true for OS/360, though that is batch and was designed
before some things were known, and especially when main memory
was expensive ($1/byte, maybe more).

It mostly works at user level, as CMS does it. (That is, IBM's own
emulation of OS/360 system calls.)

One of the complications of OS/360 is that the most important
control block, the DCB, is in user space. Even more, it has some 24
bit addresses, even with 31 and 64 bit OS versions. Much fun.

In article <ZS2dnf0hyLpzG2j_nZ2dnZfqn_WdnZ2d@supernews.com>,
dturner@islandco.com (David Turner) wrote:

> Does anyone here think that this is an option for people not
> willing or able to move over to x86-64 yet?
> An HP Integrity emulator, emulating something like an rx2800 i2 i4
> or i6 (16 cores max)

It would be useful, but it does not exist. Stromasys seem to be the
leading vendor of emulators - they support VAX, Alpha, PDP-11, SPARC and
PA-RISC - but they show no sign of launching an Itanium emulator. You
could always ask them about it? https://www.stromasys.com/

John

On 2022-08-13 02:21, Stephen Hoffman wrote:
> On 2022-08-12 22:38:28 +0000, Johnny Billquist said:
>
>> On 2022-08-12 15:10, Simon Clubley wrote:
>>> In addition, VMS has a major problem that simply doesn't exist in
>>> Linux and that is whereas the vast majority of interaction between a
>>> Linux userland binary and Linux itself is via a nice well-defined
>>> syscall interface, VMS binaries have a nasty habit of looking at data
>>> cells which exist directly in the VMS process's address space.
>>>
>>> Such data cell access would have to be recognised and emulated in
>>> such a userland level emulator.
>>
>> I find that claim incredibly hard to believe. Can you give some
>> examples of this?
>
> VAX stuff that does this will reference SYS$BASE_IMAGE during the link,
> and Alpha and Integrity apps will use LINK /SYSEXE to resolve these
> symbols.
>
> As one of various examples of symbols that some few apps will poke at:
> CTL$A_COMMON — and there are others.
>
> We met a few back in the era of Y2K too, where some apps were reading
> directly from the kernel clock storage quadword.

Are such symbols then guaranteed to never move between different
versions of the OS, or how is this managed?

>> Because even RSX, which is just a primitive predecessor of VMS do not
>> have such behavior.
>
> RSX and OpenVMS are different.  (I'd have thought you'd already been
> singed enough by this erroneous assumption, but here we are again.)

I know. :-)

> The four-rings UREW/URKW/etc design specifically permits developers to
> allow these cross-mode access shenanigans, too. BTW: UREW wasn't
> feasible on Itanium.

I know that the VAX hardware have these. I just find it weird that you
would have a design where you directly reach into the innards of the OS
without going through any system call layer.
In general it have been understood for quite some time that this is a
bad idea. Abstraction and isolation is more or less some core designs
for making things more robust and possible to change without breaking
things.

> To make some of these cross-mode shenanigans somewhat more supportable,
> OpenVMS also implements a P1 window into system space at CTL$GL_PHD,
> allowing supervisor code to poke at kernel data. But I digress.

That is digressing. Supervisor code is not normal user processes.

Well. I'm tempted to paraphrase the late Mark Crispin. RSX - a great
improvements on its successors.
(He used that with TOPS-20 and any Unix system)

Johnny

On 2022-08-13 03:03, gah4 wrote:
> On Friday, August 12, 2022 at 3:38:31 PM UTC-7, Johnny Billquist wrote:
>
> (snip)
>
>> I find that claim incredibly hard to believe. Can you give some examples
>> of this? Because even RSX, which is just a primitive predecessor of VMS
>> do not have such behavior. Everything in the kernel is completely hidden
>> and out of scope for a process, and the only way to do or get to
>> anything is through system calls. And that is generally true of almost
>> any reasonable multiuser, timesharing, memory protected operating system.
>
> Does timesharing mean interactive?

No. I just tried to limit myself to systems that fulfilled all those
attributes as systems where this isolation would be obvious. It was not
meant to be read that all timesharing systems are interactive, or that
all multiuser systems have memory protection, or any combination of
attributes means that all of those attributes apply or are necessary.

Unix systems, of which Linux is one, used to also not have that
isolation. In the old days, a lot of things were done by opening
/dev/kmem, and read through the kernel memory. Which then had to be done
in combination with reading the kernel symbol table in order to find out
where in kernel memory to read. This was always ugly, risky and tricky.
They obviously learned that this is no good, and got away from it. The
fact that VMS still have this is very surprising to me. I would have
thought it never had it to start with. Like I said, RSX do not. But in a
way that was easier/more obvious on a PDP-11, since it's not such a flat
address space as on the VAX. Kernel space on a PDP-11 is generally not
even possible to see from user space, and you'd have to mess things up,
and use extra resources there. On the VAX, the kernel space is always a
part of your address space, but I would expect it to normally all have
been fully protected from user space access. But now I'm being told it
actually isn't with VMS. I guess they might have been concerned about
performance, but this is a sad state and excuse.

Johnny