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

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

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

--
Humans: contact me at ykhan at rogers dot com
Spambots: just reply to this email address ;-)
35 answers Last reply
More about openvms itanium
  1. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In article <ip%xc.2461$LOB.872@news04.bloor.is.net.cable.rogers.com>,
    "Yousuf Khan" <bbbl67@ezrs.com> writes:
    |> ... 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.
  2. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Thu, 10 Jun 2004 15:48:30 GMT, "Yousuf Khan" <bbbl67@ezrs.com> wrote:

    >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??
  3. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Yousuf Khan" <bbbl67@ezrs.com> wrote:

    >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*
  4. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Yousuf Khan" <bbbl67@ezrs.com> writes:

    >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
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.
  5. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
    news:40c9ae4d$0$37789$e4fe514c@news.xs4all.nl...
    > "Yousuf Khan" <bbbl67@ezrs.com> writes:
    >
    > >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

    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
  6. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Casper H.S. Dik wrote:
    > "Yousuf Khan" <bbbl67@ezrs.com> writes:
    >
    >>... 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
    >

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

    RM
  7. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Robert Myers" <rmyers1400@comcast.net> wrote in message
    news:jgjyc.32265$Sw.29458@attbi_s51...
    > Casper H.S. Dik wrote:
    > > "Yousuf Khan" <bbbl67@ezrs.com> writes:
    > >
    > >>... 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
    > >
    >
    > 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
  8. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> wrote:
    > 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
  9. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In article <m-GdnU9K0dkyU1TdRVn-tw@metrocast.net>,
    "Bill Todd" <billtodd@metrocast.net> writes:
    |>
    |> > 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.
  10. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Thu, 10 Jun 2004 15:48:30 GMT, "Yousuf Khan" <bbbl67@ezrs.com>
    wrote:
    >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!

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  11. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message news:<cacjn4$6v0$1@pegasus.csx.cam.ac.uk>...
    > In article <m-GdnU9K0dkyU1TdRVn-tw@metrocast.net>,
    > "Bill Todd" <billtodd@metrocast.net> writes:
    > |>
    > |> > 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/babelfish/trurl_pagecontent?url=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2F2004%2F0305%2Fkaigai070.htm&lp=ja_en
  12. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message news:<cacjn4$6v0$1@pegasus.csx.cam.ac.uk>...
    > In article <m-GdnU9K0dkyU1TdRVn-tw@metrocast.net>,
    > "Bill Todd" <billtodd@metrocast.net> writes:
    > |>
    > |> > 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

    >
    >
    > Regards,
    > Nick Maclaren.
  13. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In article <734da31c.0406120535.4c38786f@posting.google.com>,
    David Svensson <icerq4a@spray.se> wrote:
    >>
    >> 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/babelfish/trurl_pagecontent?url=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2F2004%2F0305%2Fkaigai070.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.
  14. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In article <4495ef1f.0406121557.4f28dfd6@posting.google.com>,
    Brannon Batson <Brannon_Batson@yahoo.com> wrote:
    >nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message news:<cacjn4$6v0$1@pegasus.csx.cam.ac.uk>...
    >> In article <m-GdnU9K0dkyU1TdRVn-tw@metrocast.net>,
    >> "Bill Todd" <billtodd@metrocast.net> writes:
    >> |>
    >> |> > 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.

    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.
  15. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Nick Maclaren wrote:

    > 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
  16. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message news:<cah6aq$lmu$1@pegasus.csx.cam.ac.uk>...
    > In article <4495ef1f.0406121557.4f28dfd6@posting.google.com>,
    > Brannon Batson <Brannon_Batson@yahoo.com> wrote:
    > >nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message news:<cacjn4$6v0$1@pegasus.csx.cam.ac.uk>...
    > >> In article <m-GdnU9K0dkyU1TdRVn-tw@metrocast.net>,
    > >> "Bill Todd" <billtodd@metrocast.net> writes:
    > >> |>
    > >> |> > 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.

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

    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


    >
    >
    > Regards,
    > Nick Maclaren.
  17. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Brannon Batson" <Brannon_Batson@yahoo.com> wrote in message
    news:4495ef1f.0406141426.4d6155ce@posting.google.com...
    > nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message
    news:<cah6aq$lmu$1@pegasus.csx.cam.ac.uk>...
    > > 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?

    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

    --
    Stephen Sprunk "Those people who think they know everything
    CCIE #3723 are a great annoyance to those of us who do."
    K5SSS --Isaac Asimov
  18. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Stephen Sprunk <stephen@sprunk.org> wrote:
    > 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
  19. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In article <4495ef1f.0406141426.4d6155ce@posting.google.com>,
    Brannon_Batson@yahoo.com (Brannon Batson) writes:
    |>
    |> 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?

    No. The Crusoe, Pentium 4 and Banias don't do badly, which is what
    I am referring to. DEC got good results compiling one ISA to
    another, but the momentum seems to have been lost.

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

    So the Pentium 4 wasn't intended to be either?

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

    That is what I am advocating, but I don't think that it's what Intel
    is going to do.

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

    Yes and no. The way that the trace cache is used on a Pentium 4
    is conceptually just a variant of microcode.


    Regards,
    Nick Maclaren.
  20. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Stephen Sprunk wrote:

    > "Brannon Batson" <Brannon_Batson@yahoo.com> 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

    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

    --
    - <Terje.Mathisen@hda.hydro.com>
    "almost all programming can be viewed as an exercise in caching"
  21. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In article <cam35s$od9$1@osl016lin.hda.hydro.com>,
    Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
    |> Stephen Sprunk wrote:
    |> > "Brannon Batson" <Brannon_Batson@yahoo.com> 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. ...
    |>
    |> 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.

    Yes, indeed.

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

    Yes. My speculation is that Intel management have not learnt the
    lessons from the IA-64, and will not be put off by the complexity
    of that task.

    The underlying engine would clearly owe a lot to the Alpha, and
    be particularly similar in its VAX-emulation features. But, of
    course, it would have to have TWO legacy architectures to support.
    Not an easy task.


    Regards,
    Nick Maclaren.
  22. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

    > In article <ip%xc.2461$LOB.872@news04.bloor.is.net.cable.rogers.com>,
    > "Yousuf Khan" <bbbl67@ezrs.com> writes:

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

    Yep. It doesn't take a card-carrying analyst to see that its success
    has been inevitable for a long time now, and it's probably going to
    stay inevitable for the foreseeable future.

    :-)

    -kzm
    --
    If I haven't seen further, it is by standing in the footprints of giants
  23. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    On Tue, 15 Jun 2004 00:28:44 GMT, "Stephen Sprunk"
    <stephen@sprunk.org> wrote:
    >"Brannon Batson" <Brannon_Batson@yahoo.com> wrote in message
    >news:4495ef1f.0406141426.4d6155ce@posting.google.com...
    >> 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...

    Transmeta's "credible" job of JITing x86 isn't all that credible.
    They haven't managed to match the performance of VIA's C3 chips yet
    they are using a die that is more than twice as large and a
    SIGNIFICANTLY more expensive design, the core of their "Efficeon" chip
    is more complicated and more expensive than the AthlonXP core and
    about on-par with Intel's "Northwood" core.

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  24. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In comp.arch Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
    > Stephen Sprunk wrote:
    >
    > > "Brannon Batson" <Brannon_Batson@yahoo.com> 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
    >
    > 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_.

    Couldn't you make teh IA64 set reside in scratchpad ram, and JIT towards
    a 32 reg arch that only kept the most often / lately used regs in
    actual registers and the rest in scratch? it would then be a pretty ordinary
    target with more or less a couple of extra quirks...

    >
    > Terje
    >

    --
    Sander

    +++ Out of cheese error +++
  25. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Sander Vesik wrote:

    > In comp.arch Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
    >
    >>Stephen Sprunk wrote:
    >>
    >>
    >>>"Brannon Batson" <Brannon_Batson@yahoo.com> 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
    >>
    >>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_.
    >
    > Couldn't you make teh IA64 set reside in scratchpad ram, and JIT towards
    > a 32 reg arch that only kept the most often / lately used regs in
    > actual registers and the rest in scratch? it would then be a pretty ordinary
    > target with more or less a couple of extra quirks...

    Yes, you could, except that all the sw for which IA64 is currently fast,
    i.e. relatively regular fp codes, are fast specifically because they fit
    the rotating registers/sw pipelining model of IA64.

    This model will use all the regs, or at least all the regs that can be
    live at the same time: Since the L2 latency used to be 9 cycles, this
    means that you have to expect up to (at least?) N*9, with N = number of
    regs required by the base algorithm, to be active at any given time.

    I.e. 128 regs isn't just a hint, it's a requirement for a fast emulator,
    unless you want to completely unravel all the logic behind those
    predicated/pipelined/unrolled sw loops.

    Terje
    --
    - <Terje.Mathisen@hda.hydro.com>
    "almost all programming can be viewed as an exercise in caching"
  26. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    In article <canmh5$nqt$1@osl016lin.hda.hydro.com>,
    Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:

    > > Couldn't you make teh IA64 set reside in scratchpad ram, and JIT towards
    > > a 32 reg arch that only kept the most often / lately used regs in
    > > actual registers and the rest in scratch? it would then be a pretty
    > > ordinary
    > > target with more or less a couple of extra quirks...
    >
    > Yes, you could, except that all the sw for which IA64 is currently fast,
    > i.e. relatively regular fp codes, are fast specifically because they fit
    > the rotating registers/sw pipelining model of IA64.
    >
    > This model will use all the regs, or at least all the regs that can be
    > live at the same time: Since the L2 latency used to be 9 cycles, this
    > means that you have to expect up to (at least?) N*9, with N = number of
    > regs required by the base algorithm, to be active at any given time.
    >
    > I.e. 128 regs isn't just a hint, it's a requirement for a fast emulator,
    > unless you want to completely unravel all the logic behind those
    > predicated/pipelined/unrolled sw loops.

    But how are you going to efficiently emulate the register rotation
    itself, if the IA64 emulated registers are in 128 ordinary registers in
    a conventional CPU?

    Depending on the ratio of rotates to computation you could be much
    better off keeping them in an array and changing a base pointer (and
    doing a mod on each index into it).

    -- Bruce
  27. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Tony Hill <hilla_nospam_20@yahoo.ca> wrote:

    >On Thu, 10 Jun 2004 15:48:30 GMT, "Yousuf Khan" <bbbl67@ezrs.com>
    >wrote:
    >>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!

    It gives them someone to blame when their plan fails. "Well, the
    ANALYSTS said we were doing the right thing!"
  28. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in message news:<cam8in$7g4$1@pegasus.csx.cam.ac.uk>...
    > In article <4495ef1f.0406141426.4d6155ce@posting.google.com>,
    > Brannon_Batson@yahoo.com (Brannon Batson) writes:
    > |>
    > |> 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?
    >
    > No. The Crusoe, Pentium 4 and Banias don't do badly, which is what
    > I am referring to.

    Okay--what you are talking about doesn't have anything to do with
    running one ISA on another. It has to do with specifically designing
    an internal micro-op format for the architecture you are going to run.
    Nobody has shown they can do this for two different ISA's on the same
    hardware with optimal execution performance in both.

    > DEC got good results compiling one ISA to
    > another, but the momentum seems to have been lost.

    DEC used software to compile one ISA into another--not hardware.

    >
    > |> > 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.
    >
    > So the Pentium 4 wasn't intended to be either?

    I realize now that we are talking about two different things. The
    Pentium 4 decoding of complex instructions into micro-ops isn't
    'Microcode' by any definition that I'm familar with. The instruction
    to micro-op conversion is fixed at design time (i.e., hardwired), and
    at best takes 1 instruction and turns it into a few internal
    micro-ops. It's really just a fancy instruction decoder. True
    microcode is invoked in rare situations, it involves basically
    trapping to code stored on a ROM, here we may replace 1 instruction
    with *many* internal ones--and it is very slow.

    True microcode (and PAL code, the IPF equivalent) is also much more
    flexible--and I suppose, if you were sufficiently motivated, you could
    use it to emulate one ISA with another. But my guess is that
    sofware-based JIT's will generally be a better solution.

    >
    > |> 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.
    >
    > That is what I am advocating, but I don't think that it's what Intel
    > is going to do.

    Why not?

    >
    > |> 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.
    >
    > Yes and no. The way that the trace cache is used on a Pentium 4
    > is conceptually just a variant of microcode.

    Maybe there's a design space out there in which a microarchitecture
    which is the superset of widgets that both x86 & IPF need to have good
    native performance and backwards compatibility--and leverages
    microcode or PAL code for emulating operations which can be slow. I
    can't imagine that anyone would buy the thing, though.

    Instead, my guess is that we continue to see incremental improvement
    of software-based emulators with the occasional adding of hardware
    features to improve the performance & robustness of these.

    Brannon
    not speaking for Intel


    >
    >
    > Regards,
    > Nick Maclaren.
  29. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Bill Todd wrote:

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

    Well, ia32el-4.4-1.2.ia64.rpm from SuSe seems to work quite well around
    these parts.

    But what do I know.


    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels
    <opinions expressed here are my own, not those of my employer>
    If I have seen further, it is by standing on reference manuals.
  30. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Alexis Cousein" <al@brussels.sgi.com> wrote in message
    news:40D8983D.3080004@brussels.sgi.com...
    > Bill Todd wrote:
    >
    > >
    > > I'd say probably not before they get its vanilla-x86 emulation up to
    snuff -
    > > i.e., probably never.
    > >
    >
    > Well, ia32el-4.4-1.2.ia64.rpm from SuSe seems to work quite well around
    > these parts.
    >
    > But what do I know.

    Hard to say: does the performance evoke anything but laughter when compared
    with current IA32 Intel and AMD competition, or is it still pretty much in
    the toilet? Last I heard, the only thing that made the software emulation
    look particularly good was the fact that it was less utterly abysmal than
    the hardware kludge (i.e., might now be approaching 1.5 GHz P4/Xeon speeds -
    hardly inspiring, though probably adequate for a somewhat wider range of
    loads than the hardware IA32 Itanic box is).

    - bill
  31. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Stephen Sprunk wrote:
    > 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...
    >
    As I posted earlier, that's even how most current Itanium2 users would like to run
    their code (with an IA32EL layer that's recent enough to work). Some of the codes
    I've tried are 4-5 times faster using FX!32^WIA32EL than using the hardware engine
    (which you can still use by doing /etc/init.d/ia32el stop).

    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels
    <opinions expressed here are my own, not those of my employer>
    If I have seen further, it is by standing on reference manuals.
  32. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    "Alexis Cousein" <al@brussels.sgi.com> wrote in message
    news:40D89987.7090508@brussels.sgi.com...
    > Stephen Sprunk wrote:
    > > 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...
    > >
    > As I posted earlier, that's even how most current Itanium2 users would
    like to run
    > their code (with an IA32EL layer that's recent enough to work). Some of
    the codes
    > I've tried are 4-5 times faster using FX!32^WIA32EL than using the
    hardware engine
    > (which you can still use by doing /etc/init.d/ia32el stop).

    Oops... Last I heard it was a future thing; I must have missed the
    announcement in January when it shipped for Win2k3.

    Can you say if the hardware engine will be removed in future chips?

    S

    --
    Stephen Sprunk "Those people who think they know everything
    CCIE #3723 are a great annoyance to those of us who do."
    K5SSS --Isaac Asimov
  33. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Bruce Hoult <bruce@hoult.org> wrote in message news:<bruce-D2CA9A.09304316062004@copper.ipg.tsnz.net>...
    > In article <canmh5$nqt$1@osl016lin.hda.hydro.com>,
    > Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
    >
    > > > Couldn't you make teh IA64 set reside in scratchpad ram, and JIT towards
    > > > a 32 reg arch that only kept the most often / lately used regs in
    > > > actual registers and the rest in scratch? it would then be a pretty
    > > > ordinary
    > > > target with more or less a couple of extra quirks...
    > >
    > > Yes, you could, except that all the sw for which IA64 is currently fast,
    > > i.e. relatively regular fp codes, are fast specifically because they fit
    > > the rotating registers/sw pipelining model of IA64.
    > >
    > > This model will use all the regs, or at least all the regs that can be
    > > live at the same time: Since the L2 latency used to be 9 cycles, this
    > > means that you have to expect up to (at least?) N*9, with N = number of
    > > regs required by the base algorithm, to be active at any given time.
    > >
    > > I.e. 128 regs isn't just a hint, it's a requirement for a fast emulator,
    > > unless you want to completely unravel all the logic behind those
    > > predicated/pipelined/unrolled sw loops.
    >
    > But how are you going to efficiently emulate the register rotation
    > itself, if the IA64 emulated registers are in 128 ordinary registers in
    > a conventional CPU?
    >
    > Depending on the ratio of rotates to computation you could be much
    > better off keeping them in an array and changing a base pointer (and
    > doing a mod on each index into it).
    >
    > -- Bruce


    Do you mean something like a little wp workspace ptr:-)

    regards

    johnjakson_usa_com
  34. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    john jakson wrote:

    > Bruce Hoult <bruce@hoult.org> wrote in message news:<bruce-D2CA9A.09304316062004@copper.ipg.tsnz.net>...
    >>But how are you going to efficiently emulate the register rotation
    >>itself, if the IA64 emulated registers are in 128 ordinary registers in
    >>a conventional CPU?
    >>
    >>Depending on the ratio of rotates to computation you could be much
    >>better off keeping them in an array and changing a base pointer (and
    >>doing a mod on each index into it).

    I had this particular problem a long time ago, when implementing the
    sliding window extension to my version of Kermit.

    Today the fastest way is probably to use one (or even two) compares and
    then a conditional/predicated move/subtraction to adjust, right?

    Since Kermit could settle on arbitrary window sizes, I had to find a
    fast way to determine not just the current packet, but also [curr-N].
    The solution I settled on was to waste a little memory, and use a level
    of indirection that used a power-of-two-sized table which pointed into
    the real packet buffer array. :-)
    >>
    > Do you mean something like a little wp workspace ptr:-)

    What impresses me is that HP/Intel decided they could implement a mod-96
    register indirect access without causing this to become a critical path.

    With OOE I would expect all this logic to be handled early in the
    (decoding?) pipeline, so that the actual execution logic wouldn't see it
    at all, right?

    Terje

    --
    - <Terje.Mathisen@hda.hydro.com>
    "almost all programming can be viewed as an exercise in caching"
  35. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

    Bill Todd wrote:

    > Last I heard, the only thing that made the software emulation
    > look particularly good was the fact that it was less utterly abysmal than
    > the hardware kludge (i.e., might now be approaching 1.5 GHz P4/Xeon speeds -
    > hardly inspiring, though probably adequate for a somewhat wider range of
    > loads than the hardware IA32 Itanic box is).

    That's a correct assessment, IMO (if it weren't using such laden terms).

    Still, OpenOffice does run quite good on a 1.5GHz P4, and finding
    128 CPU P4 1.5GHz NUMA-machines *is* rather hard ;).

    You wouldn't want to run your performance-critical applications with it
    (surprise, surprise: you'd better have little-endian 64-bit clean source
    code, or an IA64 binary, for those) -- but at least your glue logic/GUI/
    toolsets etc. do work (even though it takes some Linux gymnastics with
    alternate glibc versions to make very *old* IA32 binaries work).

    For other applications that I shan't detail, IA32EL is now fast enough
    to make other parts of applications be the bottleneck -- which couldn't
    exactly be said of the hardware engine. Especially when they can
    be multi-threaded.


    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels
    <opinions expressed here are my own, not those of my employer>
    If I have seen further, it is by standing on reference manuals.
Ask a new question

Read More

CPUs OpenVMS x86 Hewlett Packard