Sign in with
Sign up | Sign in
Your question

Can I run 64bit XP Pro or Server 2003 on P4 2.6Ghz CPU?

Last response: in Systems
Share
Anonymous
a b B Homebuilt system
a b à CPUs
June 10, 2005 2:47:18 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

Not a tech. So here's my question. Do Microsoft 64bit OS
flavors, either XP Pro or Server 2003, require a 64bit CPU
to run?

My CPU is P4 2.6Ghz. Hyper thread enabled. Can I run 64bit
XP Pro or Server 2003 on it?
Anonymous
a b B Homebuilt system
a b à CPUs
June 10, 2005 7:05:56 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

In article <unria11cccv7nph42d3nep1lpr09gb4hmr@4ax.com>, lazy smurf
says...
> Not a tech. So here's my question. Do Microsoft 64bit OS
> flavors, either XP Pro or Server 2003, require a 64bit CPU
> to run?
>
Of course they don't. Why the hell do you think they released a x64
version?

> My CPU is P4 2.6Ghz. Hyper thread enabled. Can I run 64bit
> XP Pro or Server 2003 on it?
>
No.

--
Conor


"Be incomprehensible. If they can't understand, they can't disagree"
Anonymous
a b B Homebuilt system
a b à CPUs
June 10, 2005 8:01:16 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

No. You have a 32 bit CPU.

--
DaveW



"lazy smurf" <smurf@mushroomland.nature> wrote in message
news:unria11cccv7nph42d3nep1lpr09gb4hmr@4ax.com...
> Not a tech. So here's my question. Do Microsoft 64bit OS
> flavors, either XP Pro or Server 2003, require a 64bit CPU
> to run?
>
> My CPU is P4 2.6Ghz. Hyper thread enabled. Can I run 64bit
> XP Pro or Server 2003 on it?
Related resources
Anonymous
a b B Homebuilt system
a b à CPUs
June 10, 2005 8:29:52 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

Plain & simple: NO

"lazy smurf" <smurf@mushroomland.nature> wrote in message
news:unria11cccv7nph42d3nep1lpr09gb4hmr@4ax.com...
> Not a tech. So here's my question. Do Microsoft 64bit OS
> flavors, either XP Pro or Server 2003, require a 64bit CPU
> to run?
>
> My CPU is P4 2.6Ghz. Hyper thread enabled. Can I run 64bit
> XP Pro or Server 2003 on it?
Anonymous
a b B Homebuilt system
a b à CPUs
June 10, 2005 10:27:45 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

"Hrvoje Cicak" <hrvoje@bilanca.hr> wrote in message
news:D 8c4lo$i54$1@ss405.t-com.hr...
> Plain & simple: NO
>
> "lazy smurf" <smurf@mushroomland.nature> wrote in message
> news:unria11cccv7nph42d3nep1lpr09gb4hmr@4ax.com...
>> Not a tech. So here's my question. Do Microsoft 64bit OS
>> flavors, either XP Pro or Server 2003, require a 64bit CPU
>> to run?
>>
>> My CPU is P4 2.6Ghz. Hyper thread enabled. Can I run 64bit
>> XP Pro or Server 2003 on it?
>
I don't understand. Are there 2 versions of XP pro as I am running my XP pro
on an Intel P4 2.6GHz CPU - it's fine!
Anonymous
a b B Homebuilt system
a b à CPUs
June 10, 2005 10:27:46 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

"DCA" <dca860MAPS@yahoo.co.uk> wrote in message
news:BYkqe.18808$iy2.6145@newsfe1-gui.ntli.net...
> "Hrvoje Cicak" <hrvoje@bilanca.hr> wrote in message
> news:D 8c4lo$i54$1@ss405.t-com.hr...
>> Plain & simple: NO
>>
>> "lazy smurf" <smurf@mushroomland.nature> wrote in message
>> news:unria11cccv7nph42d3nep1lpr09gb4hmr@4ax.com...
>>> Not a tech. So here's my question. Do Microsoft 64bit OS
>>> flavors, either XP Pro or Server 2003, require a 64bit CPU
>>> to run?
>>>
>>> My CPU is P4 2.6Ghz. Hyper thread enabled. Can I run 64bit
>>> XP Pro or Server 2003 on it?
>>
> I don't understand. Are there 2 versions of XP pro as I am running my XP
> pro on an Intel P4 2.6GHz CPU - it's fine!
>


Yes, there are two different versions. The one you are running is 32-bit.
The new release is 64-bit and requires a 64-bit cpu, which the P4 is not and
never will be. Needless to say, but I'll say it, the 64-bit version will not
run on your P4.

The old 32-bit bu cpu is about to be relegated to the obsolete junk pile,
just as the old 16-bit chips hit the pile when the 32-bit processors became
available.

It will take a while for 64-bit format to dominate the market, so enjoy your
P4 for the next couple of years and don't worry about it. This is the normal
progression of things in the computer world. Nothing stays on top of the
heap for long.

Ed Cregger
Anonymous
a b B Homebuilt system
a b à CPUs
June 10, 2005 11:38:45 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

"DCA" <dca860MAPS@yahoo.co.uk> wrote in message
news:BYkqe.18808$iy2.6145@newsfe1-gui.ntli.net...
> "Hrvoje Cicak" <hrvoje@bilanca.hr> wrote in message
> news:D 8c4lo$i54$1@ss405.t-com.hr...
> > Plain & simple: NO
> >
> > "lazy smurf" <smurf@mushroomland.nature> wrote in message
> > news:unria11cccv7nph42d3nep1lpr09gb4hmr@4ax.com...
> >> Not a tech. So here's my question. Do Microsoft 64bit OS
> >> flavors, either XP Pro or Server 2003, require a 64bit CPU
> >> to run?
> >>
> >> My CPU is P4 2.6Ghz. Hyper thread enabled. Can I run 64bit
> >> XP Pro or Server 2003 on it?
> >
> I don't understand. Are there 2 versions of XP pro as I am running my XP
pro
> on an Intel P4 2.6GHz CPU - it's fine!
>
Yes! There ARE two versions, with different names.
Mike.
Anonymous
a b B Homebuilt system
a b à CPUs
June 11, 2005 2:07:21 AM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

Howdy!

"Ed Cregger" <ecregger@homtail.com> wrote in message
news:D 8csfg0c2t@enews1.newsguy.com...

> Yes, there are two different versions. The one you are running is 32-bit.
> The new release is 64-bit and requires a 64-bit cpu, which the P4 is not
and
> never will be. Needless to say, but I'll say it, the 64-bit version will
not
> run on your P4.

Ahem. Check the listings again. The newest Pentium 4 Extreme
Editions all support the 64 bit software extensions.

Which isn't surprising - a 32 bit processor running 64 bit
instructions B)

RwP
Anonymous
a b B Homebuilt system
a b à CPUs
June 11, 2005 4:11:07 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

"Ralph W. Phillips" <ralphp@techie.com> wrote in message
news:3gv34jFeh7q2U1@individual.net...
> Howdy!
>
> "Ed Cregger" <ecregger@homtail.com> wrote in message
> news:D 8csfg0c2t@enews1.newsguy.com...
>
>> Yes, there are two different versions. The one you are running is 32-bit.
>> The new release is 64-bit and requires a 64-bit cpu, which the P4 is not
> and
>> never will be. Needless to say, but I'll say it, the 64-bit version will
> not
>> run on your P4.
>


Well, as you can see, this makes absolutely no sense to me.

Is it a true 64-bit chip? Or are they performing translation acrobatics
somehow?

Ed Cregger
> Ahem. Check the listings again. The newest Pentium 4 Extreme
> Editions all support the 64 bit software extensions.
>
> Which isn't surprising - a 32 bit processor running 64 bit
> instructions B)
>
> RwP
>
>
Anonymous
a b B Homebuilt system
a b à CPUs
June 13, 2005 2:02:57 AM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

Howdy!

"Ed Cregger" <ecregger@homtail.com> wrote in message
news:D 8f2ep02p96@enews2.newsguy.com...
>
> "Ralph W. Phillips" <ralphp@techie.com> wrote in message
> news:3gv34jFeh7q2U1@individual.net...
> > Howdy!
> >
> > "Ed Cregger" <ecregger@homtail.com> wrote in message
> > news:D 8csfg0c2t@enews1.newsguy.com...
> >
> >> Yes, there are two different versions. The one you are running is
32-bit.
> >> The new release is 64-bit and requires a 64-bit cpu, which the P4 is
not
> > and
> >> never will be. Needless to say, but I'll say it, the 64-bit version
will
> > not
> >> run on your P4.
> >
>
>
> Well, as you can see, this makes absolutely no sense to me.
>
> Is it a true 64-bit chip? Or are they performing translation acrobatics
> somehow?

It's 32 bits in and out, but runs 64 bit instructions.

Once you figure out which it is, you can tell me.

I figure it's like the 8088 (an 8 bit processor than ran 16bit 8086
code), the 386SX (a 16 bit processor than ran 32bit 80386DX code), and the
68008 (an 8 bit processor than ran 68000 16bit code).

IOW - Business as usual for Intel and other manufacturers.

RwP
Anonymous
a b B Homebuilt system
a b à CPUs
June 13, 2005 4:23:34 AM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

"Ralph W. Phillips" <ralphp@techie.com> wrote in message
news:3h4bkcFf4qfcU2@individual.net...
> Howdy!
>
> "Ed Cregger" <ecregger@homtail.com> wrote in message
> news:D 8f2ep02p96@enews2.newsguy.com...
>>
>> "Ralph W. Phillips" <ralphp@techie.com> wrote in message
>> news:3gv34jFeh7q2U1@individual.net...
>> > Howdy!
>> >
>> > "Ed Cregger" <ecregger@homtail.com> wrote in message
>> > news:D 8csfg0c2t@enews1.newsguy.com...
>> >
>> >> Yes, there are two different versions. The one you are running is
> 32-bit.
>> >> The new release is 64-bit and requires a 64-bit cpu, which the P4 is
> not
>> > and
>> >> never will be. Needless to say, but I'll say it, the 64-bit version
> will
>> > not
>> >> run on your P4.
>> >
>>
>>
>> Well, as you can see, this makes absolutely no sense to me.
>>
>> Is it a true 64-bit chip? Or are they performing translation acrobatics
>> somehow?
>
> It's 32 bits in and out, but runs 64 bit instructions.
>
> Once you figure out which it is, you can tell me.
>
> I figure it's like the 8088 (an 8 bit processor than ran 16bit 8086
> code), the 386SX (a 16 bit processor than ran 32bit 80386DX code), and the
> 68008 (an 8 bit processor than ran 68000 16bit code).
>
> IOW - Business as usual for Intel and other manufacturers.
>
> RwP
>
>


Okay, I get it. It isn't really a 64-bit CPU if it is 32-bit in and out. At
least not to me.

Yup, I'm familiar with the 386SX chips. In fact, I own an old system that
was a gift from my sister-in-law. A bit of nostalgia. They (the 386SX)
always seemed to be a waste of time and effort to me. An interim, stop-gap
measure at best and a waste of Intel's resources. Not to mention their
customer's money. Customers that were fooled into thinking something that
did not provide the benefit that was promised.

You are correct, it is a philosophical point.

Ed Cregger
June 13, 2005 8:46:31 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

Shortest Answer - No, now read on

This is the rap, the rap is as follows:

1) it has been a Long Time since any CPU had been purely n-bit
architecture - for instance, to handle some IEEE Floating Point Data Types, you
need a few registers of more than 70 bits in length. I'll bet the '486 has some
upwards of 80 or more <without going to the data sheets>

BUT:

2) 64-bit Win-XP and 64-Bit Win Server (and 64-bit Linux) have been
designed for the SuperP4s and Xenons, Possibly even Itaniums <the Linux is good
for that> and of course the AMD Athalchips that are 100% 64 bit interiors,
though some may require double-bit access to the world.

SHORTER ANSWER - NO, YOU CAN"T run a 64-bit program on a 32-bit
Pentium/AMD chip for that reason

Longer answer:

The basic Pentium-class instruction set <with both Intel and AMD
extensions> is 32 bits wide, the reason, to mention another strand, it can only
address up to 4 GB of "core" RAM.

The Athalons and new uber-pentia are 64-bit-wide versions of the still
insane x86 instruction set. Intel tried to introduce a new system that ran a New
Different architecture and instruction set, with a built-in emulator to run x86
code - the Itanium, but the desktop PC industry rejected it because it required
a really NEW OS, and, for all the claims of the beauty of "portable" high-level
languages like C and its kin, you really cannot port something like Windows to
Itanium without a rewrite that makes Longhorn look simple.

So we're stuck using a backwards-compatable system that still runs code
written in 1978 - at a BIG expense to us to save the companies money.

Nobody has ever loved changing the machine code. It's why for several
generations into the IBM 4300 MegaMainframes, you could run the included
emulator to make it act like a 370, run under that the included emulator to make
it act like a 360, run under that the included emulator to make ot run like a
1401 and, in the 1980s run code written in the 1960s.

And that involved computers that numbered in the dozens, possibly
hundreds of machines produced.

Nobody ever thought of producing more than 20 or 30 of a given computer
until the DEC/MIT/CMU guys came up with the PDP-8 structure, then the PDP-11/Vax
series. Then you started seeing volume production.

Nobody ever in their wildest dreams when some of the rules were laid
down thought about Joe Consumer having a machine running in the multi-GHz range
with gigs of RAM and a terabyte of disk storage that fit in their hand..... When
the rules were made, a megabyte of memory took up a box at least 20-36" wide by
6' tall, required 220 volts/40 amps + a quarter-ton of AC, and a 4-meg disk pack
spun in a box about the size of a small apartment washer.

Outside of the Linux crew and possibly Apple, nobody's bothered to
consider saying "The 6500XX cpu era ended, the VAX era ended, the Power PC era
ended, let's pull the plug on the 80X86 era and build from the ground up for
CISC, revive DEC's Alpha design, now owned by Intel <though I think Apple might
be thinking in those terms>

OR: Building A Brand New Architecture - except Intel, which got
brutalized for it, mainly by Redmond and those whose future rides on Microsoft,
including AMD, which used the time to build their version of the old IBM
Stretch(1)

In fact, every New Idea Before its Time Intel project has been zapped by
the rest of the industry for one reason or another, like the IA432 CPU.

The strange duck's Assembly language was ADA, the mess cooked up by the
Pentagon and sold to the US government as a dream high-level language come true
(it wasn't but that doesn't mean anything to the -432)

The thing about the -432 is that it was designed to divide up and run
the same code if you had 2 CPU chips, 20, or 2,000! It worked better than
anything else available in the early 80s as a divided-task chip.

But nobody was thinking about that kind of multi-core operation way back
then.

Now Apple might do it - if it offers a chipset available to other board
manufacturers for a machine almost useless without its OS. As soon as Jobs&Co
decide that they cannot build every machine running Apple software and hope to
cut into the market, and are ready to port it to a non-x86 chip that can match
the speed, capacity, power and grace of its new OS, we'll all be putting
different software in our ATX-format boards.

The basic CPU specs for suc a system are easy - build a Big-Endian CISC
instruction set based on the rule of No Vertical Microcoding (the concept of
saving transistors by making a small number of subsystems perform VERY
different instructions so an instruction can take many clock cycles) and the
core rule of RISC architecture.

With almost each operation taking 4 ticks of the clock instead of up to
40, well, the same chip speed only means an 8-10 time improvement in real
throughput. The chip won't be that much bigger than Intel's largest dice, but
cache dice may have to be mounted next to-under or on top to do the job, and
folks will have to think about really integrating cooling into the silicon for
the first time. And standard PC boards may give way to embedded 3-d strips of
co-ax or optical lines to talk to memory at light-speed.

But you won't be able to build a low-end compatable machine for $600+
monitor.

Figure we'll be back to the days that "The computer you really want will
cost $5K <+inflation> again for a while. Then think of instant HDTV-level
real-time movie editing or composing images so well that no one's photos will be
"believable" anymore, based on the output of images from real-60-MegPixel x
3(RGB) X 32 bit chroma levels<x3> per pixel, and the ability to work with
it.....

TrAl
spending a summer day dreaming
Anonymous
a b B Homebuilt system
a b à CPUs
June 13, 2005 10:32:29 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

Ed Cregger wrote:
> "Ralph W. Phillips" <ralphp@techie.com> wrote in message
> news:3h4bkcFf4qfcU2@individual.net...
>
>>Howdy!
>>
>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>news:D 8f2ep02p96@enews2.newsguy.com...
>>
>>>"Ralph W. Phillips" <ralphp@techie.com> wrote in message
>>>news:3gv34jFeh7q2U1@individual.net...
>>>
>>>>Howdy!
>>>>
>>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>>news:D 8csfg0c2t@enews1.newsguy.com...
>>>>
>>>>
>>>>>Yes, there are two different versions. The one you are running is
>>
>>32-bit.
>>
>>>>>The new release is 64-bit and requires a 64-bit cpu, which the P4 is
>>
>>not
>>
>>>>and
>>>>
>>>>>never will be. Needless to say, but I'll say it, the 64-bit version
>>
>>will
>>
>>>>not
>>>>
>>>>>run on your P4.
>>>>
>>>
>>>Well, as you can see, this makes absolutely no sense to me.
>>>
>>>Is it a true 64-bit chip? Or are they performing translation acrobatics
>>>somehow?
>>
>> It's 32 bits in and out, but runs 64 bit instructions.
>>
>> Once you figure out which it is, you can tell me.
>>
>> I figure it's like the 8088 (an 8 bit processor than ran 16bit 8086
>>code), the 386SX (a 16 bit processor than ran 32bit 80386DX code), and the
>>68008 (an 8 bit processor than ran 68000 16bit code).
>>
>> IOW - Business as usual for Intel and other manufacturers.
>>
>> RwP
>>
>>
>
>
>
> Okay, I get it. It isn't really a 64-bit CPU if it is 32-bit in and out. At
> least not to me.

Of course it is. The 'in/out' is simply how the data lines are multiplexed.


> Yup, I'm familiar with the 386SX chips. In fact, I own an old system that
> was a gift from my sister-in-law. A bit of nostalgia. They (the 386SX)
> always seemed to be a waste of time and effort to me. An interim, stop-gap
> measure at best and a waste of Intel's resources. Not to mention their
> customer's money. Customers that were fooled into thinking something that
> did not provide the benefit that was promised.
>
> You are correct, it is a philosophical point.
>
> Ed Cregger
>
>
Anonymous
a b B Homebuilt system
a b à CPUs
June 14, 2005 4:01:21 AM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

"David Maynard" <nospam@private.net> wrote in message
news:11as5sf8s17qo16@corp.supernews.com...
> Ed Cregger wrote:
>> "Ralph W. Phillips" <ralphp@techie.com> wrote in message
>> news:3h4bkcFf4qfcU2@individual.net...
>>
>>>Howdy!
>>>
>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>news:D 8f2ep02p96@enews2.newsguy.com...
>>>
>>>>"Ralph W. Phillips" <ralphp@techie.com> wrote in message
>>>>news:3gv34jFeh7q2U1@individual.net...
>>>>
>>>>>Howdy!
>>>>>
>>>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>>>news:D 8csfg0c2t@enews1.newsguy.com...
>>>>>
>>>>>
>>>>>>Yes, there are two different versions. The one you are running is
>>>
>>>32-bit.
>>>
>>>>>>The new release is 64-bit and requires a 64-bit cpu, which the P4 is
>>>
>>>not
>>>
>>>>>and
>>>>>
>>>>>>never will be. Needless to say, but I'll say it, the 64-bit version
>>>
>>>will
>>>
>>>>>not
>>>>>
>>>>>>run on your P4.
>>>>>
>>>>
>>>>Well, as you can see, this makes absolutely no sense to me.
>>>>
>>>>Is it a true 64-bit chip? Or are they performing translation acrobatics
>>>>somehow?
>>>
>>> It's 32 bits in and out, but runs 64 bit instructions.
>>>
>>> Once you figure out which it is, you can tell me.
>>>
>>> I figure it's like the 8088 (an 8 bit processor than ran 16bit
>>> 8086
>>>code), the 386SX (a 16 bit processor than ran 32bit 80386DX code), and
>>>the
>>>68008 (an 8 bit processor than ran 68000 16bit code).
>>>
>>> IOW - Business as usual for Intel and other manufacturers.
>>>
>>> RwP
>>>
>>>
>>
>>
>>
>> Okay, I get it. It isn't really a 64-bit CPU if it is 32-bit in and out.
>> At least not to me.
>
> Of course it is. The 'in/out' is simply how the data lines are
> multiplexed.


In the sense that it will run the 64 bit code, yes it is. As far as the real
benefit of running a 64-bit bus, no it isn't.

Ed Cregger
Anonymous
a b B Homebuilt system
a b à CPUs
June 14, 2005 6:32:27 AM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

Ed Cregger wrote:

> "David Maynard" <nospam@private.net> wrote in message
> news:11as5sf8s17qo16@corp.supernews.com...
>
>>Ed Cregger wrote:
>>
>>>"Ralph W. Phillips" <ralphp@techie.com> wrote in message
>>>news:3h4bkcFf4qfcU2@individual.net...
>>>
>>>
>>>>Howdy!
>>>>
>>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>>news:D 8f2ep02p96@enews2.newsguy.com...
>>>>
>>>>
>>>>>"Ralph W. Phillips" <ralphp@techie.com> wrote in message
>>>>>news:3gv34jFeh7q2U1@individual.net...
>>>>>
>>>>>
>>>>>>Howdy!
>>>>>>
>>>>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>>>>news:D 8csfg0c2t@enews1.newsguy.com...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Yes, there are two different versions. The one you are running is
>>>>
>>>>32-bit.
>>>>
>>>>
>>>>>>>The new release is 64-bit and requires a 64-bit cpu, which the P4 is
>>>>
>>>>not
>>>>
>>>>
>>>>>>and
>>>>>>
>>>>>>
>>>>>>>never will be. Needless to say, but I'll say it, the 64-bit version
>>>>
>>>>will
>>>>
>>>>
>>>>>>not
>>>>>>
>>>>>>
>>>>>>>run on your P4.
>>>>>>
>>>>>Well, as you can see, this makes absolutely no sense to me.
>>>>>
>>>>>Is it a true 64-bit chip? Or are they performing translation acrobatics
>>>>>somehow?
>>>>
>>>> It's 32 bits in and out, but runs 64 bit instructions.
>>>>
>>>> Once you figure out which it is, you can tell me.
>>>>
>>>> I figure it's like the 8088 (an 8 bit processor than ran 16bit
>>>>8086
>>>>code), the 386SX (a 16 bit processor than ran 32bit 80386DX code), and
>>>>the
>>>>68008 (an 8 bit processor than ran 68000 16bit code).
>>>>
>>>> IOW - Business as usual for Intel and other manufacturers.
>>>>
>>>> RwP
>>>>
>>>>
>>>
>>>
>>>
>>>Okay, I get it. It isn't really a 64-bit CPU if it is 32-bit in and out.
>>>At least not to me.
>>
>>Of course it is. The 'in/out' is simply how the data lines are
>>multiplexed.
>
>
>
> In the sense that it will run the 64 bit code, yes it is. As far as the real
> benefit of running a 64-bit bus, no it isn't.

Even that depends on what one thinks the 'benefit' is. The addressing and
data are all still there but potentially with a speed penalty. But even
that would depend on the bus clock.

The address bus is multiplexed in all the processors but you consider it
'all there' don't you?

>
> Ed Cregger
>
>
Anonymous
a b B Homebuilt system
a b à CPUs
June 14, 2005 12:19:15 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

"David Maynard" <nospam@private.net> wrote in message
news:11at20dep5cfu1e@corp.supernews.com...
> Ed Cregger wrote:
>
>> "David Maynard" <nospam@private.net> wrote in message
>> news:11as5sf8s17qo16@corp.supernews.com...
>>
>>>Ed Cregger wrote:
>>>
>>>>"Ralph W. Phillips" <ralphp@techie.com> wrote in message
>>>>news:3h4bkcFf4qfcU2@individual.net...
>>>>
>>>>
>>>>>Howdy!
>>>>>
>>>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>>>news:D 8f2ep02p96@enews2.newsguy.com...
>>>>>
>>>>>
>>>>>>"Ralph W. Phillips" <ralphp@techie.com> wrote in message
>>>>>>news:3gv34jFeh7q2U1@individual.net...
>>>>>>
>>>>>>
>>>>>>>Howdy!
>>>>>>>
>>>>>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>>>>>news:D 8csfg0c2t@enews1.newsguy.com...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Yes, there are two different versions. The one you are running is
>>>>>
>>>>>32-bit.
>>>>>
>>>>>
>>>>>>>>The new release is 64-bit and requires a 64-bit cpu, which the P4 is
>>>>>
>>>>>not
>>>>>
>>>>>
>>>>>>>and
>>>>>>>
>>>>>>>
>>>>>>>>never will be. Needless to say, but I'll say it, the 64-bit version
>>>>>
>>>>>will
>>>>>
>>>>>
>>>>>>>not
>>>>>>>
>>>>>>>
>>>>>>>>run on your P4.
>>>>>>>
>>>>>>Well, as you can see, this makes absolutely no sense to me.
>>>>>>
>>>>>>Is it a true 64-bit chip? Or are they performing translation
>>>>>>acrobatics
>>>>>>somehow?
>>>>>
>>>>> It's 32 bits in and out, but runs 64 bit instructions.
>>>>>
>>>>> Once you figure out which it is, you can tell me.
>>>>>
>>>>> I figure it's like the 8088 (an 8 bit processor than ran 16bit
>>>>> 8086
>>>>>code), the 386SX (a 16 bit processor than ran 32bit 80386DX code), and
>>>>>the
>>>>>68008 (an 8 bit processor than ran 68000 16bit code).
>>>>>
>>>>> IOW - Business as usual for Intel and other manufacturers.
>>>>>
>>>>> RwP
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>Okay, I get it. It isn't really a 64-bit CPU if it is 32-bit in and out.
>>>>At least not to me.
>>>
>>>Of course it is. The 'in/out' is simply how the data lines are
>>>multiplexed.
>>
>>
>>
>> In the sense that it will run the 64 bit code, yes it is. As far as the
>> real benefit of running a 64-bit bus, no it isn't.
>
> Even that depends on what one thinks the 'benefit' is. The addressing and
> data are all still there but potentially with a speed penalty. But even
> that would depend on the bus clock.
>
> The address bus is multiplexed in all the processors but you consider it
> 'all there' don't you?
>
>>
>> Ed Cregger
>

I am looking at it from the speed penalty point of view. Other than for
increased bandwidth reasons, most folks upgrade for speed increases. If one
is desperate enough to run 64-bit software in any environment, regardless of
the speed, then they might find the 32-bit/64-bit machine useful. But it
would be a stop gap measure at best. I did just that at one point with the
16/32 bit change, but it wasn't long until the choked down computer was
shelved and replaced. It was a waste of money for me.

The last SX I received was a gift. I would not have bought one, even for
nostalgia. In fact, I may still replace it with a 40 MHz 386. I mentioned to
the sister-in-law that I wanted an old DOS machine on which to run Windows
5.1 in original style. Yes, I know WP 5.1 can be ran on modern computers.
But that takes the fun away from the nostalgia trip. 8^>

Ed Cregger
Anonymous
a b B Homebuilt system
a b à CPUs
June 15, 2005 8:21:11 PM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

Ed Cregger wrote:

> "David Maynard" <nospam@private.net> wrote in message
> news:11at20dep5cfu1e@corp.supernews.com...
>>Ed Cregger wrote:
>>>"David Maynard" <nospam@private.net> wrote in message
>>>news:11as5sf8s17qo16@corp.supernews.com...
>>>>Ed Cregger wrote:
>>>>>"Ralph W. Phillips" <ralphp@techie.com> wrote in message
>>>>>news:3h4bkcFf4qfcU2@individual.net...
>>>>>>Howdy!
>>>>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>>>>news:D 8f2ep02p96@enews2.newsguy.com...
>>>>>>>"Ralph W. Phillips" <ralphp@techie.com> wrote in message
>>>>>>>news:3gv34jFeh7q2U1@individual.net...
>>>>>>>>Howdy!
>>>>>>>>"Ed Cregger" <ecregger@homtail.com> wrote in message
>>>>>>>>news:D 8csfg0c2t@enews1.newsguy.com...
>>>>>>>>>Yes, there are two different versions. The one you are running is
>>>>>>
>>>>>>32-bit.
>>>>>>>>>The new release is 64-bit and requires a 64-bit cpu, which the P4 is
>>>>>>
>>>>>>not
>>>>>>>>and
>>>>>>>>>never will be. Needless to say, but I'll say it, the 64-bit version
>>>>>>
>>>>>>will
>>>>>>>>not
>>>>>>>>>run on your P4.
>>>>>>>>
>>>>>>>Well, as you can see, this makes absolutely no sense to me.
>>>>>>>
>>>>>>>Is it a true 64-bit chip? Or are they performing translation
>>>>>>>acrobatics
>>>>>>>somehow?
>>>>>>
>>>>>> It's 32 bits in and out, but runs 64 bit instructions.
>>>>>>
>>>>>> Once you figure out which it is, you can tell me.
>>>>>>
>>>>>> I figure it's like the 8088 (an 8 bit processor than ran 16bit
>>>>>>8086
>>>>>>code), the 386SX (a 16 bit processor than ran 32bit 80386DX code), and
>>>>>>the
>>>>>>68008 (an 8 bit processor than ran 68000 16bit code).
>>>>>>
>>>>>> IOW - Business as usual for Intel and other manufacturers.
>>>>>>
>>>>>> RwP
>>>>>>
>>>>>Okay, I get it. It isn't really a 64-bit CPU if it is 32-bit in and out.
>>>>>At least not to me.
>>>>
>>>>Of course it is. The 'in/out' is simply how the data lines are
>>>>multiplexed.
>>>
>>>In the sense that it will run the 64 bit code, yes it is. As far as the
>>>real benefit of running a 64-bit bus, no it isn't.
>>
>>Even that depends on what one thinks the 'benefit' is. The addressing and
>>data are all still there but potentially with a speed penalty. But even
>>that would depend on the bus clock.
>>
>>The address bus is multiplexed in all the processors but you consider it
>>'all there' don't you?
>>
>>
>>>Ed Cregger
>>
>
> I am looking at it from the speed penalty point of view. Other than for
> increased bandwidth reasons, most folks upgrade for speed increases. If one
> is desperate enough to run 64-bit software in any environment, regardless of
> the speed, then they might find the 32-bit/64-bit machine useful. But it
> would be a stop gap measure at best. I did just that at one point with the
> 16/32 bit change, but it wasn't long until the choked down computer was
> shelved and replaced. It was a waste of money for me.

Very well might not be the solution for you but that doesn't mean it isn't
a 64 bit (or 32 bit, depending on which one is the topic) processor. Just
one that's slower than you'd like.

Same case as a 32 bit processor on a 66MHz FSB vs 100Mhz vs 133MHz vs
166Mhz vs 200Mhz, FPM vs EDO vs SDR vs DDR, with or without cache, or
motherboard vs on-die, full speed or half speed or FSB speed, or 256K vs
512K vs 1 Meg vs 2 Meg cache and a host of other things. Still, they're all
"32 bit processors" but certainly not the same performance.

It's the internal bus, accumulator(s), and ALU that it's referring to.

Btw, just to further confuse things ;)  What you would likely consider a
'true' 32 bit processor doesn't have a 32 bit wide (external) data bus
either. It's 64 bit wide. Ponder that mystery <grin>.

> The last SX I received was a gift. I would not have bought one, even for
> nostalgia. In fact, I may still replace it with a 40 MHz 386. I mentioned to
> the sister-in-law that I wanted an old DOS machine on which to run Windows
> 5.1 in original style. Yes, I know WP 5.1 can be ran on modern computers.
> But that takes the fun away from the nostalgia trip. 8^>

Hehe

I have a couple of Windows 3.1 nostalgia machines too. Zippy even on a 16
Meg 486.

>
> Ed Cregger
>
>
June 26, 2005 4:49:23 AM

Archived from groups: alt.comp.hardware.pc-homebuilt (More info?)

On Mon, 13 Jun 2005 00:23:34 -0400, "Ed Cregger"
<ecregger@homtail.com> wrote:


>Okay, I get it. It isn't really a 64-bit CPU if it is 32-bit in and out. At
>least not to me.
>
>Yup, I'm familiar with the 386SX chips. In fact, I own an old system that
>was a gift from my sister-in-law. A bit of nostalgia. They (the 386SX)
>always seemed to be a waste of time and effort to me. An interim, stop-gap
>measure at best and a waste of Intel's resources. Not to mention their
>customer's money. Customers that were fooled into thinking something that
>did not provide the benefit that was promised.
>
>Ed Cregger


Excuse me, but there seem to be some misunderstanding regarding these
bits. Maybe I can clear that up.

(you are correct about the '386SX having only a 16-bit bus, and it
very likely had an obvious effect on performance vs '386DX. But it has
nothing to do with the '386's 32-bitness in terms of software
capability. It's just a performance feature, like the original
Pentiums 66MHz 64-bit bus, and the PCI architecture, etc.)

First of all, there is widespread temptation to interpret
"cpu-bitness" as some width of computing that has directly with
performance to do. That is not correct. It has to do with the
capability of the CPU to do things. - At all.

In the specific regards of what is called "64-bit class computing"
generally, and in regards of 16-, 32- and 64-bit
computing/CPU/software/OS on the PC particularly, the bits refer to
the length of the address field that a machine instruction use to
refer to any code or data. This is the only kind of "CPU-bitness" that
is meaningful today.

One very old, but common, convention was to refer to the width of data
registers. That quickly had to be qualified as "general purpose
registers", due to developments.
(Well, both the AMD K8 line (A64), and Intel's EM64T enabled Prescott
line, have 64-bit GPRs.)
This "bitness" is still greatly favored by old men, who have been in
the industry for a long while. They sometimes also vehemently claim
that it represents some kind of "definition" of cpu-"bitness".

Well, I believe that "definition" talk is rubbish. But enough
nonsense, because it really doesn't matter anyway. The main problem
with using register length, any register length, for understanding
"cpu-bitness", is that it is completely meaningless. It doesn't really
directly say anything about the CPUs properties, in the sense of what
kind of class of computing the CPU is capable of, or suitable for.

The annoying thing for all rigid 'systematizists', is that there isn't
any single bit-thing, that is consistent through the ages and CPU
developments, in saying anything meaningful, without also being
misleading, about the class of a CPU.



CPU-BITNESS:

- It is a property of the machine instructions provided in the ISA!

The only thing that is interesting today, in any context of "64-bit
class computing", is the length of an address, that a native binary
instruction can use.

Similarly, "16-bit", "32-bit" computing, in terms of PC use, _ALSO_
refers to the instructions address length. If you believe it to be
anything different, you've been assuming wrongly.

The '286 (16-bit) added a new processor personality to the 8086 (also
16-bit). The new one featured protected mode addressing and a
different segmented addressing that made a larger space available.
That means nothing for old 8086 software. That runs with the same
limitations on the old personality, which is kept for compatibility
reasons.

The '386 (32-bit) added a new processor personality to the '286. It,
again, means nothing for old software, which still has to run on the
old personalities. But new software, written and compiled for the
'386, can do 32-bit addressing, and can also have a flat virtual
space, instead of segmented. It wasn't put much to use, before
Windows95, though.
That is really what happened when Win95 came. We started to use a
'processor' that actually was already introduced with the '386.

Same again with AMD86-64 (Intel calls it EM64T, but that's not the
proper name). It effectively adds a 64-bit processor to the collection
of old processor personalities, already available. The A64 basically
represents four different CPUs in the same package. 8086, '286, '386
and AMD64.
Again, we're not using the 64-bit part yet. I suppose we'll have to
wait for Longhorn.




WIDTH OF COMPUTING AND WIDTH OF DATA

It is true that increased computing width can be exploited for
increased performance. But that has already been going on for quite a
while, and doesn't affect the fundamental 32-bitness of our earlier
Pentiums and Athlons.
For instance, already the first original Pentium introduced 64-bit
data bus. And the P4 have 128-bit data bus in two 64-bit channels.

The Pentium Pro, PentiumII/III, AMD K6 and Athlon also continued to
aggressively pursue increased width of internal execution as means to
increase performance.

Taking the modern K8 (A64, X2, Opteron) as example, the logical
execution width of the core is 192 bits. That is the number of
computed data bits that can be committed every cycle.
Does that make the K8 a 192-bit CPU?
Well, let me put it this way: - For those who think that 32-bit is
twice as fast as 16-bit and 64 twice as fast as 32-bit, and ask for a
"128-bit processor", or are expecting that soon, as next logical
evolutionary step, - yes it does ;)  .
3 execution pipelines, 64 bit wide = 192 bits.

In hardware terms it is even considerably wider. Which is often
observed in schematics of these CPUs. And leads to misunderstandings.
But the number of hardware execution units is of secondary importance.
These are connected to the pipeline, and used by it. It's the pipeline
that controls execution

Intel's next major core technology, 'Conroe' (Pentium5?, it will
probably debut as a mobile cpu, 'Merom') will be even wider, 256-bit.
4 pipelines. Observe that this is per core. A four core CPU will be
1024 bits wide, in the sense of data width computed.
In regards of what kind of software it can run, it is 64-bit!
Which is the kind of bitness we are discussing.




WIDTH OF REGISTERS

Now lets discuss the width of registers for a while.
The length of a register is for accommodating the data type that is to
be processed. Any excess length is wasted.
Floating point numbers are 32 or 64 (double precision) bits long. And
guess what, - we already have had 64-bit FP registers ever since the
FPU was integrated in the '486DX.
Characters are 8 or 16 (unicode) bits long.
Counters, indexes, identifiers, flags, masks, and other integers can
be 16, 32, or even 64 bit.
But there are few reasons to use integers longer than 32 bit. They
exist, but the opportunities to increase performance by fitting longer
integers into a single register are fairly rare.

However: What about processing several pieces of data collectively?
Right, again we have been doing exactly that for quite a while
already. We have 128-bit and 64-bit wide SIMD registers. These are
used to handle two 64 bit, four 32 bit, four 16 bit or eight 8 bit
data simultaneously. This also didn't make the 32-bit processor either
64-bit or 128-bit.

However: Pointers are also integers. And here we have the real reason
for expanding integer register width to 64 bits in AMD86-64. Because
we want to use 64-bit pointers! 64-bit software uses 64-bit pointers.

One further thing about "registers" that need to be mentioned, is that
they more and more, are mainly something that the instruction set
makes "visible", as part of the CPU's software interface, and virtual,
functional model. And something that less and less, has any direct
correlation in the actual hardware.

In terms of data storage&accumulation devices, that are available to
execution units, both P4 and K8 have hundreds. (And yes again, at
least in the K8, all of them are generalized to at least 64 bits.)
These are not visible in the ISA.
The ones the ISA defines, relates to the formal function model. The
program interface. Not to how the hardware actually goes about doing
its thing.

For instance the 128-bit SIMD registers. This is not how the hardware
handles it. For the hardware, a vector instruction (SIMD) expresses
explicit parallelism, that is more expedient and simple to schedule in
its multiple parallel pipelines. It will however handle the data in
separate 32 or 64 bit chunks, and again assemble the 128 bit segment
at the end. So the 128-bit registers are to a degree only 'virtual'.
But this doesn't represent any cheating, or compromised performance.
Quite the contrary. It's part of a decoupling that makes the CPU
scalable.




64-BIT AND PERFORMANCE

Much of the performance improvement from 32-bit code vs 16-bit code
came from the fact that we abandoned a segmented virtual memory model,
and adopted a flat, linear virtual memory model instead.
The idea that 32- vs 16-bit is about computing things in larger chunks
is essentially false. There is that too, to some extent. But it's not
the main thing.

This time, we are retaining the flat virtual memory model. 64-bit
makes it bigger (which is essential, and highly needed), but that's
all. So actually, we would have no direct reason to expect a
performance improvement from going to 64-bit software.

We will, however. But that's not so much from going to 64-bit, as
actually switching to a new ISA, that provides twice as many
registers, and makes the integer registers all general purpose.

Both the 600-, 501-, 800- series Pentium4/PentiumD and A64/Opteron/X2
must be considered "true" 64-bit CPUs, IMO.
However, Intel have done a modification to a 32-bit design already
underway. While AMD did a 64-bit design from scratch. Perhaps that is
the reason why Intel don't see the same performance improvement from
64-bit code vs 32-bit code?
But it could just as well be due to compiler optimizations in gcc. I
don't know.
I believe Intel also have an issue with memory mapping beyond 4GB,
which at least appear to be due to 64-bit mapping being strapped onto
old 32-bit mapping. Other evidence of that is Intel's 36 bit limit.

It doesn't matter much, as AMD is so much faster, cooler, more stable
today, and cheaper as well.
I'm sure that will change. But clearly, people who purchase Intel
right now, do so for other reasons than technology, economy or
performance.
!