Re: Will Prescott work on Win64?

"Ancra" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Wed, 22 Oct 2003 15:57:37 -0700, [EMAIL PROTECTED] (Nate Edel)
> wrote:
>
> >In comp.arch Wes Felter <[EMAIL PROTECTED]> wrote:
> >> On Wed, 22 Oct 2003 14:35:12 +0000, zalzon wrote:
> >> > I know its a 32 bit chip, but does this mean it could work on Win64
by
> >> > emulating a 64 bit processor?
> >>
> >> No. Either it's a 32-bit processor or it's a 64-bit processor.
> >
> >'taint so simple.
>
> - Oh, yes it actually is!
>
> >What makes something a 64-bit processor anyway?  ALU width?  GP Register
> >width?  Pointer width? Virtual address space size?  Physical address
space?
>
> Of the above? - "Virtual address space size" comes closest. Though
> that is something the OS decides. Windows64 'only' gives us 4
> Terabytes, while 64 bits are potentially good for 16 Exobytes.
>
> There's no cloudy mystery about 64-bitness.
> Bits can of course be used to refer to the length of many various
> things.
>
> But when it comes to 16-32-64 bit processors there's no doubt about
> what it refers to.
>  -  It's the length of the native machine code instructions
> addressfield.
> It's this property that confers the capability of the cpu. It's that
> simple.
>
> Or hard, which is why a 32-bit cpu can never become a 64-bit. Nor even
> be able to 'emulate' a 64-bit. You have to feature a complete new set
> of 64-bit instructions, and a complete new memory management.
> That exactly means an entirely new cpu family from the ground up.
>
> >I've heard it said elsewhere here that the original 68000 used a 16-bit
ALU,
> >and yet it had a 32-bit instruction set and address space (albeit with 24
> >external lines). Was it a 16 bit CPU, a 32 bit CPU, or a 24 bit one?
>
>  - 32-bit! - And no doubt about it at all!
>
> 16 bit ALU was only a transistor count and performance decision. Later
> 68k members got 32-bit ALU. Not that it means anything, other than
> using more available transistors for better efficiency.
> Today, with our piped, cached and branchpredicted cpus, we would talk
> about the depth and width, in terms of pipes, of the execution unit.
> It still remains the question of how many transistors are going to be
> used for a diminishing return in performance.
>
> The 68000 featured 32-bit registers, and used 32-bit addressing
> instructions. And it's the latter part that makes it a true, bona fide
> 32-bit cpu. As all 68k family members.
>
> It could also use half registers as 16-bit registers, and indexed
> 16-bit addressing. In those days, 16-bit integers and short pointers
> weren't obscene.
>
> It also used a 16-bit external databus and a 24-bit external
> addressbus. Again, other 68k members employed anything from 8-bit to
> 64 bit buses, most of them featuring 32-bit. That happen to be just as
> irrelevant for their 32-bitness as the fact that the '386SX (another
> 32-bit cpu) also used 16-bit databus. That the '286 (a 16-bit cpu)
> used 24-bit addressbus. That the 8086 (a 16-bit cpu) had 20 bit
> addressbus. That the 8088 (16-bit) featured 8-bit databus. That the
> Pentiums (32-bit cpus) have 36-bit physical addressing and 64-bit
> databus. That the AthlonFX (64-bit) feature 128-bit databus and
> registers, and 40-bit addressbus. Etc ad nauseum.
>
> The integer registers should be least as wide as instruction address.
> And existing registers cannot shrink. Nor can any previously existing
> instruction use the extension of widened registers or any additional
> registers.
>
> Apart from that, these physical 'width'-thingys are all minor
> architectual concerns. Something that can easily be changed on the
> next member of the family (as is usually also the case), without
> anyone really noticing. It's just a matter of economy and what can be
> made effective use of.
>
> The instructions address length, on the other hand, is fundamental. It
> means different instruction sets and memoryhandling == completely
> different cpu == completely different OS == completely different
> software == completely different capabilities.
> 32-bit backwards compatibility is something that has to be
> painstakingly designed into the cpu as an additional feature.
> Just as the '386 did with 16-bit compatibility.
>
> Still, expect a massive smokescreen about 'bits' from Intel and
> affiliated journalists. They've already started.
>
>
> ancra