On 2022-08-13 10:19:14 +0000, Johnny Billquist said:

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

Linking against the kernel can vary, whether from boot to boot, or from
patch to patch. There are some apps which resolve these references at
app startup, and others that require relinking after updates or
upgrades.

Whether anybody wanted users accessing data directly is one discussion.
That some of the kernel data was accessible from an outer mode (user,
super, etc) and which meant some developers would access it directly is
another discussion.

> 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.

VAX/VMS programmers can and did make substantial efforts to optimize
some VAX code.

Worked to reduce or eliminate CALLS/CALLG calls and change-mode
operations and longword offsets was popular, along with some other VAX
operations.

That code tuning is related to why some of us have been cleaning up
co-routine code in recent decades, why the OpenVMS Alpha C system
programming work that occurred leading up to OpenVMS Alpha V6.1 was
gnarly, and why compiler code generation can be such a joy.

There's sketchy Y2K-era timekeeping and time-drifting code around and
still in use, too. Apps that haven't been remediated to deal correctly
with daylight saving time changes, mostly.

That VAX code-optimization work has become needed less often in recent
times particularly as the compilers address much of that, though there
are still performance-sensitive code paths in some apps. Just not as
widespread as on VAX.

> 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.

Which is why I've been known to grumble about itemlists and descriptors
and related abstractions, too. Itemlists and descriptors were great for
the 1980s and 1990s, but are increasingly limiting what changes can be
made to OpenVMS APIs.

>> Hoff: 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.

It's another of design compromises intended to reduce or avoid
overhead. VAX/VMS had those. All operating systems have those.

TL;DR: Yes, there are outer-mode apps that read directly from
inner-mode memory.

--
Pure Personal Opinion | HoffmanLabs LLC

John Dallman <jgd@cix.co.uk> wrote:
>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/

It is very, very hard to build an efficient emulator for the itanium, which
is part of why HP didn't actually realize how bad the architecture was until
they were close to having silicon on the die.

Although people in this newsgroup keep referring to itanium as a risc machine,
it's not at all a risc machine. It's a VLIW architecture where the instruction
actually sets the bits to route the data within the processor rather than just
saying what operations to perform. That is, it's basically microcode instead
of a normal operating instruction code.

This means that the actual number of possible operations that you can perform
is enormous, and a lot of the instructions themselves aren't completely
documented. You can do weird combinations of operations in one instruction,
routing an accumulator into several different parts of the alu and then picking
pieces of each of the alu outputs and putting them into another register.

Getting the compiler to efficiently take advantage of the VLIW archiecture
is really, really hard, and not enough actual work got put into it to make
the Intel compiler good enough. It might have taken decades to make it good.

Anyway, because of this, either you look at the instructions that the compiler
generates and you emulate those and hope nobody runs any code that didn't
come from that compiler, or you simulate at gate level and get a an emulator
that is accurate and reliable and slow as molasses.

It's a really interesting approach to building a computer, going in a very
different direction than either CISC or RISC architectures, but it relies
entirely on either very sophisticated compilers or very sophisticated assembler
programmers, and there remains a shortage of both.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 8/13/2022 4:54 PM, Scott Dorsey wrote:
> John Dallman <jgd@cix.co.uk> wrote:
>> 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/
>
> It is very, very hard to build an efficient emulator for the itanium, which
> is part of why HP didn't actually realize how bad the architecture was until
> they were close to having silicon on the die.
>
> Although people in this newsgroup keep referring to itanium as a risc machine,
> it's not at all a risc machine. It's a VLIW architecture where the instruction
> actually sets the bits to route the data within the processor rather than just
> saying what operations to perform. That is, it's basically microcode instead
> of a normal operating instruction code.

https://en.wikipedia.org/wiki/Multiflow

--

--- Rob

On 2022-08-13 21:46, Stephen Hoffman wrote:
> On 2022-08-13 10:19:14 +0000, Johnny Billquist said:
>
>> Are such symbols then guaranteed to never move between different
>> versions of the OS, or how is this managed?
>
> Linking against the kernel can vary, whether from boot to boot, or from
> patch to patch. There are some apps which resolve these references at
> app startup, and others that require relinking after updates or upgrades.

I see. Potential nastiness ahead there then.

> Whether anybody wanted users accessing data directly is one discussion.
> That some of the kernel data was accessible from an outer mode (user,
> super, etc) and which meant some developers would access it directly is
> another discussion.

Understood. But I guess the fact that they made it possible means
obviously some will do it.

>> 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.
>
> VAX/VMS programmers can and did make substantial efforts to optimize
> some VAX code.
>
> Worked to reduce or eliminate CALLS/CALLG calls and change-mode
> operations and longword offsets was popular, along with some other VAX
> operations.

Understood. And I do remember a lot of this stuff from way back when.
It do seem that in the goal to make things a bit more efficient, they
were willing to bend things just a bit more than I had expected.

> That code tuning is related to why some of us have been cleaning up
> co-routine code in recent decades, why the OpenVMS Alpha C system
> programming work that occurred leading up to OpenVMS Alpha V6.1 was
> gnarly, and why compiler code generation can be such a joy.

I know that there was quite some effort before VAX and Alpha was
somewhat unified. Never knew much of the details, but I see that I'm
getting some of that now.

> There's sketchy Y2K-era timekeeping and time-drifting code around and
> still in use, too. Apps that haven't been remediated to deal correctly
> with daylight saving time changes, mostly.

Meh. Tell me about it. Same mess in RSX.

> That VAX code-optimization work has become needed less often in recent
> times particularly as the compilers address much of that, though there
> are still performance-sensitive code paths in some apps. Just not as
> widespread as on VAX.

I would hope that they are working on getting rid of this stuff as they
port things.

>> 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.
>
> Which is why I've been known to grumble about itemlists and descriptors
> and related abstractions, too. Itemlists and descriptors were great for
> the 1980s and 1990s, but are increasingly limiting what changes can be
> made to OpenVMS APIs.

Descriptors, if we talk about the kind used for strings, are not
unreasonable. But it seems a lot of the extensions to VMS over the years
have made things more complicated.

>>> Hoff: 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.
>
> It's another of design compromises intended to reduce or avoid overhead.
> VAX/VMS had those. All operating systems have those.

Different mode code to provide services and/or libraries not exactly in
user space are definitely common. And I do give such code more leeway,
since commonly they might be shipped with the OS itself, and as such,
are in sync with other internal bits, or else have other APIs used
internally, for which other rules apply anyway.

> TL;DR: Yes, there are outer-mode apps that read directly from inner-mode
> memory.

Check. That's the thing that surprised me. Especially since that's not
happening in RSX, unless you have a privileged program which is mapped
to the kernel. But such a program is already not very normal anyway, and
not something any normal user can write or run (well, of course they can
write it, but they can't actually run it.)

Johnny

On 2022-08-13 22:54, Scott Dorsey wrote:
> Although people in this newsgroup keep referring to itanium as a risc machine,
> it's not at all a risc machine. It's a VLIW architecture where the instruction
> actually sets the bits to route the data within the processor rather than just
> saying what operations to perform. That is, it's basically microcode instead
> of a normal operating instruction code.

I wouldn't agree with that. Yes, it's not really RISC, and yes, it's
most definitely VLIW.
However, you have a clear set of defined opcodes, with arguments, and
all that stuff. No different than any other processor. It's just that
because of the long word, you stuff multiple instructions into one word,
and then you get to the point of all the rules of which instructions can
actually be combined in one word, since you do not have enough execution
units to perform all the operations for all the instructions in one word
in parallel. This is where scheduling comes in, and with VLIW, it was
thought that the compiler can work this out, reorder code, and come up
with the optimal ordering and combination of things to do to maximize
the utilization of the execution units.

As opposed to the Alpha, for example, which instead dynamically can
reorder instructions to keep all execution units busy.

The Alpha thus is more complex in the silicon, since the rescheduling
and resource allocation, along with making it behave somewhat correct,
is pretty complex. On the other hand, the compile don't really have to
be so clever.

And it turned out that statically working this out isn't only a bit too
complex in the generic case. It's not even very possible when you have
unknown (at compile time) work to do.

The dynamic rescheduling deals with this much better. In addition, with
VLIW, you are getting to the same problem some other RISC CPUs exposed,
where things like the delayed branch slot, while considered a great idea
at one point, became one of the worst achilles heels of the SPARC later
on, since every implementation had to implement that same behavior, even
when it was no longer needed.

VLIW is bad in that way that if you would want to add more execution
units, and more instructions into the word, you just can't. You are
locking yourself into the current design limits, based on current
technology, making future development very hard.

It's just a dead end, except for more specialized problems, where it
works well. What Alpha did was actually the right thing. But that whole
thing is moot now. We have x86, which have been poured so much resources
on that it's hard to displace. ARM seems to be the only realistic
alternative still around. ARM on the other hand, can potentially benefit
from at least some of the same solutions that Alpha had.

Johnny

On Saturday, August 13, 2022 at 2:35:11 PM UTC-7, Johnny Billquist wrote:

(snip)

> It's just a dead end, except for more specialized problems, where it
> works well. What Alpha did was actually the right thing. But that whole
> thing is moot now. We have x86, which have been poured so much resources
> on that it's hard to displace. ARM seems to be the only realistic
> alternative still around. ARM on the other hand, can potentially benefit
> from at least some of the same solutions that Alpha had.

I believe RISC-V is on its way to a realistic alternative, though
maybe not there yet.

By the way, since people asked about IA64 emulators, and the general
belief that they don't exist and are too difficult to do.

They do exist, and have for a long time. It's not that complex from this
point of view, but of course, performance is probably nowhere near where
anyone would actually want to use it for production.

See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/

Last updated in 2004. But that is how they developed all the tooling and
so on before they had actual hardware.

And to correct myself and others a little. IA84 isn't really just a VLIW
machine. It also incorporated EPIC, which is sortof an attempt at half
dynamically be able to figure out dynamically which bundles of
instructions could be parallelized.
See: https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing

It was still crap though.

Johnny

On 8/13/2022 6:33 PM, Johnny Billquist wrote:
> By the way, since people asked about IA64 emulators, and the general belief that
> they don't exist and are too difficult to do.
>
> They do exist, and have for a long time. It's not that complex from this point
> of view, but of course, performance is probably nowhere near where anyone would
> actually want to use it for production.
>
> See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/
>
> Last updated in 2004. But that is how they developed all the tooling and so on
> before they had actual hardware.
>
> And to correct myself and others a little. IA84 isn't really just a VLIW
> machine. It also incorporated EPIC, which is sortof an attempt at half
> dynamically be able to figure out dynamically which bundles of instructions
> could be parallelized.
> See: https://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing
>
> It was still crap though.
>
> Johnny
>

I seem to recall that at some point HP engineers tried to tell management that
VLIW was a bad idea, and another path (perhaps Alpha which they then had) should
be taken. HP management would not hear of it. Don't remember when this was.

--
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

In article <td98si$cvh$1@news.misty.com>, bqt@softjar.se (Johnny
Billquist) wrote:

> By the way, since people asked about IA64 emulators, and the
> general belief that they don't exist and are too difficult to do.
>
> They do exist, and have for a long time. It's not that complex from
> this point of view, but of course, performance is probably nowhere
> near where anyone would actually want to use it for production.
>
> See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/
>
> Last updated in 2004. But that is how they developed all the
> tooling and so on before they had actual hardware.

Is that page still up? I can't access it.

In 1999, when trying to port software to Windows Itanium, I had a copy of
Intel's emulator for Windows. It was ... slow. Too slow to actually be
useful for software development, never mind production. Part of this was
because it ran on 32-bit x86. It could have run faster on Alpha, but
Intel said "they couldn't do that, could they?"

Intel thought of it as the fast simulator, because it didn't do
gate-level emulation. Heaven knows how slow that was. One of the early
indicators of problems with the project was their answer which I asked if
the emulator was generated from the formal model of the processor. They
didn't understand the question.

John

On 2022-08-14 11:02, John Dallman wrote:
> In article <td98si$cvh$1@news.misty.com>, bqt@softjar.se (Johnny
> Billquist) wrote:
>
>> By the way, since people asked about IA64 emulators, and the
>> general belief that they don't exist and are too difficult to do.
>>
>> They do exist, and have for a long time. It's not that complex from
>> this point of view, but of course, performance is probably nowhere
>> near where anyone would actually want to use it for production.
>>
>> See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/
>>
>> Last updated in 2004. But that is how they developed all the
>> tooling and so on before they had actual hardware.
>
> Is that page still up? I can't access it.

It works for me. No idea what the problem might be for you.

> In 1999, when trying to port software to Windows Itanium, I had a copy of
> Intel's emulator for Windows. It was ... slow. Too slow to actually be
> useful for software development, never mind production. Part of this was
> because it ran on 32-bit x86. It could have run faster on Alpha, but
> Intel said "they couldn't do that, could they?"

:-)
But I think performance wouldn't exactly have been great on an Alpha
either. Better, but not useful.

> Intel thought of it as the fast simulator, because it didn't do
> gate-level emulation. Heaven knows how slow that was. One of the early
> indicators of problems with the project was their answer which I asked if
> the emulator was generated from the formal model of the processor. They
> didn't understand the question.

I would sortof have expected that they'd know and would have answered
"no". But not even understanding the question would be a bad sign
indeed. I wonder if they had a formal model even.

Johnny

Den 2022-08-14 kl. 12:10, skrev Johnny Billquist:
> On 2022-08-14 11:02, John Dallman wrote:
>> In article <td98si$cvh$1@news.misty.com>, bqt@softjar.se (Johnny
>> Billquist) wrote:
>>
>>> By the way, since people asked about IA64 emulators, and the
>>> general belief that they don't exist and are too difficult to do.
>>>
>>> They do exist, and have for a long time. It's not that complex from
>>> this point of view, but of course, performance is probably nowhere
>>> near where anyone would actually want to use it for production.
>>>
>>> See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/
>>>
>>> Last updated in 2004. But that is how they developed all the
>>> tooling and so on before they had actual hardware.
>>
>> Is that page still up? I can't access it.
>
> It works for me. No idea what the problem might be for you.

Doesn't work for me. Gives "www.irisa.fr doesn't respond".

First hit when googling "irisa" is www.irisa.fr, but doesn't work either.

On 2022-08-14 14:28, Jan-Erik Söderholm wrote:
> Den 2022-08-14 kl. 12:10, skrev Johnny Billquist:
>> On 2022-08-14 11:02, John Dallman wrote:
>>> In article <td98si$cvh$1@news.misty.com>, bqt@softjar.se (Johnny
>>> Billquist) wrote:
>>>
>>>> By the way, since people asked about IA64 emulators, and the
>>>> general belief that they don't exist and are too difficult to do.
>>>>
>>>> They do exist, and have for a long time. It's not that complex from
>>>> this point of view, but of course, performance is probably nowhere
>>>> near where anyone would actually want to use it for production.
>>>>
>>>> See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/
>>>>
>>>> Last updated in 2004. But that is how they developed all the
>>>> tooling and so on before they had actual hardware.
>>>
>>> Is that page still up? I can't access it.
>>
>> It works for me. No idea what the problem might be for you.
>
> Doesn't work for me. Gives "www.irisa.fr doesn't respond".
>
> First hit when googling "irisa" is www.irisa.fr, but doesn't work either.

Seems to have stopped working for me as well now.
I got the link from the Itanium wikipedia page.

Well, there is always the wayback machine (those people should really
get some kudos...)

https://web.archive.org/web/20220410003719/http://www.irisa.fr/caps/projects/ArchiCompil/iato/

Johnny

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?
> 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

Based on a review of object code generated for this machine by a certain C compiler, I'd say you need only one instruction: NOP

In article <td9q3r$32ah0$1@dont-email.me>, davef@tsoft-inc.com (Dave
Froble) wrote:

> I seem to recall that at some point HP engineers tried to tell
> management that VLIW was a bad idea, and another path (perhaps
> Alpha which they then had) should be taken. HP management would
> not hear of it. Don't remember when this was.

That's consistent with HP management's behaviour in 2002-04, when it was
becoming clear that (a) Intel's plan to replace x86 with Itanium had been
wrecked by AMD's x86-64 and (b) making Windows and HP-UX software run
fast on Itanium was quite hard. At this point, HP made a lot of noise
about how they were "Betting the company on Itanium" and quite a few
companies felt they needed to become less reliant on HP.

Later on, an HP person said "You're biased against Itanium!" and our
chief of operations responded "We think of ourselves as well-informed."

John

I am still convinced that running HP_UX on an Itanium emulator, not
messing with code, applications etc, would be a better option than
trying to port to another Unix-like OS.
Perhaps not so for OpenVMS. But on the other hand, there are many
companies out there just using OpenVMS; their app vendors have either
gone out of business or stopped supporting OpenVMS all together on ANY
platform. An emulator with decent performance would be better than the
many 100,000s of dollars to port to a new OS. And yes, from the people I
have talked to, there is nothing cheap about any work done in the
OpenVMS market.
A $10K emulator that performs efficiently and fast, would still be
cheaper than going with any unnecessary hardware or OS upgrades. I think
AlphaVM-Pro VTALpha and Cahron-Alpha have all proven that fact.

DT

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.
>
>
> David Turner
>
>

On 8/14/2022 2:19 PM, David Turner wrote:
> I am still convinced that running HP_UX on an Itanium emulator, not
> messing with code, applications etc, would be a better option than
> trying to port to another Unix-like OS.
> Perhaps not so for OpenVMS. But on the other hand, there are many
> companies out there just using OpenVMS; their app vendors have either
> gone out of business or stopped supporting OpenVMS all together on ANY
> platform. An emulator with decent performance would be better than the
> many 100,000s of dollars to port to a new OS. And yes, from the people I
> have talked to, there is nothing cheap about any work done in the
> OpenVMS market.
> A $10K emulator that performs efficiently and fast, would still be
> cheaper than going with any unnecessary hardware or OS upgrades. I think
> AlphaVM-Pro VTALpha and Cahron-Alpha have all proven that fact.

Obviously the situation for HP-UX is a lot different than
for VMS.

VMS has a company dedicated to it. VMS has been ported to x86-64.

HP-UX got neither of those. Unless HPE does something then HP-UX is
stuck on Itanium and current functionality.

But I also suspect that the typical HP-UX site is a lot easier
to migrate than the typical VMS site.

Macro-11, VMS Pascal and VMS Basic are a rewrite from scratch
on Linux. All LIB$ and SYS$ calls would need to be changed
on Linux no matter the language. Lots of VMS concepts are not 1:1
portable to Linux including logical names and queue system.
Rdb is not available on Linux. RMS index-sequential files
would (except for Cobol) require a third party software solution
and change of calls to use API of that. No DCL on Linux so all
script would be rewrite from scratch. VMS to Linux is not easy - not
impossible either but expensive and risky.

I believe a lot of HP-UX systems are database servers running
Oracle DB, Sybase ASE etc. - and those are available on
Linux (in fact the vendors would like to see customers migrate
to Linux). Most application code would be C/C++ and Cobol
which are respectively available by default and available for
a price on Linux. Most programming concepts and system
calls would work on Linux. The shells used would be available
on Linux. HP-UX to Linux would not be trivial - definitely a
huge project, but both risk and cost seems significant lower
than VMS to Linux.

Arne

gah4 <gah4@u.washington.edu> writes:

> 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.)

ITYM, actually IKYM DOS/360 here.

> 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.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

David Turner <dturner@islandco.com> wrote:
>I am still convinced that running HP_UX on an Itanium emulator, not
>messing with code, applications etc, would be a better option than
>trying to port to another Unix-like OS.

HP-UX really is Unix. If the code is well-written, it should not be
difficult to port to any other SysV-like Unix. Realtime code excepted
perhaps.

>Perhaps not so for OpenVMS. But on the other hand, there are many
>companies out there just using OpenVMS; their app vendors have either
>gone out of business or stopped supporting OpenVMS all together on ANY
>platform. An emulator with decent performance would be better than the
>many 100,000s of dollars to port to a new OS. And yes, from the people I
>have talked to, there is nothing cheap about any work done in the
>OpenVMS market.

OpenVMS is not Unixlike and porting OpenVMS code to Unix-like systems is
frequently problematic. Which is why x86 VMS is such a great idea. In
most cases this involves a complete rewrite rather than a port.

>A $10K emulator that performs efficiently and fast, would still be
>cheaper than going with any unnecessary hardware or OS upgrades. I think
>AlphaVM-Pro VTALpha and Cahron-Alpha have all proven that fact.

I don't think an IA64 emulator that performs efficiently and fast is even
feasible. Making it reliable is still more difficult. It's not like
emulating a normal architecture like Alpha.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

> A $10K emulator that performs efficiently and fast, would still be
> cheaper than going with any unnecessary hardware or OS upgrades. I think
> AlphaVM-Pro VTALpha and Cahron-Alpha have all proven that fact.
>
> DT

No to be picky, but the Stromasys product is called Charon/AXP.

Dan

(Currently working for Stromasys)

In article <tdbn3s$3v3$1@gioia.aioe.org>, arne@vajhoej.dk (Arne Vajh�j)
wrote:

> Unless HPE does something then HP-UX is stuck on Itanium and
> current functionality.

I've been watching for that for years. There were rumours during the
HP-Oracle lawsuit that HP had investigated porting HP-UX to x86-64, but
nothing came of them. HP has been running Linux for years on its high-end
"Superdome" x86-64 systems. They haven't said anything to indicate that
HP-UX will have a life after the end of Itanium support in 2025 AFAIK.

> But I also suspect that the typical HP-UX site is a lot easier
> to migrate than the typical VMS site.

You're right. HP-UX has a few quirks of its own, but it isn't
fundamentally hard to port from it to Linux.

John

On 2022-08-12, Johnny Billquist <bqt@softjar.se> wrote:
> 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.
>

As you now know Johnny, you were (once again) very very wrong to try
and compare the two. :-)

BTW, the fact you immediately switched to talking about kernel mode,
makes me wonder if you are even aware of P1 space in a VMS process.

> There is absolutely nothing Unix/Linux specific about this.
>

Oh yes there is.

Unix/Linux sets up a new process to run an image and then deletes
it immediately afterwards and has no such thing as P1 space.

A normal VMS session only ever has one process that is reused over
and over again to run programs (unless you choose to start a subprocess
for some reason.)

Simon.

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

On 2022-08-13, gah4 <gah4@u.washington.edu> wrote:
> On Saturday, August 13, 2022 at 2:35:11 PM UTC-7, Johnny Billquist wrote:
>
> (snip)
>
>> It's just a dead end, except for more specialized problems, where it
>> works well. What Alpha did was actually the right thing. But that whole
>> thing is moot now. We have x86, which have been poured so much resources
>> on that it's hard to displace. ARM seems to be the only realistic
>> alternative still around. ARM on the other hand, can potentially benefit
>> from at least some of the same solutions that Alpha had.
>
> I believe RISC-V is on its way to a realistic alternative, though
> maybe not there yet.
>

I keep looking at RISC-V. I will become _much_ more interested when
you can get a RISC-V board at Raspberry Pi or BeagleBone Black prices
and with the capabilities of those boards.

Once it reaches that level, that's when it is _really_ going to take
off (IMHO), but it's not there yet.

As with the ARM stuff, you need that price/functionality point to get
enough people to start playing with them to build a critical mass of
interested people.

Simon.

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

On 2022-08-13, Johnny Billquist <bqt@softjar.se> wrote:
> By the way, since people asked about IA64 emulators, and the general
> belief that they don't exist and are too difficult to do.
>
> They do exist, and have for a long time. It's not that complex from this
> point of view, but of course, performance is probably nowhere near where
> anyone would actually want to use it for production.
>
> See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/
>
> Last updated in 2004. But that is how they developed all the tooling and
> so on before they had actual hardware.
>

I've just had a quick look at this. This emulator is no good for VMS.

From the documentation:

|The IATO environment operates directly with ELF binary executables. As of
|release 1.0, fully static binary executables are only supported. In the
|presence of dynamically linked executables, the IATO clients reports an
|error and terminates. The best method to check for a file type is to use
|the file command

It's an user-level binary emulator only and it doesn't even support dynamic
binaries.

Also:

|3.4 Kernel emulation library
|The kernel (KRN) library is a set of classes that handles Linux system
|calls. Systems calls are vectored traps sent by the program. They are
|caught by the emulator or the simulator and routed to the system call
|handler. The Syscall class encapsulates all Linux system calls. Note that a
|system call argument mapping procedure is also included into this library.

And it only supports Linux syscalls.

Simon.

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

On 8/15/2022 1:47 PM, Simon Clubley wrote:
> On 2022-08-13, Johnny Billquist <bqt@softjar.se> wrote:
>> By the way, since people asked about IA64 emulators, and the general
>> belief that they don't exist and are too difficult to do.
>>
>> They do exist, and have for a long time. It's not that complex from this
>> point of view, but of course, performance is probably nowhere near where
>> anyone would actually want to use it for production.
>>
>> See: http://www.irisa.fr/caps/projects/ArchiCompil/iato/
>>
>> Last updated in 2004. But that is how they developed all the tooling and
>> so on before they had actual hardware.
>>
>
> I've just had a quick look at this. This emulator is no good for VMS.
>
> From the documentation:
>
> |The IATO environment operates directly with ELF binary executables. As of
> |release 1.0, fully static binary executables are only supported. In the
> |presence of dynamically linked executables, the IATO clients reports an
> |error and terminates. The best method to check for a file type is to use
> |the file command
>
> It's an user-level binary emulator only and it doesn't even support dynamic
> binaries.
>
> Also:
>
> |3.4 Kernel emulation library
> |The kernel (KRN) library is a set of classes that handles Linux system
> |calls. Systems calls are vectored traps sent by the program. They are
> |caught by the emulator or the simulator and routed to the system call
> |handler. The Syscall class encapsulates all Linux system calls. Note that a
> |system call argument mapping procedure is also included into this library.
>
> And it only supports Linux syscalls.
>
> Simon.
>

Can't everybody just let the itanic boat anchor sink quietly into the mud, never
to be seen again?

I'm also a bit surprised by David's question. I was under the impression that
there were many discarded itanics, available rather cheap. What has changed?

The one I have cost exactly $0, and I rarely run 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-08-13, Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-08-13 02:21, Stephen Hoffman wrote:
>> 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.
>

On VMS, there is no such thing as a normal user process.

There is one process that at various times during its lifecycle
executes a mixture of code running in all four modes (KESU).

As such, the supervisor mode code and data structures are part of
the same address space as the user-mode programs. It's just that
most of it is not directly accessible to user-mode programs due
to page protections.

My opinions about whether I think this is a good idea these days
have already been discussed at length. :-)

BTW, are you aware that on VMS, a normal user program can execute
a function within that same program in kernel mode provided it has
sufficient privileges ?

I don't mean jump into the kernel address space, but to actually
execute a function within the program with kernel-mode access.

Simon.

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