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

Niether Microsoft, AMD, nor Intel are coming clean out to the public
about what the conversion to 64bit architecture really entails for
backward compatibility and performance degredation of existing
applications.

Backward compatibility has been the bane of CPU designers for the last
20 years. In order to get clunky CISC chips to run at 1.0 GHz and
higher speeds, they have had to re-design the core pipeline of the CPU
as a RISC core, because RISC cores are much simpler than CISC cores,
and therefore, can run cooler at higher clock speeds. The problem is
that these new Pentium IIIs needed to run software that was compiled
to run natively on 486s, 386s, or even 286s (be that as it may). In
order to pull this off, extra hardware was added to convert old CISC
instructions on the fly into small lists of RISC instructions so that
the RISC core could execute them.

The idea behind the upcoming conversion to 64bit is that we abandon
backward compability, so that the complete computer, from OS to
software to motherboard to CPU, is all seamlessly integrated in
architecture.

But Microsoft realized very quickly that not allowing compatibility
with existing 32bit apps would be a business nightmare. (Although it
would be a utopia in terms of computer speed). So what they did was
bundle a WoW64 system with their 64bit versions of XP. Which is the
XP Professional x64 Edition.

Interestingly enough, neither Microsoft, AMD, nor Intel is coming
straight out to the public about what this conversion to 64bit
platform really entails.

If you google about the details of the WoW64 system you will see that
is indeed called an EMULATOR of 32bit apps. Meaning the computer is
not sending 32bit code directly to the CPU, but instead traps every
incoming 32bit instruction and converts it to 64bit before sending it
to the native 64bit processor. Anyone who is familiar with the
difference between emulation and "compiled native code" will realize
that this entails a hefty performance degredation of 32bit code run on
a 64bit platform.

How severe is this performance degredation? Well essentially what
is happening is that every single reference to memory in old 32bit
code will have to be trapped so that all those memory pointer
references can be converted into 64bit memory pointers.
Applications write and read from memory nearly all the time. 90% of
all instructions run, reference memory in some way. Very rarely do
you have spans of code that juggle things in the registers of the CPU
only.

Ironically, if you google about WOW64, you get webpages claiming that
a 64bit computer can run old 32bit apps "without performance
degredation". This is clearly a bald-faced lie coming out of
marketing.

I am glad that the CPU industry has finally given up wholesale on
backward compability. It needed to be done at some point even though
its a "growing pain" of sorts. But what has essentially happened is
that the issues of backward compatibility have been outsourced to the
Operating System, with the hopes that the end-user will not "notice" a
performance degredation.

It is likely that professionals running 32bit business apps in an
office probably will not "notice" a performance degredation at all.
But those of you who work with intensive graphics applications or
physics simulations beware.

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

On Mon, 20 Jun 2005 01:47:19 -0400, HMS Beagle <bgates@microsoft.org>
wrote:

>Niether Microsoft, AMD, nor Intel are coming clean out to the public
>about what the conversion to 64bit architecture really entails for
>backward compatibility and performance degredation of existing
>applications.
>
>Backward compatibility has been the bane of CPU designers for the last
>20 years. In order to get clunky CISC chips to run at 1.0 GHz and
>higher speeds, they have had to re-design the core pipeline of the CPU
>as a RISC core, because RISC cores are much simpler than CISC cores,
>and therefore, can run cooler at higher clock speeds. The problem is
>that these new Pentium IIIs needed to run software that was compiled
>to run natively on 486s, 386s, or even 286s (be that as it may). In
>order to pull this off, extra hardware was added to convert old CISC
>instructions on the fly into small lists of RISC instructions so that
>the RISC core could execute them.
>
>The idea behind the upcoming conversion to 64bit is that we abandon
>backward compability, so that the complete computer, from OS to
>software to motherboard to CPU, is all seamlessly integrated in
>architecture.

Huh? You call that abandoning backward compatibility?<shrug>

>But Microsoft realized very quickly that not allowing compatibility
>with existing 32bit apps would be a business nightmare. (Although it
>would be a utopia in terms of computer speed). So what they did was
>bundle a WoW64 system with their 64bit versions of XP. Which is the
>XP Professional x64 Edition.
>
>Interestingly enough, neither Microsoft, AMD, nor Intel is coming
>straight out to the public about what this conversion to 64bit
>platform really entails.

There is nothng to tell the "public" that they would understand, other than
it works and works efficiently.

>If you google about the details of the WoW64 system you will see that
>is indeed called an EMULATOR of 32bit apps. Meaning the computer is
>not sending 32bit code directly to the CPU, but instead traps every
>incoming 32bit instruction and converts it to 64bit before sending it
>to the native 64bit processor. Anyone who is familiar with the
>difference between emulation and "compiled native code" will realize
>that this entails a hefty performance degredation of 32bit code run on
>a 64bit platform.

I have no idea what you mean by "the computer"<boggle> here but you have
obviously been confused by the existence of WOW64 for IA64, where there is
a JIT software translator to Itanium native instructions and WOW64 for
AMD64/EM64T where there is no such need.

There is a difference between "google"ing for info with the correct
equipment to understand the results and just reading.

>How severe is this performance degredation? Well essentially what
>is happening is that every single reference to memory in old 32bit
>code will have to be trapped so that all those memory pointer
>references can be converted into 64bit memory pointers.
>Applications write and read from memory nearly all the time. 90% of
>all instructions run, reference memory in some way. Very rarely do
>you have spans of code that juggle things in the registers of the CPU
>only.

This address "trapping" can all be handled in hardware after the OS has
established the correct mappings for virtual to physical addressing just
like it has to do for any process, whether it be 32-bit or 64-bit. There
is no penalty there.

>Ironically, if you google about WOW64, you get webpages claiming that
>a 64bit computer can run old 32bit apps "without performance
>degredation". This is clearly a bald-faced lie coming out of
>marketing.

Nope.

>I am glad that the CPU industry has finally given up wholesale on
>backward compability. It needed to be done at some point even though
>its a "growing pain" of sorts. But what has essentially happened is
>that the issues of backward compatibility have been outsourced to the
>Operating System, with the hopes that the end-user will not "notice" a
>performance degredation.

You got it all backwards - AMD64/EM64T is about compatibility.

>It is likely that professionals running 32bit business apps in an
>office probably will not "notice" a performance degredation at all.
>But those of you who work with intensive graphics applications or
>physics simulations beware.

Rubbish.

--
Rgds, George Macdonald

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

HMS Beagle wrote:
> If you google about the details of the WoW64 system you will see that
> is indeed called an EMULATOR of 32bit apps. Meaning the computer is
> not sending 32bit code directly to the CPU, but instead traps every
> incoming 32bit instruction and converts it to 64bit before sending it
> to the native 64bit processor. Anyone who is familiar with the
> difference between emulation and "compiled native code" will realize
> that this entails a hefty performance degredation of 32bit code run on
> a 64bit platform.

I see what the problem is here. You are not aware that there are
actually two different implementations of WoW64's in existence. WOW64
was originally created for Itanium based systems, where the 32-bit
instruction set is a completely different language, and it actually has
to be emulated. However, that's only for Itanium. In an x64 system,
Wow64 is nothing more than a glorified thunking layer. Basically,
Microsoft reused the source code between its Itanium and x64 versions
of Windows, but implemented the low-level hardware-specific
implementations different. Standard practice.

Basically there's no emulation in Wow64 on x64, but there is in Wow64
on Itanium. Hope that clears it up for you now.

Yousuf Khan

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

On 20 Jun 2005 05:01:56 -0700, "YKhan" <yjkhan@gmail.com> wrote:
>I see what the problem is here. You are not aware that there are
>actually two different implementations of WoW64's in existence. WOW64
>was originally created for Itanium based systems, where the 32-bit
>instruction set is a completely different language, and it actually has
>to be emulated. However, that's only for Itanium. In an x64 system,
>Wow64 is nothing more than a glorified thunking layer. Basically,
>Microsoft reused the source code between its Itanium and x64 versions
>of Windows, but implemented the low-level hardware-specific
>implementations different. Standard practice.


But wait! That looks and smells and sounds like full hardware
backward compatibility. You do realize that having a 32-bit pipe
inside the 64bit CPU adds extra circuitry, and extra circuitry means
that you run hotter, thus you are less stable at higher clock speeds.
I know I realize this. But do you?

My understanding is that this conversion to 64bit was going to abandon
backward compatibility (at the hardware level) so that we can run
these next-generation processors cooler, and hence faster.

Maybe I was wrong. Maybe the chip manufacturers have caved in and
decided to do the same old stuff they have been doing for the last 20
years. (And that is conserving old clunky hardware that was designed
to run code written 10 years ago.)

>Basically there's no emulation in Wow64 on x64, but there is in Wow64
>on Itanium. Hope that clears it up for you now.

Right. Right. But is this the "caving in" I wrote about above?
or...?

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

HMS Beagle wrote:
> But wait! That looks and smells and sounds like full hardware
> backward compatibility.

Why yes it does.

> You do realize that having a 32-bit pipe
> inside the 64bit CPU adds extra circuitry, and extra circuitry means
> that you run hotter, thus you are less stable at higher clock speeds.
> I know I realize this. But do you?

In AMD's implementation called AMD64, they said that the 64-bit
extensions just added less than 5% to their core size. They basically
just reused all of the existing instructions for 64-bit. So for example
the opcode for the 32-bit ADD instruction is exactly the same opcode as
the 64-bit ADD. All of the instructions are just extended out to 64-bit,
but they can still work exactly the same way with 32-bit operands, or
even 16- or 8-bit operands. It's not like as if they're using seperate
circuitry for the 64-bit and 32-bit versions of instructions.


> My understanding is that this conversion to 64bit was going to abandon
> backward compatibility (at the hardware level) so that we can run
> these next-generation processors cooler, and hence faster.

Well, I don't know about cooler and faster, but the rest of what you
said would've been right, if Itanium had become very popular. Itanium
would've been the processor that abandonned all backward compatibility.

You gotta be careful when talking about "64-bit", they are not all the
same languages. Itanium's native language is as different from x86 as
Chinese is from English. By contrast, the difference between AMD64 and
x86 is like the difference between English and graduate-level English.

> Maybe I was wrong. Maybe the chip manufacturers have caved in and
> decided to do the same old stuff they have been doing for the last 20
> years. (And that is conserving old clunky hardware that was designed
> to run code written 10 years ago.)

Yup, that was the overwhelmingly preferred course of action. It's
turning out that the x86 extended out to 64-bit is much more popular and
practical than the Itanium solution was. Companies were taking a wait
and see attitude with Itanium -- when everyone is in wait'n'see mode,
then nobody is buying. By contrast, people were taking to x64 almost
right away.

But I wouldn't call it clunky. The designers took the opportunity to
clean up the architecture somewhat. The segment registers are gone in
64-bit mode; they were already in severe disuse in 32-bit mode. The old
stack-based FPU is now deprecated in favor of the fully
randomly-accessible SSE. They not only doubled the size of the general
purpose integer registers, but they also doubled the number of
registers, etc.

>>Basically there's no emulation in Wow64 on x64, but there is in Wow64
>>on Itanium. Hope that clears it up for you now.
>
>
> Right. Right. But is this the "caving in" I wrote about above?
> or...?

If you were an Itanium fan, then it's caving in. If you were one of
those who couldn't see the point of Itanium, then this is just the world
evolving naturally the way it should've all along.

Yousuf Khan

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

Thank you for your response. It was very informative and it answered
all questions I had. If you don't mind me asking you, what do you do
for a living?




On Tue, 21 Jun 2005 01:17:11 -0400, Yousuf Khan <bbbl67@ezrs.com>
wrote:
> > You do realize that having a 32-bit pipe
>> inside the 64bit CPU adds extra circuitry, and extra circuitry means
>> that you run hotter, thus you are less stable at higher clock speeds.
>> I know I realize this. But do you?
>
>In AMD's implementation called AMD64, they said that the 64-bit
>extensions just added less than 5% to their core size. They basically
>just reused all of the existing instructions for 64-bit. So for example
>the opcode for the 32-bit ADD instruction is exactly the same opcode as
>the 64-bit ADD. All of the instructions are just extended out to 64-bit,
>but they can still work exactly the same way with 32-bit operands, or
>even 16- or 8-bit operands. It's not like as if they're using seperate
>circuitry for the 64-bit and 32-bit versions of instructions.
>
>
>> My understanding is that this conversion to 64bit was going to abandon
>> backward compatibility (at the hardware level) so that we can run
>> these next-generation processors cooler, and hence faster.
>
>Well, I don't know about cooler and faster, but the rest of what you
>said would've been right, if Itanium had become very popular. Itanium
>would've been the processor that abandonned all backward compatibility.
>
>You gotta be careful when talking about "64-bit", they are not all the
>same languages. Itanium's native language is as different from x86 as
>Chinese is from English. By contrast, the difference between AMD64 and
>x86 is like the difference between English and graduate-level English.
>
>> Maybe I was wrong. Maybe the chip manufacturers have caved in and
>> decided to do the same old stuff they have been doing for the last 20
>> years. (And that is conserving old clunky hardware that was designed
>> to run code written 10 years ago.)
>
>Yup, that was the overwhelmingly preferred course of action. It's
>turning out that the x86 extended out to 64-bit is much more popular and
>practical than the Itanium solution was. Companies were taking a wait
>and see attitude with Itanium -- when everyone is in wait'n'see mode,
>then nobody is buying. By contrast, people were taking to x64 almost
>right away.
>
>But I wouldn't call it clunky. The designers took the opportunity to
>clean up the architecture somewhat. The segment registers are gone in
>64-bit mode; they were already in severe disuse in 32-bit mode. The old
>stack-based FPU is now deprecated in favor of the fully
>randomly-accessible SSE. They not only doubled the size of the general
>purpose integer registers, but they also doubled the number of
>registers, etc.
>
>>>Basically there's no emulation in Wow64 on x64, but there is in Wow64
>>>on Itanium. Hope that clears it up for you now.
>>
>>
>> Right. Right. But is this the "caving in" I wrote about above?
>> or...?
>
>If you were an Itanium fan, then it's caving in. If you were one of
>those who couldn't see the point of Itanium, then this is just the world
>evolving naturally the way it should've all along.
>
> Yousuf Khan

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

HMS Beagle wrote:
> Thank you for your response. It was very informative and it answered
> all questions I had. If you don't mind me asking you, what do you do
> for a living?

I slave for an evil corporation. :-)

Yousuf Khan

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

In article <upNte.32771$Kk4.421520@news20.bellglobal.com>,
Yousuf Khan <bbbl67@ezrs.com> writes:
<snip>
> If you were an Itanium fan, then it's caving in. If you were one of
> those who couldn't see the point of Itanium, then this is just the world
> evolving naturally the way it should've all along.
>
After all, we all KNOW that Itanium is THE only non-x86 64-bit CPU, and
that if you want to progress beyond the horrendous nightmare known as
x86, Itanium is the ONLY solution. (I know you know better than this,
but I just had to mini-rant/respond.)

The most amazing thing of all is that Itanium managed to scare most of
the competition out of the market, without even executing a cycle in
silicon.

Dale