HP's Q&A about OpenVMS, x86-64, and Itanium

[Yousuf Khan]

Terry Shannon recently did an interview about the future directions of
OpenVMS. HP strongly denies they will ever port their OpenVMS operating
system over to x86 extensions (AMD64, EM64T) from Itanium. Of course, just a
few months ago, they were strongly denying that they would ever use AMD64
systems at all, just a few weeks before announcing the biggest roll-out of
Opteron servers that AMD has seen so far. Also HP says that it doesn't need
a contingency plan in case Itanium fails, because "leading industry analysts
see the success of Itanium as being inevitable."

http://www.shannonknowshpc.com/stories.php?story=04/06/09/3222020

Yousuf Khan

 

[Nick Maclaren]

|> ... Also HP says that it doesn't need
|> a contingency plan in case Itanium fails, because "leading industry analysts
|> see the success of Itanium as being inevitable."

Ah. The doctrine of Historical Inevitability. How nice to see
such, er, interesting philosophies being preserved.


Regards,
Nick Maclaren.

 

[George Macdonald]

Terry Shannon recently did an interview about the future directions of
OpenVMS. HP strongly denies they will ever port their OpenVMS operating
system over to x86 extensions (AMD64, EM64T) from Itanium. Of course, just a
few months ago, they were strongly denying that they would ever use AMD64
systems at all, just a few weeks before announcing the biggest roll-out of
Opteron servers that AMD has seen so far. Also HP says that it doesn't need
a contingency plan in case Itanium fails, because "leading industry analysts
see the success of Itanium as being inevitable."

So HP is basing its projections on the prognostications of "leading
industry analysts" now?? Am I missing something here? I though that it
was.... oh never mind!

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Casper H.S. Dik]

Terry Shannon recently did an interview about the future directions of
OpenVMS. HP strongly denies they will ever port their OpenVMS operating
system over to x86 extensions (AMD64, EM64T) from Itanium. Of course, just a
few months ago, they were strongly denying that they would ever use AMD64
systems at all, just a few weeks before announcing the biggest roll-out of
Opteron servers that AMD has seen so far. Also HP says that it doesn't need
a contingency plan in case Itanium fails, because "leading industry analysts
see the success of Itanium as being inevitable."

Perhaps they can send some of the leading industry experts to PTC:

http://www.ptc.com/partners/hardware/current/itanium_letter.htm

Casper

 

[Robert Myers]

Perhaps they can send some of the leading industry experts to PTC:

http://www.ptc.com/partners/hardware/current/itanium_letter.htm

So when do we expect x86-64 emulation for Itanium?

RM

 

[Bill Todd]

So when do we expect x86-64 emulation for Itanium?

I'd say probably not before they get its vanilla-x86 emulation up to snuff -
i.e., probably never.

- bill

 

[Yousuf Khan]

So HP is basing its projections on the prognostications of "leading
industry analysts" now?? Am I missing something here? I though that
it was.... oh never mind!

Nah, I think this is HP's way of saying to expect OpenVMS for AMD64 to be
announced soon.

Yousuf Khan

 

[Bill Todd]

Perhaps they can send some of the leading industry experts to PTC:

http://www.ptc.com/partners/hardware/current/itanium_letter.htm

Oh, dear - how embarrassingly public and direct. One suspects that this
particular departing rat may never have been all that enthused about Itanic
in the first place - or at least became unenthused after acquiring direct
experience with it.

- bill

 

[Nick Maclaren]

|>
|> > So when do we expect x86-64 emulation for Itanium?
|>
|> I'd say probably not before they get its vanilla-x86 emulation up to snuff -
|> i.e., probably never.

I am speculating that the much-replicated Alpha engineers and the
most innovative Intel ones are designing a completely new range
for 2007/8, and that this will be microcoded (like the Banias and
Pentium 4). It will come in Itanium, x86-64 and possibly other
flavours, and possibly be able to switch between them dynamically.
Combine that with multiple cores, and you have an interesting
basis for a self-configuring system


Regards,
Nick Maclaren.

 

[chrisv]

Also HP says that it doesn't need
a contingency plan in case Itanium fails, because "leading industry analysts
see the success of Itanium as being inevitable."

*scoff*

 

[Tony Hill]

Terry Shannon recently did an interview about the future directions of
OpenVMS. HP strongly denies they will ever port their OpenVMS operating
system over to x86 extensions (AMD64, EM64T) from Itanium. Of course, just a
few months ago, they were strongly denying that they would ever use AMD64
systems at all, just a few weeks before announcing the biggest roll-out of
Opteron servers that AMD has seen so far. Also HP says that it doesn't need
a contingency plan in case Itanium fails, because "leading industry analysts
see the success of Itanium as being inevitable."

Haha, somehow I'm not at all surprised that HP is placing it's faith
in "industry analysts"! Having recently gained some exposure to the
inner workings of HP, I can say without a doubt that it's one of the
most confused and disorganized companies out there and they've got a
lot of the wrong people making decisions.

I don't know if the old Packard family was right about the merger with
Compaq being a bad idea, or if things were this bad before the merger,
but HP is definitely suffering from schizophrenia at this stage.
Basing your product lines on the whims of some analyst is perhaps the
best proof that no one is home in upper management!

 

[David Svensson]

|>
|> > So when do we expect x86-64 emulation for Itanium?
|>
|> I'd say probably not before they get its vanilla-x86 emulation up to snuff -
|> i.e., probably never.

I am speculating that the much-replicated Alpha engineers and the
most innovative Intel ones are designing a completely new range
for 2007/8, and that this will be microcoded (like the Banias and
Pentium 4). It will come in Itanium, x86-64 and possibly other
flavours, and possibly be able to switch between them dynamically.
Combine that with multiple cores, and you have an interesting
basis for a self-configuring system

There is some speculation, and some facts(?) here.

http://pc.watch.impress.co.jp/docs/2004/0305/kaigai070.htm

http://babelfish.altavista.com/babe...s.co.jp/docs/2004/0305/kaigai070.htm&lp=ja_en

 

[Nick Maclaren]

There is some speculation, and some facts(?) here.

http://pc.watch.impress.co.jp/docs/2004/0305/kaigai070.htm

http://babelfish.altavista.com/babe...s.co.jp/docs/2004/0305/kaigai070.htm&lp=ja_en

Thanks very much. Unfortunately, I don't read Japanese, and decoding
the Janglish will take me a little time. But it would not be the
first time that the Japanese put two and two together a long time before
anyone in the West did ....


Regards,
Nick Maclaren.

 

[Brannon Batson]

|>
|> > So when do we expect x86-64 emulation for Itanium?
|>
|> I'd say probably not before they get its vanilla-x86 emulation up to snuff -
|> i.e., probably never.

I am speculating that the much-replicated Alpha engineers and the
most innovative Intel ones are designing a completely new range
for 2007/8, and that this will be microcoded (like the Banias and
Pentium 4). It will come in Itanium, x86-64 and possibly other
flavours, and possibly be able to switch between them dynamically.
Combine that with multiple cores, and you have an interesting
basis for a self-configuring system

I have no idea what this paragraph means.

Also, Why do you consider microcode a step forward?

Brannon
not speaking for Intel

 

[Nick Maclaren]

I have no idea what this paragraph means.

I have no idea why not

I will try a rephrasing. My guess is that the new design will have
an inner core and infrastructure (memory management, CPU-CPU links
etc.) that is not directly programmable by at least unprivileged
code. There will be another layer that translates the ISAs it
supports into code that executes on the inner core, though I can't
guess which of the many technologies to do that will be used, and
have little idea whether a chip will be fixed in an ISA mode during
manufacture or be changeable later.

All of the definitions of microcode that I have seen that exclude
the Pentium 4 have been revisionist marketing. In the 1960s and
1970s, it would have been classified as an advanced microcoded
design.

But, as I said, there are considerable advantages to NOT fixing it
during manufacture, as it would allow Intel to build boards or even
systems that could be IPLed as IA-64, x86-64 or whatever servers.
Surely I don't have to explain the advantages of that?

Also, Why do you consider microcode a step forward?

Why do you assume that I regard future developments to be necessarily
a step forward?

But, as I have posted before, microcode (preferably of the advanced
Pentium 4 or Crusoe type) would allow an ISA to be designed with
application/compiler constraints foremost, while still having an
execution engine that was designed with hardware constraints foremost.
This could be used to increase reliability.


Regards,
Nick Maclaren.

 

[Per =?ISO-8859-1?Q?Schr=F6der?=]

I am speculating that the much-replicated Alpha engineers and the
most innovative Intel ones are designing a completely new range
for 2007/8, and that this will be microcoded (like the Banias and
Pentium 4).  It will come in Itanium, x86-64 and possibly other
flavours, and possibly be able to switch between them dynamically.
Combine that with multiple cores, and you have an interesting
basis for a self-configuring system

Cool! Like what PR1ME did. Maybe the new Intel chips will be able to emulate
Honeywells too. Maybe we could reinvent microcode with JIT compiling (where
did I hear that last...)? ;-)

http://www.malch.com/prime/primefaq.htm#L2_18

/Per Schröder

 

[Brannon Batson]

|>
|> > So when do we expect x86-64 emulation for Itanium?
|>
|> I'd say probably not before they get its vanilla-x86 emulation up to snuff -
|> i.e., probably never.

[snip]

I have no idea what this paragraph means.

I have no idea why not

I will try a rephrasing. My guess is that the new design will have
an inner core and infrastructure (memory management, CPU-CPU links
etc.) that is not directly programmable by at least unprivileged
code. There will be another layer that translates the ISAs it
supports into code that executes on the inner core, though I can't
guess which of the many technologies to do that will be used, and
have little idea whether a chip will be fixed in an ISA mode during
manufacture or be changeable later.

BB> Hardware hasn't done a great job of just in time compiling one ISA
into another in the past--are you expecting a breakthrough?

All of the definitions of microcode that I have seen that exclude
the Pentium 4 have been revisionist marketing. In the 1960s and
1970s, it would have been classified as an advanced microcoded
design.

BB> Microcode is used to emulate slow legacy things, more or less.
Anything that wants to be fast or power-efficient needs to run on
dedicated hardware.

But, as I said, there are considerable advantages to NOT fixing it
during manufacture, as it would allow Intel to build boards or even
systems that could be IPLed as IA-64, x86-64 or whatever servers.
Surely I don't have to explain the advantages of that?

BB> No, just let me know how to do it.

Why do you assume that I regard future developments to be necessarily
a step forward?

But, as I have posted before, microcode (preferably of the advanced
Pentium 4 or Crusoe type) would allow an ISA to be designed with
application/compiler constraints foremost, while still having an
execution engine that was designed with hardware constraints foremost.
This could be used to increase reliability.

BB> Programming languages are designed with application/compiler
constraints foremost, while still allowing code to be generated for an
efficient execution engine. That's the way it works now--and stuff
that isn't performance critical is slowly transitioning over to
portable, ISA-agnostic formats. What you are saying is that we put
the JIT in hardware--and then everybody can build into the same ISA.
The problem is that JIT's don't work as well as full compilers, JIT's
in hardware don't work as well as JIT's in software, and the
intermediate format causes important optimization information to be
lost. Come up with a solution to these problems and I'm on board.

Now if what you are advocating is a development framework which
further abstracts hardware from the people writing the software while
trying to recover as much performance as possible--that's hardly a
novel goal, but it's certainly noble.

As an aside--microcode on x86 and PAL code on IPF are used to add
features (reliability, security, and otherwise) and simplify the
implementation for things that can be slow.

Brannon
not speaking for Intel

 

[Stephen Sprunk]

(e-mail address removed) (Nick Maclaren) wrote in message

BB> Hardware hasn't done a great job of just in time compiling one ISA
into another in the past--are you expecting a breakthrough?

Well, Transmeta's doing a credible job of JITing x86 into VLIW, so
presumably they could have JITs for IA64 and AMD64 as well. That's also
rumored to be how future Itanics are going to handle x86 emulation (i.e.
FX!32); hopefully it'll be better than the direct hardware support of
earlier models...

Or perhaps all of the external ISAs could decode to a common set of uops?

BB> Programming languages are designed with application/compiler
constraints foremost, while still allowing code to be generated for an
efficient execution engine. That's the way it works now--and stuff
that isn't performance critical is slowly transitioning over to
portable, ISA-agnostic formats. What you are saying is that we put
the JIT in hardware--and then everybody can build into the same ISA.
The problem is that JIT's don't work as well as full compilers, JIT's
in hardware don't work as well as JIT's in software, and the
intermediate format causes important optimization information to be
lost. Come up with a solution to these problems and I'm on board.

HP's Dynamo supposedly got a 10% performance gain JITing PA-RISC binaries on
a PA-RISC processor, including overhead. While not proof of anything, even
maintaining native performance while under a JIT is damn impressive, and
that opens a lot of doors to runtime optimizations not possible in either
compilers or processors.

Now if what you are advocating is a development framework which
further abstracts hardware from the people writing the software while
trying to recover as much performance as possible--that's hardly a
novel goal, but it's certainly noble.

C simply exposes too much of the hardware; you may alter what's exposed to
the compiler and thus the programmer, but you have to expose something.

S

 

[Yousuf Khan]

Well, Transmeta's doing a credible job of JITing x86 into VLIW, so
presumably they could have JITs for IA64 and AMD64 as well. That's
also rumored to be how future Itanics are going to handle x86
emulation (i.e. FX!32); hopefully it'll be better than the direct
hardware support of earlier models...

From what I hear, Transmeta's VLIW is nothing like Itanium's VLIW.
Transmeta's VLIW is geared towards the emulation of x86 opcodes specifically
and nothing else.

Yousuf Khan

 

[Terje Mathisen]

Well, Transmeta's doing a credible job of JITing x86 into VLIW, so
presumably they could have JITs for IA64 and AMD64 as well. That's also

The relatively fast x86 emulation in Transmeta chips owe quite a lot to
the fact that the hw was intentionally designed to be superset of all
important x86 features, plus extra hw to handle/detect memory aliasing
problems, thereby allowing them to enregister memory variables.

Extending it to AMD64 would mostly be a matter of extending the
registers to 64 bit, and possibly increasing the number a bit, to more
easily handle 16 instead of 8 architected regs.

Doing IA64 the same way, with good performance, would be _hard_.

Terje