On 2022-08-14 14:28, Jan-Erik Söderholm wrote:
Doesn't work for me. Gives "www.irisa.fr doesn't respond".
First hit when googling "irisa" is www.irisa.fr, but doesn't workSeems to have stopped working for me as well now.
either.
I got the link from the Itanium wikipedia page.
In article <tdaror$bap$1@news.misty.com>, bqt@softjar.se (Johnny
Billquist) wrote:
On 2022-08-14 14:28, Jan-Erik Söderholm wrote:
Doesn't work for me. Gives "www.irisa.fr doesn't respond".Seems to have stopped working for me as well now.
First hit when googling "irisa" is www.irisa.fr, but doesn't work
either.
I got the link from the Itanium wikipedia page.
Working now, and I took the chance to grab all the files.
Is this a full-system emulator or just a CPU emulator ?
[From what I can tell from the webpage, it appears to be another CPU
emulator only, just like Ski.]
If the documentation is correct, then making an IA64 VMS emulator for
x96-64 VMS would require, at least:
* Extending the ELF library to cope with dynamically linked executables
and libraries.
* Creating a system call translation layer for VMS. This would be a lot
easier with the VMS source available.
* Fixing bugs that doubtless exist in the libraries.
* Getting the instruction set library to run at a reasonable speed.
On 2024-02-27, John Dallman <jgd@cix.co.uk> wrote:
If the documentation is correct, then making an IA64 VMS emulator for
x96-64 VMS would require, at least:
* Extending the ELF library to cope with dynamically linked executables
and libraries.
* Creating a system call translation layer for VMS. This would be a lot
easier with the VMS source available.
* Fixing bugs that doubtless exist in the libraries.
* Getting the instruction set library to run at a reasonable speed.
So direct execution of some standalone Itanium VMS user-mode executables might be possible with enough effort, but no running Itanium VMS as an
entity in its own right.
It really does speak to how complex the Itanium architecture is that
nobody has ever done an Itanium full-system emulator. :-)
On 2024-02-27, John Dallman <jgd@cix.co.uk> wrote:
If the documentation is correct, then making an IA64 VMS emulator for
x96-64 VMS would require, at least:
* Extending the ELF library to cope with dynamically linked executables
and libraries.
* Creating a system call translation layer for VMS. This would be a lot
easier with the VMS source available.
* Fixing bugs that doubtless exist in the libraries.
* Getting the instruction set library to run at a reasonable speed.
Thanks John.
So direct execution of some standalone Itanium VMS user-mode executables might be possible with enough effort, but no running Itanium VMS as an
entity in its own right.
It really does speak to how complex the Itanium architecture is that
nobody has ever done an Itanium full-system emulator. :-)
Simon.
Before it was considered a bad idea, it was still available. They are still >available used. I got one which hasn't been powered on in months. Want it?
Emulators allowed use of discontinued architectures that people actually wanted
to run. I don't know anyone who really wants to run an itanic. Do you?
On 2/28/2024 1:03 PM, Simon Clubley wrote:
On 2024-02-27, John Dallman <jgd@cix.co.uk> wrote:
If the documentation is correct, then making an IA64 VMS emulator for
x96-64 VMS would require, at least:
* Extending the ELF library to cope with dynamically linked executables
  and libraries.
* Creating a system call translation layer for VMS. This would be a lot
  easier with the VMS source available.
* Fixing bugs that doubtless exist in the libraries.
* Getting the instruction set library to run at a reasonable speed.
So direct execution of some standalone Itanium VMS user-mode executables
might be possible with enough effort, but no running Itanium VMS as an
entity in its own right.
It really does speak to how complex the Itanium architecture is that
nobody has ever done an Itanium full-system emulator. :-)
That and lack of demand (demand = businesses willing to
pay for such an emulator not hobbyists that think it could
be fun with such an emulator).
Maybe it will change. HP-UX is not being ported to x86-64
as far as I know, so *if* some businesses do not want to
migrate from HP-UX/Itanium to Linux/x86-64, then demand
for an Itanium emulator may rise.
(note the *if* - I don't know any HP-UX people)
Arne Vajhøj schrieb am 28.02.2024 um 20:20:
Maybe it will change. HP-UX is not being ported to x86-64
as far as I know, so *if* some businesses do not want to
migrate from HP-UX/Itanium to Linux/x86-64, then demand
for an Itanium emulator may rise.
(note the *if* - I don't know any HP-UX people)
Well... I know VMS customers who stepped back from Itanium to Alpha
because an Alpha emulator was available (they used a specific PCI(e)
card for their application).
HP-UX customers could step back to PA-RISC instead of porting to Linux. Stromasys offers a PA-RISC emulator.
Maybe it will change. HP-UX is not being ported to x86-64
as far as I know, so *if* some businesses do not want to
migrate from HP-UX/Itanium to Linux/x86-64, then demand
for an Itanium emulator may rise.
Well, that's sort of the thing. MAYBE the Itanium might actually
have been a viable architecture if the compilers could have been
made smart enough. But this turned out to be a whole lot harder
than the Intel crew expected.
In article <uro126$1pab$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
Maybe it will change. HP-UX is not being ported to x86-64
as far as I know, so *if* some businesses do not want to
migrate from HP-UX/Itanium to Linux/x86-64, then demand
for an Itanium emulator may rise.
HP-UX isn't all that different from Linux, and I seriously doubt there
would be enough businesses that want to stay with HP-UX badly enough.
In article <urq94k$m8rf$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
On 2/29/2024 3:06 AM, John Dallman wrote:
HP-UX isn't all that different from Linux, and I seriously doubtPeople liking HP-UX and liking Itanium may be a very small group.
there would be enough businesses that want to stay with HP-UX
badly enough.
"Liking" doesn't mean so much when lots of money is involved. A decade
ago, a fair few people may have expressed loyalty to HP-UX/Itanium, but
it was obvious then that it wasn't going to grow, and the writing has
been on the wall for Itanium since 2019.
Moving almost any kind of HP-UX software to Linux is much easier than
moving VMS software that uses VMS hard to anything else.
John
On 2/29/2024 3:06 AM, John Dallman wrote:
HP-UX isn't all that different from Linux, and I seriously doubtPeople liking HP-UX and liking Itanium may be a very small group.
there would be enough businesses that want to stay with HP-UX
badly enough.
What would be the point?
Before it was considered a bad idea, it was still available. They are still available used. I got one which hasn't been powered on in months. Want it?
Emulators allowed use of discontinued architectures that people actually wanted
to run. I don't know anyone who really wants to run an itanic. Do you?
In article <uroeg8$b8$1@panix2.panix.com>, kludge@panix.com (Scott Dorsey) wrote:
Well, that's sort of the thing. MAYBE the Itanium might actually
have been a viable architecture if the compilers could have been
made smart enough. But this turned out to be a whole lot harder
than the Intel crew expected.
No, it couldn't. The problem is the delays in accessing memory.
EPIC requires the compilers to issue speculative loads far enough in
advance to keep the processor from stalling waiting for memory for most
of the time. However, that doesn't work: the information isn't available enough of the time. The compiler also doesn't know what's in what level
of cache, because it's /impossible/ to know that when code is running on
a multi-tasking OS that is taking interrupts.
Out-of-order execution, as used on modern x86 processors (and ARM, POWER,
IBM Z, and anything else that's still competitive) deals with the memory
and cache problems by letting the data dependencies for instructions be resolved dynamically as data arrives. This works much better.
EPIC only made sense in a system that was running a single process and
taking few, if any, interrupts. That was how early embedded systems,
which were Intel's original market, worked in the 1970s and early 1980s. Trying to apply that to a processor that appeared in 2001 was a massive failure of concept and project management. Itanium was obsolete when it shipped.
John
In article <urq94k$m8rf$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
On 2/29/2024 3:06 AM, John Dallman wrote:
HP-UX isn't all that different from Linux, and I seriously doubtPeople liking HP-UX and liking Itanium may be a very small group.
there would be enough businesses that want to stay with HP-UX
badly enough.
"Liking" doesn't mean so much when lots of money is involved. A decade
ago, a fair few people may have expressed loyalty to HP-UX/Itanium, but
it was obvious then that it wasn't going to grow, and the writing has
been on the wall for Itanium since 2019.
Moving almost any kind of HP-UX software to Linux is much easier than
moving VMS software that uses VMS hard to anything else.
Yes, and while I've never been in this situation, some users must
have well documented testing and validation of their software.
This can involve large amounts of that money you mention. It could
be possible for some that just about anything is cheaper than a new validation job.
It would be my guess that anyone is such a situation just might
have the re-validation to do if switching to an emulator.
Since IA64 was really in its infancy when Intel acquired Alpha
(rather was forced to acquire Alpha due to legal issues), Intel
could have decided to drop IA64 and go full speed with next gen
Alpha development. But, from what I heard, there was a lot of
"not invented here" culture in Intel, so Alpha dev was pushed
to the side.
And then IA64 was something like 6 or 7 years late to the market,
which, by this time, x86-64 was out and about, so IA64 never
really recovered ..
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 432 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 31:09:56 |
| Calls: | 9,081 |
| Calls today: | 4 |
| Files: | 13,409 |
| Messages: | 6,022,251 |