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.