Will Prescott work on Win64?
zalzon
have "64 bit extentions".
I know its a 32 bit chip, but does this mean it could work on Win64 by
emulating a 64 bit processor?
We are straddling the 32 to 64 bit transition time frame here. Is it
worth waiting for 64 bit chips to establish themselves on the market
before upgrading?
Now if you listen to Intel, they say they are not sure whether 64 bit
is ready for the desktop yet. That may be because they don't have a
64 bit desktop chip yet and are trying to play down the whole affair.
But if that is the case, why are they introducing 32 bit chips like
centrino and prescott?
I don't know what to do now. I need to upgrade but I don't want to
upgrade to something which lasts only a short while before yet ANOTHER
upgrade is needed.
Wes Felter
> Read an article down at The Inquirer which mentions that Prescott will
> have "64 bit extentions".
That's speculative. It may or may not be true.
> 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.
> We are straddling the 32 to 64 bit transition time frame here. Is it
> worth waiting for 64 bit chips to establish themselves on the market
> before upgrading?
I don't think so. If you don't need 64-bit today, you probably won't need
it next year either.
--
Wes Felter - wes...@felter.org - http://felter.org/wesley/
Joe Pfeiffer
> On Wed, 22 Oct 2003 14:35:12 +0000, zalzon wrote:
>
> > Read an article down at The Inquirer which mentions that Prescott will
> > have "64 bit extentions".
>
> That's speculative. It may or may not be true.
>
> > 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.
I'm not sure what part of his sentence you're saying "no" to here. If
the speculation that it'll have AMD's 64 bit instructions is true,
then I'd expect it could run win64. If you're objecting to his use of
the term "emulate", well, no, it would be a 64 bit processor.
> > We are straddling the 32 to 64 bit transition time frame here. Is it
> > worth waiting for 64 bit chips to establish themselves on the market
> > before upgrading?
>
> I don't think so. If you don't need 64-bit today, you probably won't need
> it next year either.
Until the first 64 bit killer game comes out...
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair
Wes Felter
> "Wes Felter" <wes...@felter.org> writes:
>
>> 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.
>
> I'm not sure what part of his sentence you're saying "no" to here. If
> the speculation that it'll have AMD's 64 bit instructions is true,
> then I'd expect it could run win64. If you're objecting to his use of
> the term "emulate", well, no, it would be a 64 bit processor.
Right, I was objecting to the idea of a 32-bit processor that has some
kind of 64-bit emulation.
>> > We are straddling the 32 to 64 bit transition time frame here. Is it
>> > worth waiting for 64 bit chips to establish themselves on the market
>> > before upgrading?
>>
>> I don't think so. If you don't need 64-bit today, you probably won't need
>> it next year either.
>
> Until the first 64 bit killer game comes out...
A game that requires more than 4GB of RAM? It will be a few years before
people will be able to afford that.
Nate Edel
> 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.
What makes something a 64-bit processor anyway? ALU width? GP Register
width? Pointer width? Virtual address space size? Physical address space?
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?
> I don't think so. If you don't need 64-bit today, you probably won't need
> it next year either.
Well, that I think most people would agree with that.
--
Nate Edel http://www.nkedel.com/
"But Marge! I've never felt so accepted in my life. These people looked deep
into my soul and assigned me a number based on the order in which I joined."
John Dallman
zalzon...@zalll.com (zalzon) wrote:
> Read an article down at The Inquirer which mentions that Prescott will
> have "64 bit extentions".
It seems fairly unlikely to me that this is correct, in the sense of a
64-bit address space and corresponding instruction set, like an AMD
Opteron. It could be that there's a drastic overstatement of some
different feature. For example, upgrading PAE to allow the chip to handle
really large amounts of physical memory, but still with a limit of 4Gb of
address space per process. However, AFAIK, the story is based on
interpretation of die photographs, and while such a picture - with a scale
- can tell you a bit about pinouts and cache sizes, I strongly suspect
that this story is based on over-interpretation.
> I know its a 32 bit chip, but does this mean it could work on Win64 by
> emulating a 64 bit processor?
Well, yes, in an absolute sense. But probably not for practical purposes.
I've used an Itanium emulator on 32-bit x86. The net 64-bit performance
was about 1% of the raw performance of the 32-bit processor. An emulator
could be a whole lot better than that and still useless for doing real
work.
If Prescott had a real 64-bit mode, Intel might want to keep it quiet as
long as possible, but since the chip's due for introduction in a couple of
months and third parties are working on motherboards, one would feel it
would have leaked out by now, somehow. There'd be more information about
it than the Inquirer story.
They might be trying to keep it quiet until operating systems and software
were ready, but one Inquirer story that I believe is that Microsoft would
be extremely reluctant to support two incompatible 64-bit x86 instruction
sets. And Intel probably have too much pride to sell something that's AMD-
compatible.
> We are straddling the 32 to 64 bit transition time frame here. Is it
> worth waiting for 64 bit chips to establish themselves on the market
> before upgrading?
It depends, entirely, what you're using your computer for. Some hint about
that would make it more possible to give sensible answers.
> Now if you listen to Intel, they say they are not sure whether 64 bit
> is ready for the desktop yet. That may be because they don't have a
> 64 bit desktop chip yet and are trying to play down the whole affair.
Well, since they don't have a 64-bit desktop-targeted chip ready with all
the software to take over from the 32-bit chips they make a living out of,
they'd be foolish to talk up the idea. Please remember that statements
like that from any company are largely marketing-driven.
There are applications in MCAD and ECAD, for example, where 64-bit
desktops are genuinely useful now, and have been for a few years. They
just aren't using Windows, or Intel processors, very much. This is
starting to change, but fairly slowly, because people who are used to
64-bit UNIX desktops often resist being switched to Windows, for a variety
of reasons.
> But if that is the case, why are they introducing 32 bit chips like
> centrino and prescott?
If they don't have a 64-bit chip ready, they still need to keep on
introducing new chips, or their marketing department will become
under-employed. It's a whole lot quicker and simpler to modify and upgrade
an existing design to something better, but not drastically different,
than it is to do a complete redesign.
> I don't know what to do now. I need to upgrade but I don't want to
> upgrade to something which lasts only a short while before yet ANOTHER
> upgrade is needed.
Well, an Opteron or Athlon 64 will run all the existing x86 32-bit
software, and its own 64-bit code. That seems to be the most versatile PC
processor available at present. Will it succeed? Well, there are much
bigger bets than your machine upgrade budget on it. Both ways.
---
John Dallman j...@cix.co.uk
"Any sufficiently advanced technology is indistinguishable from a
well-rigged demo"
Douglas Siebert
>A game that requires more than 4GB of RAM? It will be a few years before
>people will be able to afford that.
2GB costs only about $250 now, that's the limit of what Win32 will let
you use for a process (without PAE) isn't it? A lot of the game freaks
will spend that much for 512MB just to get memory that can be overclocked
to match their increased bus speed (perhaps a hidden advantage of Athlon
64 for gamers that this wouldn't be required?) When they are spending
$500 on a top end video card, buying extra RAM if required for the coolest
new game isn't that much of a stretch.
--
Douglas Siebert dsie...@excisethis.khamsin.net
"I feel sorry for people who don't drink. When they wake up in the morning,
that's as good as they're going to feel all day" -- Frank Sinatra
Douglas Siebert
>If Prescott had a real 64-bit mode, Intel might want to keep it quiet as
>long as possible, but since the chip's due for introduction in a couple of
>months and third parties are working on motherboards, one would feel it
>would have leaked out by now, somehow. There'd be more information about
>it than the Inquirer story.
Why? They could have the 64 bit mode in there but not be planning on
telling anyone UNLESS Opteron takes off due to its 64 bit support, and
then magically a new motherboard rev (or possibly even BIOS rev) will
allow 64 bit operation. But only for Xeon. If Athlon 64 takes off, then
suddenly it'd be supported on desktops as well.
If Opteron and Athlon 64 are mostly sold as fast 32 bit CPUs, they'd just
keep it quiet because they know that 64 bit capability in x86 will kill
any chance for their plans to move Itanium out of its ever-shrinking high
end "replace PA-RISC, Alpha and MIPS" niche down smaller servers and
desktops.
<wild speculation>
My hunch is that when Intel found out MS was going to support AMD64 they
told them they were putting a hidden 64 bit capability in x86 "just in
case" and wanted them to support it as well. MS said no, but agreed to
delay AMD64 support until Intel could get themselves ready for it "just
in case". This latest Windows 64 delay until early next year seems a
mite suspicious to me considering they've been working on 64 bit Windows
for how many years now, and have it more mature on Itanium which is a
lot weirder architecture than the simple evolution of x86. Comes just
when rumors appear that Intel is delaying Prescott from early Q4 to
sometime in Q1.
</wild speculation>
Neo
>
> 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?
This subject arises every now and then...
What defines the bitness of an architecture is its instruction set
(ISA). The implementation details like the iwdth of the ALU or of the
internal or external data paths, the available address pins, etc, are
imaterial to the ISA.
In this specific case, the 68K had a 32-bit ISA. Period. The 68020
had 32-bit ALU and data and address paths, but the ISA was the same.
Hades! The 80486 had an 80-bit FP ALU. Was it an 80-bit chip? What
matters is its 32-bit ISA.
And this is as far as I go in this discussion.
Nate Edel
> arch...@sfchat.org (Nate Edel) wrote:
> > 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?
>
> This subject arises every now and then...
> What defines the bitness of an architecture is its instruction set
> (ISA).
I'm inclined to agree.
But take a 32-bit ISA, add 64-bit extensions, and run those extensions on an
core with primarily 32-bit datapaths and integer execution units, and it's
starting to sound a lot like (in layman's language) what the prior person
said about Prescott "emulating 64 bits."
I have no idea if that's what Prescott does, or if it has any 64-bit
extension at all, but it's not an implausible concept.
Ancra
wrote:
>Read an article down at The Inquirer which mentions that Prescott will
>have "64 bit extentions".
No. There's no chance for that.
Intel probably have some emergency 64cpu in secret works.
It might be that its hardware design follows the same concept as the
P4/P5. For the simple reason that this is the only architecture Intel
have been "successful" with, for quite some time. It should be
tempting for Intel to use solutions similar to the P4/P5 in a new
64-bit cpu.
Just as the Athlon64s execution unit looks somewhat like the Athlons.
But it's not the same, and doesn't contain any part from the Athlon.
Intel too will have to do it all from the ground.
It may also contain an entire P4-derivate inside, as an expedient way
of supporting 32-bit code (though that would be wasteful of
transistors). But they will have to do all the 64-bit wiring and
memorymanagement from scratch.
And that chip won't be the Prescott.
Otherwise it might be they're stuffing a P4/P5 into their ol' Itanium.
That won't be the Prescott either.
They're doing something. What, is just speculations. Their secrecy
could be indicative of that it's an AMD64 compatible cpu. They
wouldn't want people to know that, since it would clearly point to
AMD's architecture as the future for 64-bit software. That would pull
the rug on their Itanium and gain AMD more momentum in their early
start, maybe years before Intel is ready to compete.
Intels silence could also be indicative of that they actually don't
have any 64-bit act together.
I wouldn't count on Intels 86-extended 64-bit cpu being AMD
compatible. It would be nice, but I wouldn't count on it. I wouldn't
count on seeing any trace of Intels 86-64 like any time soon, either.
>I know its a 32 bit chip, but does this mean it could work on Win64 by
>emulating a 64 bit processor?
No. It cannot work like that. You need an ocean to navigate a
containerliner. It doesn't fit in a pond.
>We are straddling the 32 to 64 bit transition time frame here. Is it
>worth waiting for 64 bit chips to establish themselves on the market
>before upgrading?
Computer tech shouldn't be bought before you need it. It's value drops
way too fast, just sitting there on your desk. Is that "yes" to you?
But say you want to have a fast 32-bit cpu, and are prepared to pay
$400 - $700 for it... Athlon64 happen to also be that '32-bit cpu'.
>I don't know what to do now. I need to upgrade but I don't want to
>upgrade to something which lasts only a short while before yet ANOTHER
>upgrade is needed.
Seriously, it's the way of computing. And frequent upgrades is a cheap
way to have performance. Buying high end, 'lasts' only a couple of
months longer, and is an expensive way of staying obsolete most of the
time. The trick is to stay away from top performance. Drop down to 80%
performance and the cost is 15%. As for "short while" I think the time
until we have a desktop Windows64 and some 64-bit software might be
just about right for a cheap intermediate upgrade. Just don't go
blowing a lot of money on 3.2 GHz P4s or similar.
I wouldn't buy an Athlon64 now, because I don't buy +$400 cpus.
As always, and as a lot of people point out all the time, you can get
really decent performing cpus from AMD for $50-$90! Fabulous value.
(Why is anybody buying anything else, like. ;))
My take is that AMD aimed slightly on the side with their early
releases, A64 socket754 & AFX.socket940
Socket939 will eventually be available, and seems more desirable.
754pin A64 is still going to be much cheaper though, so I guess that's
what I'll buy, eventually. ...For starters.
I also wan't to see more about how the chipsets do. As long as there
is no OS, why hurry?
ancra
Ancra
wrote:
First of all, I object to the idea of 4GB being expensive ;).
I think the cost of RAM and hardrives suggests that the time for
64-bit computing has come.
Secondly, you're off target a bit:
Win32 only gives an app 2GB process space, not 4.
For a win32 app to enjoy 4GB process space you need a 64-bit OS
running on a 64-bit cpu. (that certainly doesn't mean you will
automatically get that though, only what is possible).
Thirdly, we're talking process space here. Nice to have ram for it,
but not necessary for making use of it. Address space is the range of
numbers an app can have as unique byte addresses. Wherever those
addresses are mapped to. Doesn't even have to be mapped at all. Could
be just reserved blocks. Ram is nice, but doesn't limit the usefulness
of a 64-bit address space.
A 64-bit game will use, but will not require massive ram. Hd swap
space will do nicely.
Problem for a hypothetic complex VR 32-bit game, featuring a large,
open 3D-world, is that handles and objects of that world, have to be
successively destroyed, to free up space for later accessed objects.
Then later be regenerated again.
This is both wasteful and bugprone, and also puts a number of
difficulties and constraints on causality and world dynamics.
The world model would be much simpler and more powerful in a 64-bit
game.
There is also the tantalizing vision of games featuring completely new
ideas. Not seen or contemplated yet, due to 32-bit addressing not
allowing the models.
Sofar though, the Athlon64s are just fast 32-bit cpus. Nicely priced
too (as fast 32-bits). But we need 64-bit OS and apps to get 64-bit
computing.
The good news is that MS have finally committed themselves bigtime to
AMD's 86-64. They will release W2003 server in AMD64 standard and
enterprise editions supporting single and multiple cpus, ASAP.
I get a strong feeling that MS is experiencing a demand for an OS for
Opterons from customers, and less interest in their Itanium version.
Well they backed the wrong horse. Now that they've figured that out,
we should see some action.
The bad news is that it still won't happen until a good bit into 2004,
and there is no word of when the desktop WinXP-AMD64 will be out.
So when will the apps and games come?
Much as I want AMD to have success with their Athlon64, and as much as
I think the time of 64-bit computing is ASAP, I agree with your
assessment that we're in for bit of waiting. Unfortunatly.
ancra
Ancra
wrote:
>In comp.arch Wes Felter <wes...@felter.org> 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
Bill Bradley
> The bad news is that it still won't happen until a good bit into 2004,
> and there is no word of when the desktop WinXP-AMD64 will be out.
Unofficially first quarter 2004. I've got a beta copy of it from
Microsoft right here: Microsoft Windows XP 64-bit Edition Version 2003,
Beta 1 Build 1069. It was running quite happily on the systems at the
launch on Sept 23rd. It was hapily running the current build of
American Army (64-bit), and Unreal Tournament 2004 at the San Fransico
launch event [not just for the event but for seven hours solid at the
vendors demo area]. The only complaint that I've heard is the lack of
64-bit drivers from the hardware vendors.
> So when will the apps and games come?
America's Army already runs 64-bit, and talking to the lead programmer
from Epic Games (whose name escapes me at the moment) the new UT 2004
has been running on the 64bit OS (on Opteron systems), which they were
pretty happy about since the "current" unoptimized builds still ran at
playable speed which was not the case with previous versions of the
software.
> Much as I want AMD to have success with their Athlon64, and as much as
> I think the time of 64-bit computing is ASAP, I agree with your
> assessment that we're in for bit of waiting. Unfortunatly.
From what I saw at the Athlon 64 launch and talking to vendors
afterward I'd bet on <6 months for the first wave.
Bill
Nate Edel
> As always, and as a lot of people point out all the time, you can get
> really decent performing cpus from AMD for $50-$90! Fabulous value.
> (Why is anybody buying anything else, like. ;))
Personally, I'd buy a P4/2.4C -- 25% more memory bandwidth than a comparable
AMD chip, and only a bit more expensive than the comparable AMD chips (about
$180 vs. about $150). AMD really needs to push the faster FSB into a rev of
cheaper chips than the 3200+.
> 754pin A64 is still going to be much cheaper though, so I guess that's
> what I'll buy, eventually. ...For starters.
I heard at one point a long while ago that AMD was considering a generation
of 32-bit Athlons on 754. Don't know if that's gone anywhere.
Tarjei T. Jensen
> Personally, I'd buy a P4/2.4C -- 25% more memory bandwidth than a
comparable
> AMD chip, and only a bit more expensive than the comparable AMD chips
(about
> $180 vs. about $150). AMD really needs to push the faster FSB into a rev
of
> cheaper chips than the 3200+.
If you pay $150 for an Athlon 2500XP you have been fleeced. It costs NOK 800
in Norway and that translates usually to less than $80 for the US.
greetings,
Tarjei T. Jensen
"Ancra" wrote:
> First of all, I object to the idea of 4GB being expensive ;).
> I think the cost of RAM and hardrives suggests that the time for
> 64-bit computing has come.
According to
http://firingsquad.com/hardware/building_gaming_opteron_2003_Part2/page14.as
p a machine having 4GB might be slower than a machine having 1GB. Looks like
speed goes down as you add more memory slots. At least if you have an AMD
CPU.
greetings,
John Kang
> "Wes Felter" <wes...@felter.org> writes:
>
>
>>A game that requires more than 4GB of RAM? It will be a few years before
>>people will be able to afford that.
>
>
>
> 2GB costs only about $250 now, that's the limit of what Win32 will let
> you use for a process (without PAE) isn't it? A lot of the game freaks
> will spend that much for 512MB just to get memory that can be overclocked
> to match their increased bus speed (perhaps a hidden advantage of Athlon
> 64 for gamers that this wouldn't be required?) When they are spending
> $500 on a top end video card, buying extra RAM if required for the coolest
> new game isn't that much of a stretch.
>
Well, being one of these people, I can tell you that having more than 1
GB does not increase modern gaming performance. In fact, more than
512MB usually does nothing. We spend $500 on a video card and $300 for
fast memory because those things improve gaming performance. Having
more than 2GB of memory will not help gaming performance for a long
time. Not until games come out that saturate that much memory. Last I
heard, none of the next-gen games (Doom3, Half-life 2, etc) will.
John Kang
I think this issue was specific to the P4 and the use of unregistered
memory. That review showed that when using registered DIMMS on an
Opteron, having lots of memory does not decrease performance.
John Kang
Only the x87 FP registers were 80-bits. The GPR's were still 32-bit.
Besides, how do you define "32-bit ISA"? How much memory it can
address? Default integer operand size? IA-32 still considers a 16-bit
integer as a "word", does that mean it's still a 16-bit ISA?
Nate Edel
I tend to see the 2500+ right around $95-100 still (at least boxed, and for
the non-boxed model, you'll easily pay around $20 for a good fan, while the
AMD-made fan is fine if you don't overclock.)
I personally have found the P-ratings on the Barton chips to be a bit
optimistic -- especially as compared to the the DDR400/"800mhz" FSB P4s. I
was thinking of the 2700+ when I said "about $150."
The faster FSB makes a big difference -- compare the P4/3.06 to the 3.0 and
even on some benchmarks, the 2.8C for a dramatic demonstration. On the AMD
chips 333mhz is certainly better than the 266/"533" of older P4s, as is the
nForce's implementation of dual channel memory as compared to 845 based
boards. But right now I think in the midrange AMD is taking a big hit
compared to the "unapproved" 865 boards and cheaper 875 boards and the
P4 2.4C/2.6C.
AMD's site lists a Athlon64 3000+; I haven't seen pricing on it, but I'll be
curious to see where it goes. The Operton 140s are also looking intriguing,
although at a 1.4ghz clock speed, they're a little too slow to take
that seriously as single-processors.
Tarjei T. Jensen
Nate Edel wrote:
> The faster FSB makes a big difference -- compare the P4/3.06 to the 3.0
and
> even on some benchmarks, the 2.8C for a dramatic demonstration. On the AMD
> chips 333mhz is certainly better than the 266/"533" of older P4s, as is
the
> nForce's implementation of dual channel memory as compared to 845 based
> boards. But right now I think in the midrange AMD is taking a big hit
> compared to the "unapproved" 865 boards and cheaper 875 boards and the
> P4 2.4C/2.6C.
It has been reported that the latest VIA (?) chipset which used a single
memory channel performed better than the nForce chipset.
> AMD's site lists a Athlon64 3000+; I haven't seen pricing on it, but I'll
be
> curious to see where it goes. The Operton 140s are also looking
intriguing,
> although at a 1.4ghz clock speed, they're a little too slow to take
> that seriously as single-processors.
If I had a say in things, the Athlon XP would have a 400MHz bus and be
available in with the following speeds: 2000, 2500, 3000, 3500 and 4000.
That would have given give Intel a few headaches.
greetings,
Dan Pop
>Only the x87 FP registers were 80-bits. The GPR's were still 32-bit.
>Besides, how do you define "32-bit ISA"? How much memory it can
>address? Default integer operand size?
The size of the GPRs is what usually defines the size of an architecture.
An 8080 can directly address 64 kB of memory, yet it's still an 8-bit
processor.
>IA-32 still considers a 16-bit
>integer as a "word", does that mean it's still a 16-bit ISA?
In many cases, "word" is an almost meaningless term. It's not only IA-32,
but also the now defunct VAX architecture specification that uses 16-bit
"words", for backward compatibility purposes (the VAX architecture was an
extension of the enormously popular PDP-11 architecture, which had a
genuine 16-bit word).
Actually, there are precious few architectures still in use where the
term "word" really make sense, and they're usually used for embedded
control purposes (mostly DSP chips).
"Word" was traditionally related to the memory system of the
architectures that didn't support byte addressing, i.e. each memory
address was a word address. Examples include IBM architectures prior
to the 360, PDP architectures prior to the 11, CDC and traditional
Cray supercomputers. Popular word sizes of these architectures: 12,
18, 36, 60 and 64 bits. With one exception (the 64-bit words of the
Cray vector processors), these sizes are not powers of two.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Ancra
wrote:
>In comp.arch Ancra <somea...@some.domain> wrote:
>> As always, and as a lot of people point out all the time, you can get
>> really decent performing cpus from AMD for $50-$90! Fabulous value.
>> (Why is anybody buying anything else, like. ;))
>
>Personally, I'd buy a P4/2.4C -- 25% more memory bandwidth than a comparable
>AMD chip, and only a bit more expensive than the comparable AMD chips (about
>$180 vs. about $150). AMD really needs to push the faster FSB into a rev of
>cheaper chips than the 3200+.
Of course. If memory bandwidth is important for your main apps
performance, it might be worth the money. Same goes for SSE2.
(The XP2500 is $90 btw.)
My take is that it isn't. It's easy to get brainwashed by published
benchmarks, which for some reason almost exclusively tests SSE2 mpeg
performance.
(The Athlon is so much faster than the P4 on most things I run, that I
think such differences in bandwidth must be irrelevant. Certainly for
me. I have no complaint about my dual channel DDR333 CL2.0.
I have almost no SSE2 apps and a 2.4 P4 and a XP3000+. Mind you, that
P4 is no C, (not even a 533) and I agree that 800FSB has given the
P4's general performance a push. Not enough though, to rid me of my
suspicion that the 800FSB ones too, really are slow GP&FP cpus.)
>> 754pin A64 is still going to be much cheaper though, so I guess that's
>> what I'll buy, eventually. ...For starters.
>
>I heard at one point a long while ago that AMD was considering a generation
>of 32-bit Athlons on 754. Don't know if that's gone anywhere.
I doubt it. Economy have forced AMD to cut staff. They are
concentrating on the Athlon64. It's their new highend '32-bit' chip as
well.
There wouldn't be much point either. 754 pins costs to much for the
AthlonXP.
ancra
Ancra
<tarjei...@akerkvaerner.com> wrote:
Not at all. There is much to say about this, but I'll try to be brief.
First of all, you're talking about a mobo DIMM configuration issue.
Not about a cpu brand or memory size issue. You want two symmetrical
DIMMS for maximum performance.
As someone else have already pointed out, Intel is also affected. Both
i865PE and i875P slows down with more than 2 DIMMs.
As you also see in the tests, the effect on the Athlon64 is mostly
minimal and affects only bandwidth. Compare that to the dramatic loss
of performance for the P4, due to increased latency, when exceeding
1GB ram! But - GEE! - I mean REALLY!
Neither AthlonFX or Opteron is affected at all, so on the contrary,
AMD seem definitly to be the way to go. ;)
BTW. What I really liked about the site you guided me to, was the way
they exposed SiSoft Sandra grossly misleading synthetic benchmarks.
Then, 64-bit computing isn't immediatly about memory performance or
even about direct performance at all. It's about capability.
Performance will follow.
ancra
Ancra
<sen...@NOSPAMstargate.net> wrote:
>Ancra wrote:
>> The bad news is that it still won't happen until a good bit into 2004,
>> and there is no word of when the desktop WinXP-AMD64 will be out.
>
> Unofficially first quarter 2004. I've got a beta copy of it from
>Microsoft right here: Microsoft Windows XP 64-bit Edition Version 2003,
>Beta 1 Build 1069. It was running quite happily on the systems at the
>launch on Sept 23rd. It was hapily running the current build of
>American Army (64-bit), and Unreal Tournament 2004 at the San Fransico
>launch event [not just for the event but for seven hours solid at the
>vendors demo area]. The only complaint that I've heard is the lack of
>64-bit drivers from the hardware vendors.
[Jumpin up and down] - Exciting!
>> So when will the apps and games come?
>
> America's Army already runs 64-bit, and talking to the lead programmer
>from Epic Games (whose name escapes me at the moment) the new UT 2004
>has been running on the 64bit OS (on Opteron systems), which they were
>pretty happy about since the "current" unoptimized builds still ran at
>playable speed which was not the case with previous versions of the
>software.
>
>> Much as I want AMD to have success with their Athlon64, and as much as
>> I think the time of 64-bit computing is ASAP, I agree with your
>> assessment that we're in for bit of waiting. Unfortunatly.
>
> From what I saw at the Athlon 64 launch and talking to vendors
>afterward I'd bet on <6 months for the first wave.
- Really good news! It's really happening then? ...But everything
takes longer than you think, even if you consider that everything
takes longer than you think, even if you consider...
ancra
Rupert Pigott
news:3f988915...@nntpserver.swip.net...
Dan Pop
>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.
Nope, it's the former part (32-bit general purpose registers) that made it
a 32-bit CPU. The 68000 only had 24-bit addressing instructions: the
higher 8 bits of the address registers were not used when the address
of the operand was supplied by an address register, for the simple reason
that the address bus of the 68000 only had 24 bits.
Zak
> I heard at one point a long while ago that AMD was considering a generation
> of 32-bit Athlons on 754. Don't know if that's gone anywhere.
That would be a terribly stupid idea at the moment. AMD64 needs all the
mass it can gather, and a 32-bit 754 chip will probably be just a 64 bit
one with some instructions disabled. No cost savings, but tactically a
wrong message to launch now. Lower clocked Athlon64s would make a lot
more sense.
Now as a Duron replacement it will make sense. But that will be a while...
Thomas
Nate Edel
> memory channel performed better than the nForce chipset.
I haven't looked at the latest benchmarks; the last round of Via benchmarks
I saw -- which were trying to use DDR400 with the 333mhz Bartons -- looked
pretty bad, but it's good to hear that they've caught up.
> If I had a say in things, the Athlon XP would have a 400MHz bus and be
> available in with the following speeds: 2000, 2500, 3000, 3500 and 4000.
> That would have given give Intel a few headaches.
That would, and it would be a very welcome thing. Then again, given that
degree of say in things, I'd just go for dirt cheap Opterons :)
That said, I'm not sure what stops AMD from replacing the 2500+ (1833/333)
with a 2550+(1800/400) and the 2800+ (2083/333) with a 2800+(2000/400) --
while it's a little harder to clock the external bus faster, they've already
got the chip to do it... it seems like just a matter of tweaking the
multiplier.
Nate Edel
> On Thu, 23 Oct 2003 22:16:55 -0700, arch...@sfchat.org (Nate Edel)
> wrote:
> >Personally, I'd buy a P4/2.4C -- 25% more memory bandwidth than a
> >comparable AMD chip, and only a bit more expensive than the comparable
> >AMD chips (about $180 vs. about $150). AMD really needs to push the
> >faster FSB into a rev of cheaper chips than the 3200+.
>
> Of course. If memory bandwidth is important for your main apps
> performance, it might be worth the money. Same goes for SSE2.
> (The XP2500 is $90 btw.)
As I noted elsewhere, I wasn't comparing against the 2500+, but against the
2600+/2700+. In my experience the ratings are a little bit optimistic,
especially as compared to the C-steppings.
As for memory bandwidth, it makes a very big difference in heavily
multitasked workloads, and when doing big builds with gcc or other
programming tools. Amounts of memory, at least up to a point, and disk
bandwidth make even bigger differences, but it's relatively easy to make
both of those "all things being equal." For simulations, memory bandwidth is
less important, but it does seem to make a noticeable difference. SSE2 makes
no noticeable difference at all.
> My take is that it isn't. It's easy to get brainwashed by published
> benchmarks, which for some reason almost exclusively tests SSE2 mpeg
> performance.
Depends on your workloads. Toms Hardware is one of the better sites for
that, and they tend to have a mix of synthetic workloads and gaming
benchmarks.
> (The Athlon is so much faster than the P4 on most things I run, that I
> think such differences in bandwidth must be irrelevant.
What sort of stuff are you running? And what OS?
> Certainly for me. I have no complaint about my dual channel DDR333 CL2.0.
> I have almost no SSE2 apps and a 2.4 P4 and a XP3000+. Mind you, that P4
> is no C, (not even a 533) and I agree that 800FSB has given the P4's
> general performance a push.
Doubling the memory bandwidth, plus some of the memory latency tweaks in the
newer chipsets, would make a huge difference in the performance of the P4.
Just talking P4 to P4, a 2.26/533 tends to outperform a 2.4/400 on most
benchmarks, and that's a much smaller difference in bandwidth.
Would a 2.4C beat a 3000+? I highly doubt it would on anything but raw
memory bandwidth. Would a 2.8C? It might. One of the problems with
benchmarking sites is that they seem to almost entirely concentrate on the
high-end: the 3200+ vs the 3.2, for example.
> >> 754pin A64 is still going to be much cheaper though, so I guess that's
> >> what I'll buy, eventually. ...For starters.
> >
> >I heard at one point a long while ago that AMD was considering a generation
> >of 32-bit Athlons on 754. Don't know if that's gone anywhere.
>
> I doubt it. Economy have forced AMD to cut staff. They are concentrating
> on the Athlon64. It's their new highend '32-bit' chip as well. There
> wouldn't be much point either. 754 pins costs to much for the AthlonXP.
Well, it'll be interesting to see how AMD does pushing the Athlon64s down
into the mainstream -- I don't see buying a $500 processor, but would love
to get my hands on one if they can get a decently fast Athlon64 down to
$200-250.
Bill Bradley
> AMD's site lists a Athlon64 3000+; I haven't seen pricing on it, but I'll be
> curious to see where it goes. The Operton 140s are also looking intriguing,
> although at a 1.4ghz clock speed, they're a little too slow to take
> that seriously as single-processors.
IIRC the 1.8Ghz "3000+" is a mobile processor. I think that this is
really AMD's ace in the hole. Given that laptop/tablet/notebooks are
now over 50% of the profit in the computer industry the mobile Athlon
64s seem to be a better option for the "power users" than the P4Ms.
There were a few networked playing BF1942 the the launch and they were
at least comparable to a high end desktop.
Bill
Bill Bradley
>>Ancra wrote:
>>>The bad news is that it still won't happen until a good bit into 2004,
>>>and there is no word of when the desktop WinXP-AMD64 will be out.
>>
>> Unofficially first quarter 2004. I've got a beta copy of it from
>>Microsoft right here: Microsoft Windows XP 64-bit Edition Version 2003,
>>Beta 1 Build 1069. It was running quite happily on the systems at the
>>launch on Sept 23rd. It was hapily running the current build of
>>American Army (64-bit), and Unreal Tournament 2004 at the San Fransico
>>launch event [not just for the event but for seven hours solid at the
>>vendors demo area]. The only complaint that I've heard is the lack of
>>64-bit drivers from the hardware vendors.
>
> [Jumpin up and down] - Exciting!
On this topic NVidia has released 64-bit drivers for the WinXP 64-bit
beta(http://www.nvidia.com/object/winxp64_52.14), so that least they
seem to be serious about support in the immediate future.
Bill
Ancra
>In <3f988915...@nntpserver.swip.net> somea...@some.domain (Ancra) writes:
>
>>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.
>
>Nope, it's the former part (32-bit general purpose registers) that made it
>a 32-bit CPU.
It's very convenient to have at least as wide registers as the length
of the Instruction Set Adress. But the various hardware widths inside
a processor are almost arbitrary. And indeed varies a lot. Physical
width only confers performance. Software width, OTH is fundamental!
It's the adress length that decides the capabilities of the cpu.
> The 68000 only had 24-bit addressing instructions:
- Really now... :-/
* - The 68000 cpu have 32-bit long instruction set adress format! *
...like all 68k members.
> the higher 8 bits of the address registers were not used when the address
>of the operand was supplied by an address register, for the simple reason
>that the address bus of the 68000 only had 24 bits.
- Really now... :-/ So how can it throw away 8 bits from the
adresslength and get 24-bit physical adress if it doesn't have 32-bit
adress length to start with? (rethorical)
The fact that it only have 24-bit physical bus is completely
irrelevant. That's just a hardware interface. Just like the Athlon64's
40-bit adressbus.
ancra
Ancra
>In <Kz4mb.41867$hp5.13802@fed1read04> John Kang <img...@umail.ucsb.edu> writes:
>
>>Only the x87 FP registers were 80-bits. The GPR's were still 32-bit.
>>Besides, how do you define "32-bit ISA"? How much memory it can
>>address? Default integer operand size?
>
>The size of the GPRs is what usually defines the size of an architecture.
>An 8080 can directly address 64 kB of memory, yet it's still an 8-bit
>processor.
It doesn't work like that, in those neat anal retentive terms.
Unfortunatly, the thing we refer to with bits, when classifying cpus
is not consistent. But then, why should it be? Why assume it is? Why
assume a 30 year old convention can be a guide on what is the
distinctive difference between these later cpu generations?
It is correct that early cpus like 8080 are referred to as 8-bit. That
was consistent with the practice of the time to refer to the 'size' of
computers in terms of their width of data registers. This and 'word'
size was what interested the punchcard geeks in those days.
Size in these terms is an obsolete concept.
All our computers have byte addressing, 8-, 16-, 32-bit integer ops,
32-, 64-bit fp ops. There's no distinctions there anymore. Nothing of
interest. No reason to classify cpus. "WORD"? - Phew! Give me a break!
Size today is number of transistors and cpus, ...and size of
..memory!
Just ask yourself at least one time why. Why are we classifying these
16-32-64 bit processors? What's the crucial property that defines
their abilities? GPR width? - No way! It may fit, but it doesn't have
to. Theoretically it's arbitrary.
When I, MS, Linux-kernel-programmers, IBM, Sun, Intel, AMD, HP,
Motorola and those journalists that actually have a clue, talks about
16-, 32-, and 64-bit cpus, the reason for the classification is the
software they can run.
It's the SOFTWARE! There have to be a hardware implementation to run
the software, but the FUNDAMENTAL PROPERTY is the address length of
the software. This is where the bit's come from!
16-bit cpus run code with 16-bit addresses. Because of this, their
addressing is highly convoluted and contorted. A pointer doesn't fit
in 16 bits. The software itself always has to set a pageselector and
then use the appropriate index into this in the instructions
addressfield.
The necessary mapping operations on top of this, to make sure the
software fits in on the hardware, and fits in between the OS and other
apps, also severely limits the memory space. 16MB, I think for Win16,
collectively, for all apps and OS together.
32-bit cpus run 32-bit code. Here all addresses and arithmetic are
linear. Linear addressing, just by itself, results in a massive
performance boost and simplification of code.
Each process has a single context, featuring 4GB linear space, mapping
addresses to physical space. This confers a thremendous boost in
capabilities of the computer. Process space in windows is 2GB for EACH
app. This is still not enough for voxelobjects, databases, AI, finite
element, solid engineering, games, filmwork... While those apps is
running on 32-bit architectures, they're running into the limits of
the 2GB process space.
64-bit cpus also use linear process space. But because the
instructions address field is now 64-bit wide, the address space is a
whopping 16 EB! While early OS will not feature more than fraction of
that as process space, 4 TB from Windows64, we now have space to grow.
- This is it!
This is the reason AMD, Intel, IBM and Sun are building "64-bit" cpus.
This is why we're even discussing 64-bit cpus right now.
GPR width hasn't a f**k to do with it! It is of course convenient to
have integer registers as wide as addressing. Since these registers
have to do the address arithmetic. Which is why it is usually selected
as the same width as addresslength. But it doesn't have to be. It's
arbitrary. Athlon64 could have had 8, 16, 20, 32, 40 or 128-bit
integer registers. It would affect performance and it would be bad
engineering. But it wouldn't change the fact that it's a '64-bit' cpu,
in the only terms that are interesting or relevant.
Likewise, Intel have extended the Pentium architecure numorous times.
This have added 64-bit registers. They have not extended the integer
registers though. They could have. It's shit easy. But why? It
wouldn't change properties of the cpu. Sorry, 64-bit GPR wouldn't make
it a '64-bit' cpu. It would still be the same 32-bit cpu.
It has to be a new cpu. With new instructions, featuring 64-bit
addresses. And new memory management.
I have no doubt that there are lots of people out there assuming it is
some question of 'width' that affects performance. Like 32-bit is
twice as fast as 16, and 64 bits are twice as fast as 32-bit, much in
the manner of a game console. But that is of course not it at all.
Hardware widths in a cpus are prone to changes and are what you can
afford and make effective use of. Pentiums, Athlons, Athlon64s feature
elements of anything from 16 to 256-bits width. Wouldn't surprise me
if the A64 has some 512-bit wide internal bus in relation to its
caches. But I haven't studied that and I don't know it.
ancra
Rupert Pigott
[SNIP]
> The fact that it only have 24-bit physical bus is completely
> irrelevant. That's just a hardware interface. Just like the Athlon64's
> 40-bit adressbus.
Right, so 6502s were 8 bit.
Cheers,
Rupert
Ancra
Hi, Rupert.
Your posts are really funny, but unfortunatly I don't know what to
make of them. ;) Sorry.
ancra
Dan Pop
>On 24 Oct 2003 13:49:38 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
>>In <3f988915...@nntpserver.swip.net> somea...@some.domain (Ancra) writes:
>>
>>>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.
>>
>>Nope, it's the former part (32-bit general purpose registers) that made it
>>a 32-bit CPU.
>
>It's very convenient to have at least as wide registers as the length
>of the Instruction Set Adress. But the various hardware widths inside
>a processor are almost arbitrary. And indeed varies a lot. Physical
>width only confers performance. Software width, OTH is fundamental!
>It's the adress length that decides the capabilities of the cpu.
>
>> The 68000 only had 24-bit addressing instructions:
>
>- Really now... :-/
>* - The 68000 cpu have 32-bit long instruction set adress format! *
>...like all 68k members.
>
>> the higher 8 bits of the address registers were not used when the address
>>of the operand was supplied by an address register, for the simple reason
>>that the address bus of the 68000 only had 24 bits.
>
>- Really now... :-/ So how can it throw away 8 bits from the
>adresslength and get 24-bit physical adress if it doesn't have 32-bit
>adress length to start with? (rethorical)
You're confusing the with the width of the address registers with the
addressing capabilities of the processor.
>The fact that it only have 24-bit physical bus is completely
>irrelevant.
Nope, it ain't. Plenty of *software* used the high 8 bits of the 68000
pointers for other purposes and failed to work on the later members of
the 68k family that had 32-bit addressing capabilities.
>That's just a hardware interface. Just like the Athlon64's
>40-bit adressbus.
Which merely goes to show that the 64-bitness of the Athlon64 is not
dictated by its addressing capabilities.
Pentiums have been able to address more than 4GB of memory for quite
a while, yet no one claimed that they're more than 32-bit processors.
Just as in the case of 8-bit processors, all of them being able to
address more than 256 bytes of memory. So, whether you get it or not,
the size of an ISA is *not* determined by its addressing capabilities.
It's the size of the GPRs that matters and nothing else.
Alex Colvin
Consider an earlier CPU, 1959's IBM 1620.
--
mac the naïf
Martin Høyer Kristiansen
> A game that requires more than 4GB of RAM? It will be a few years before
> people will be able to afford that.
>
No, but a game that uses the extra registers of the x86-64 model and
squeezes 10% more performance out, - causing every (enthusiast) hardware
website to state that "AMD64 is clearly the choice for
DOOM/UNREAL/HALFLIFE XXX" causing the masses to buy x86-64 capable
machines in droves.
Cheers
Martin
Nick Maclaren
In article <bnj0bt$kp1$1...@sunnews.cern.ch>,
Dan...@cern.ch (Dan Pop) writes:
|>
|> >The fact that it only have 24-bit physical bus is completely
|> >irrelevant.
|>
|> Nope, it ain't. Plenty of *software* used the high 8 bits of the 68000
|> pointers for other purposes and failed to work on the later members of
|> the 68k family that had 32-bit addressing capabilities.
Virtual or physical addresses? The physical bus affects only the
latter, and they are used only by a very small part of the kernel
if you are using an operating system like Unix. Also, systems in
the past have sometimes checked that unused bits were zero and
faulted if they weren't. In that case, the physical bus width is
irrelevant.
|> Pentiums have been able to address more than 4GB of memory for quite
|> a while, yet no one claimed that they're more than 32-bit processors.
|> Just as in the case of 8-bit processors, all of them being able to
|> address more than 256 bytes of memory. So, whether you get it or not,
|> the size of an ISA is *not* determined by its addressing capabilities.
That's physical memory again - no single process can address more
than 4 GB.
|> It's the size of the GPRs that matters and nothing else.
Definitely not. There have been systems where a single process
could address 1 TB using 32-bit registers - in an earlier period,
there were systems where one could access 1 MB using 16-bit
registers. There are several ways to do that.
I would assert that such systems are not clearly N-bit for any N,
but they are definitely NOT just N-bit systems, where N is the
number of bits in a general purpose register.
Regards,
Nick Maclaren.
Dan Pop
>In article <bnj0bt$kp1$1...@sunnews.cern.ch>,
>Dan...@cern.ch (Dan Pop) writes:
>|>
>|> >The fact that it only have 24-bit physical bus is completely
>|> >irrelevant.
>|>
>|> Nope, it ain't. Plenty of *software* used the high 8 bits of the 68000
>|> pointers for other purposes and failed to work on the later members of
>|> the 68k family that had 32-bit addressing capabilities.
>
>Virtual or physical addresses?
The 68000 was unfit for virtual memory addressing. The first processor
of the family properly designed for virtual memory addressing was the
68010.
>|> Pentiums have been able to address more than 4GB of memory for quite
>|> a while, yet no one claimed that they're more than 32-bit processors.
>|> Just as in the case of 8-bit processors, all of them being able to
>|> address more than 256 bytes of memory. So, whether you get it or not,
>|> the size of an ISA is *not* determined by its addressing capabilities.
>
>That's physical memory again - no single process can address more
>than 4 GB.
Sez who? What is preventing the design of an OS whose processes can
address more than 4GB, through segmentation, just as MSDOS allowed its
processes to access more than 64 KB?
And, anyway, the OS is irrelevant in establishing the bitness of the CPU,
which is exclusively a property of the ISA.
>|> It's the size of the GPRs that matters and nothing else.
>
>Definitely not. There have been systems where a single process
>could address 1 TB using 32-bit registers - in an earlier period,
>there were systems where one could access 1 MB using 16-bit
>registers. There are several ways to do that.
How is this relevant to a discussion about the bitness of a certain ISA?
>I would assert that such systems are not clearly N-bit for any N,
>but they are definitely NOT just N-bit systems, where N is the
>number of bits in a general purpose register.
Feel free to invent your own terminology, but don't expect other people
to care about it. The bitness of an ISA has been determined by nothing
else than the size of the GPRs for as long as I can remember (the IBM 360
has been a 32-bit architecture, despite 24-bit addressing and 8-bit
physical implementations).
Ancra
If and when I get confused, I'll let you know.
I'd say you are confused about physical addressing abilities and
software adressing. 64-bit computing is all about using _linear_
64-bit pointer software. GPRs and physical adressing are just
particulars of hardware implementations. And as I've said often enough
now, actually quite arbitrary to 64-bit computing.
>>The fact that it only have 24-bit physical bus is completely
>>irrelevant.
>
>Nope, it ain't. Plenty of *software* used the high 8 bits of the 68000
>pointers for other purposes and failed to work on the later members of
>the 68k family that had 32-bit addressing capabilities.
(That is an out of context comment from you).
- It's just as irrelevant as mobos RAM limitations for the fundamental
properties of the cpu.
The cpu is DEFINED by its instruction set. It is LIMITED by its
hardware interface. And it is neither defined nor limited by its GPRs.
The point is that you can develop and run software on the 68000 and
any 68k, that can in linear mode utilize any memory, available sooner
or later from some hardware, theoretically up to 32-bits. And it can
do so because the cpu has an instruction set with 32-bit
adresseslength.
>>That's just a hardware interface. Just like the Athlon64's
>>40-bit adressbus.
>
>Which merely goes to show that the 64-bitness of the Athlon64 is not
>dictated by its addressing capabilities.
In our context - this thread, this group - "64-bitness" as a property,
refers to the property of *membership* in a class of cpus. The label
for this class says '64-bit'. Ultimately it doesn't matter how this
label was derived.
In particular, it doesn't matter how that other label '8'bit' was
derived 30 years ago, for that other completely different class of
cpus known as "8-bit" cpus.
What matters are the capabilities shared by the "64-bit" cpus.
And those capabilities are most definitely "dictated by its adressing
capabilities"!
>Pentiums have been able to address more than 4GB of memory for quite
>a while, yet no one claimed that they're more than 32-bit processors.
>Just as in the case of 8-bit processors, all of them being able to
>address more than 256 bytes of memory. So, whether you get it or not,
>the size of an ISA is *not* determined by its addressing capabilities.
I write "instruction set" again and again and again... - Don't you
know how physical adressing is managed in the post-8bit-cpu era?
>It's the size of the GPRs that matters and nothing else.
No, it's the capabilities that matters! You could possibly claim that
the 'label' -name is derived from the length of the GPR. (I would
argue against it).
Speaking of getting it - what is special with GPRs?
The Pentiums also have 64-bit registers. That doesn't make the Pentium
a 64-bit cpu. Not even according to you. But if it is the registers
that matters, why not?
And why is the length of the GPR (which is really arbitrary) chosen as
it is? - Eh?
They "matters" because software does its own adressarithmetic - for
instructions adressfields - in them! That is why it's good engineering
to choose their length from the ISA.
My argument is that the capabilities does not follow from the GPR.
The capabilities signifying 16-, 32-, 64-bit classes of cpus follows
from the instruction set adresslength.
The length of GPR _also_ follows from the instruction set
adresslength.
(But it doesn't _have_ to!)
To link to the subjectline of this group: 64-bit integer registers
won't make the Prescott a '64-bit' cpu.
It needs a completely new instruction set. It needs completely new
memorymanagement. Guess what that makes it? - Right, a completely new
processor. But does it need 64-bit GPRs, to realize the capabilities
that will make it a member of the '64-bit' class? - No! It actually
doesn't need that.
A cpu belonging to the 64-bit class could have 8-bit or 1024 bit GPRs.
(It would be terribly interesting to see the reasons for that, ;-D
but that's a different story)
So it's misleading to say that the property conferring '64-bitness' is
the GPR length. It's not. - It's the instruction set that is the
ticket to the 64-bit club.
It's _always_ the instruction set.
ancra
Ken Hagan
>
> In particular, it doesn't matter how that other label '8'bit' was
> derived 30 years ago, for that other completely different class of
> cpus known as "8-bit" cpus.
If you are arguing that the "8" in 8-bit does not correspond to the
"64" in 64-bit, then you are presumably of the belief that "bit-ness"
is not a term with any generally applicable meaning. This will come
as a surprise to many people, hence the current thread, I suppose.
Furthermore, since "64-bit" is now merely a label applied to a group
of processors that are currently of interest to you, I might ask two
questions.
Which processors are "64-bit"? (Just so as we know.)
Why not call them "red processors"? (This would avoid annoying
those who wish to infer some meaning from the term "bit-ness".)
If, on the other hand, the "8" and "64" are different values of the
same property, then we are under some obligation to come up with a
definition of "bit-ness" which agrees with historic usage. It seems
to me that Dan's definition manages that.
Dan Pop
>On 27 Oct 2003 11:42:53 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
>>You're confusing the with the width of the address registers with the
>>addressing capabilities of the processor.
>
>If and when I get confused, I'll let you know.
You can do that only *after* you realise you're confused. Until then...
Rupert Pigott
[SNIP]
> My argument is that the capabilities does not follow from the GPR.
Yes, quite correct for *YOUR* definition of 64 bitness.
However *YOUR* definition isn't the one shared by the
rest of the world.
Word to the wise :
It's a good idea to run a sanity check on your arguments
if you are finding that they conflict with 50+ years of
practice.
Cheers,
Rupert
Del Cecchi
"Rupert Pigott" <r...@dark-try-removing-this-boong.demon.co.uk> wrote in
message news:10673600...@saucer.planet.gong...
concensus definition is among real computer architects and computer
scientists, rather than making something up.
del
>
Rupert Pigott
news:bnm8ol$ut8$1...@news.rchland.ibm.com...
Bah, I never did that and I think that *might* fall into
the category of "sanity check". In this case I don't think
it's really necessary anyways, he's getting silver platter
treatment, but I bet he doesn't say thankyou. :P
Cheers,
Rupert
Ancra
<K.H...@thermoteknix.co.uk> wrote:
>Ancra wrote:
>>
>> In particular, it doesn't matter how that other label '8'bit' was
>> derived 30 years ago, for that other completely different class of
>> cpus known as "8-bit" cpus.
>
>If you are arguing that the "8" in 8-bit does not correspond to the
>"64" in 64-bit, then you are presumably of the belief that "bit-ness"
>is not a term with any generally applicable meaning. This will come
>as a surprise to many people, hence the current thread, I suppose.
- Hmm, good point. :-/
Also, as a strategy to get past labels and into the content, it
certainly seems to have failed miserably.
>Furthermore, since "64-bit" is now merely a label applied to a group
>of processors that are currently of interest to you, I might ask two
>questions.
>
> Which processors are "64-bit"? (Just so as we know.)
Cpus having an ISA with 64-bit flat virtual addressing. (and please,
no more on physical addressing or segmented mapping. Likewise I don't
think we need any wideranging discussions on canonical addressing
form).
I'm not aware of any "64-bit" cpu that does not have 64-bit GPRs. Nor
am I aware of any "32-bit" cpu that doesn't have 32-bit GPRs. I
believe this will answer your question, in the terms you are looking
for?
In this thread I've tried to deliver answers that assumes there is
some point to asking that question in the first place.
Rather than assuming "A big red truck" is a satisfactory answer to
"What is a fire engine?", however correct that may be.
I also have a tendency to question things like if it really has to be
red. ;-)
> Why not call them "red processors"? (This would avoid annoying
> those who wish to infer some meaning from the term "bit-ness".)
Well, that was just my point. "Inferring some meaning from the term".
"let's see here now... ok it's painted red (has 64-bit GPRs), allright
then, it's a "red processor"(64-bit cpu)!"
What does that mean? What does 64-bit GPRs mean?
If you do try to infer some meaning from that, what would you say it
would be?
And why "general purpose registers" in particular? What about other
registers? I would think at least some people, looking for answers to
the question what is '64-bitness', would feel "64-bit GPRs" leaves the
question curiously unanswered.
>If, on the other hand, the "8" and "64" are different values of the
>same property, then we are under some obligation to come up with a
>definition of "bit-ness" which agrees with historic usage. It seems
>to me that Dan's definition manages that.
Yes, I have to agree with that. Just as I would have to agree to red
for redpainted cpus :-)
Definition in the sense of how to - sofar - recocnize a 64-bit cpu.
I don't think that answers the question what 64-bit computing really
means, for the guy starting this thread. Though that's just my
assumption of course.
ancra
Ancra
<r...@dark-try-removing-this-boong.demon.co.uk> wrote:
>"Ancra" <somea...@some.domain> wrote in message
>news:3f9e74c7...@nntpserver.swip.net...
>
>[SNIP]
>
>> My argument is that the capabilities does not follow from the GPR.
>
>Yes, quite correct for *YOUR* definition of 64 bitness.
(Hi Rupert, now I understand you ;-))
"definition"? well, bits can refer to many things.
The argument one makes is to a large part caused by how one percieves
the opponents view. And much of my 'War & Peace novel' ;) elaborations
were driven by Dan involving physical addressing into the discussion.
I wanted to make clarifications.
But ok, let me try this:
The capabilities, in question, belong to the concept widely known and
referred to as "64-bit computing" in connection with any discussion on
servers, 64-bit Linux, Windows64 etc.
The question I sought to answer was this: What 64-bit property confers
these capabilities to a cpu?
>However *YOUR* definition isn't the one shared by the
>rest of the world.
-Hmm, "definition"? again.
Take any article you want, on 64-bit computing, and read on. Read on
beyond the introductionary section on 64-bit GPRs, to what the purpose
of 64-bit computing is about.
>Word to the wise :
>It's a good idea to run a sanity check on your arguments
>if you are finding that they conflict with 50+ years of
>practice.
Yes, but I'm such a convoluted person, that I feel practice sometimes
outlives its usefulness. Much have happened in those 50 years.
Register widths and path widths tend to vary a lot inside
architectures today. And are more governed by what you can make use
of, than by how often you have to change vacuum tubes. ;)
But let's do it your way:
OK, '64-bitness' refers to the length of those particular registers
known as GPR.
- Then what?
What does that mean? Why does anyone need 64-bitness?
Cheers,
ancra
Ancra
>... establishing the bitness of the CPU,
>which is exclusively a property of the ISA.
- ! !
Well,well.- Why didn't you say so before? We're in perfect agreement
then!
ancra
Rupert Pigott
I don't think it ever really does outlive it's usefullness
to be honest. There are always lessons to be learnt from
the past as well as present. I do confess to thinking the
same way as yourself and beating up on this very group in
the very same way. I think the last great crusade I launched
was in the thread entitled something like "Dead horse
flogging" from a long time ago.
> Register widths and path widths tend to vary a lot inside
> architectures today. And are more governed by what you can make use
> of, than by how often you have to change vacuum tubes. ;)
>
> But let's do it your way:
> OK, '64-bitness' refers to the length of those particular registers
> known as GPR.
>
> - Then what?
> What does that mean? Why does anyone need 64-bitness?
Personally I've found it to be rather handy. I've done
stuff like SIMD work with it, done 3D graphics in integer
because 64bits give me enough range to get by etc...
In the current world dominated by register-register style
machines 64bit GPRs is a big deal, especially as addresses
are often held in GPRs.
Cheers,
Rupert
Ancra
<r...@dark-try-removing-this-boong.demon.co.uk> wrote:
>"Ancra" <somea...@some.domain> wrote in message
>news:3fa06561...@nntpserver.swip.net...
>> On Tue, 28 Oct 2003 16:53:44 -0000, "Rupert Pigott"
>> <r...@dark-try-removing-this-boong.demon.co.uk> wrote:
>> >Word to the wise :
>> >It's a good idea to run a sanity check on your arguments
>> >if you are finding that they conflict with 50+ years of
>> >practice.
>>
>> Yes, but I'm such a convoluted person, that I feel practice sometimes
>> outlives its usefulness. Much have happened in those 50 years.
>
>I don't think it ever really does outlive it's usefullness
>to be honest. There are always lessons to be learnt from
>the past as well as present. I do confess to thinking the
>same way as yourself and beating up on this very group in
>the very same way. I think the last great crusade I launched
>was in the thread entitled something like "Dead horse
>flogging" from a long time ago.
Well I've folded and changed my mind. It means Dan is right about his
preliminary statement "It's not that easy" too. :-)
But it's alright. I now think that is the way it will have to be. Any
real or percieved difficulties from tying cpu bitness to gp registers
have to be dealt with when encountered, rather than preempted. And
wider explanations of meaning of "bitness" will be separate stories.
But I do still feel that gpr-length, as criteria for bitness, has
outlived most of its usefulness, even if I now agree with it.
>> What does that mean? Why does anyone need 64-bitness?
>
>Personally I've found it to be rather handy. I've done
>stuff like SIMD work with it, done 3D graphics in integer
>because 64bits give me enough range to get by etc...
>In the current world dominated by register-register style
>machines 64bit GPRs is a big deal, especially as addresses
>are often held in GPRs.
I agree of course. When I work, I run fairly close to the 2GB
boundary, 1.2 - 1.8GB app space (Windows PC). I need x86-64 soon.
In the PC world (I'm involved through crossposting from
achw.pc-homebuilt) bitness very much concerns addressing.
Cheers
ancra
Ancra
wrote:
>Ancra <somea...@some.domain> wrote:
>As for memory bandwidth, it makes a very big difference in heavily
>multitasked workloads, and when doing big builds with gcc or other
>programming tools. Amounts of memory, at least up to a point, and disk
>bandwidth make even bigger differences, but it's relatively easy to make
>both of those "all things being equal." For simulations, memory bandwidth is
>less important, but it does seem to make a noticeable difference. SSE2 makes
>no noticeable difference at all.
(btw, delay is caused by me not really lurking comp.arch)
Well, SSE2 makes no difference as long as it isn't used or cannot be
used. If it is used, as in virtually all benchmarks, it makes a big
difference. That was sort of one of my points. If you're not using
SSE2, published benchmarks are grossly misleading in respect of
performance. Vector processing is the future of the PC too, but if
you're not attentive, benchmarks may give you a very distorted picture
of the kind of relative (AMD Intel) performance you can expect.
Depending upon your software of course.
>> My take is that it isn't. It's easy to get brainwashed by published
>> benchmarks, which for some reason almost exclusively tests SSE2 mpeg
>> performance.
>
>Depends on your workloads. Toms Hardware is one of the better sites for
>that, and they tend to have a mix of synthetic workloads and gaming
>benchmarks.
If you're saying the 800FSB has meant a lot for the P4 vs P4, I'm
entirely with you. ...And in absolute terms as well of course.
Toms Hardware puts _really_heavy_ emphasis on SSE2 optimized
benchmarks.
Another point to note is that a lot of synthetic 'creation content'
and 'cpu performance' benchmarks actually weighs SSE2 mpeg/jpeg coding
very heavily too, so it's sort of just the very same benchmark as all
the media coding benchmarks, yet another round.
As for the games benchmarks. One thing that concerns me, is that
almost all are of the variety that just sends image renders down the
3D graphics channel. That doesn't in any way measure the impact of AI
and pathfinding. I don't know it it will be much impact, but these are
the sort of things the P4 is at disadvantage.
>> (The Athlon is so much faster than the P4 on most things I run, that I
>> think such differences in bandwidth must be irrelevant.
>
>What sort of stuff are you running?
Hmm, 'Topologic' is how I would describe it.
Large memory requirements. Actually almost using the entire 2GB space.
Computing times are in the 'hours' cathegory.
Otherwise and private, as I said, no SSE2 stuff.
I'm a fairly recent Athlon convert. Basically because all the P4s
prooved to be disappointments. The Athlon hacks it by a different
magnitude. If the libs were ported to SSE2, and if I didn't really
need x86-64 instead, I might have tried another P4. As it is, I have
no confidence in that the 800FSB have worked miracles.
> And what OS?
WindowsXPpro.
ancra
Terje Mathisen
>>scientists, rather than making something up.
>
> Bah, I never did that and I think that *might* fall into
> the category of "sanity check". In this case I don't think
> it's really necessary anyways, he's getting silver platter
> treatment, but I bet he doesn't say thankyou. :P
I don't really think you need to be a computer architect to come up with
a reasonable definition:
The bitness of a system is (mostly) determined by the largest flat
address range you can easily handle.
(This is quite obvious to asm hackers, but much less so for others, as
long as the compiler can hide the ugly stuff.)
If Intel had modified the Pentium so as to allow more than 4 GB in a
single process, and also let the 64-bit MMX registers be used for memory
addressing, then it would have been a 64-bit system.
(A very _ugly_ 64-bit system though.)
Doing it halfway, by just extending the process address space, but
requiring segment+offset addressing to reach the rest of the physical
address range would not have been enough imho.
OTOH, doing the latter (most easily by requiring ranges of more than 4GB
to be mapped by big pages only) would have made it even harder to
persuade anyone to leave x86 for Itanium.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
John Dallman
(John Dallman) wrote:
> However, AFAIK, the story is based on interpretation of die photographs,
> and while such a picture - with a scale - can tell you a bit about
> pinouts and cache sizes, I strongly suspect that this story is based on
> over-interpretation.
A further thought: The die photos are provided by Intel, yes? If they were
trying to hide something ... well, who could tell if they released a photo
that wasn't of the real die?
---
John Dallman j...@cix.co.uk
"Any sufficiently advanced technology is indistinguishable from a
well-rigged demo"
John Dallman
dsie...@excisethis.khamsin.net (Douglas Siebert) wrote:
> <wild speculation>
> My hunch is that when Intel found out MS was going to support AMD64 they
> told them they were putting a hidden 64 bit capability in x86 "just in
> case" and wanted them to support it as well. MS said no, but agreed to
> delay AMD64 support until Intel could get themselves ready for it "just
> in case".
Pretty wild. MS don't tend to just do what Intel ask, you know. Intel
indulge in L*n*x, for one thing, and I don't think there are many greater
sins in MS eyes.
Dan Pop
>I don't really think you need to be a computer architect to come up with
>a reasonable definition:
>
>The bitness of a system is (mostly) determined by the largest flat
>address range you can easily handle.
There are many flaws in this definition:
1. It doesn't address the Harvard architectures with different sizes for
the data and the code address spaces.
2. It makes no difference between systems with byte addressing and systems
with word addressing.
3. If we put it to work, we get the following results for several well
known architectures:
Z80 - 16-bit
PDP-8 - 7-bit
PDP-10 - 18-bit
IBM 360 - 24-bit
Cray-1 - 48-bit
>(This is quite obvious to asm hackers, but much less so for others, as
>long as the compiler can hide the ugly stuff.)
It is quite obvious to asm hackers whose experience is limited to
architectures where all the bits of the GPRs are used for addressing
purposes.
By your definition, an architecture with 64-bit GPRs supporting 48-bit
addressing is a 48-bit architecture, while the computing indistry
would consider it a 64-bit architecture, without any if's and but's.
The traditional Cray vector processors fall into this category.
Terje Mathisen
> In <bo6191$c6o$2...@osl016lin.hda.hydro.com> Terje Mathisen <terje.m...@hda.hydro.com> writes:
>>The bitness of a system is (mostly) determined by the largest flat
>>address range you can easily handle.
> By your definition, an architecture with 64-bit GPRs supporting 48-bit
> addressing is a 48-bit architecture, while the computing indistry
> would consider it a 64-bit architecture, without any if's and but's.
Huh?
How can you read that into what I wrote?
If I do all address arithmetic on 64-bit registers, then it is indeed a
64-bit system, even if parts of that address range doesn't really point
to real (or even virtual) memory.
> The traditional Cray vector processors fall into this category.
In the paragraphs you snipped, I mentioned how being allowed to use the
64-bit MMX registers to address the 36-bit physical address range of
some x86 cpus would have made them (ugly) 64-bit cpus.
Is this very different from your Cray?
Dan Pop
>Dan Pop wrote:
>> In <bo6191$c6o$2...@osl016lin.hda.hydro.com> Terje Mathisen <terje.m...@hda.hydro.com> writes:
>>>The bitness of a system is (mostly) determined by the largest flat
>>>address range you can easily handle.
>
>> By your definition, an architecture with 64-bit GPRs supporting 48-bit
>> addressing is a 48-bit architecture, while the computing indistry
>> would consider it a 64-bit architecture, without any if's and but's.
>
>Huh?
>
>How can you read that into what I wrote?
>
>If I do all address arithmetic on 64-bit registers, then it is indeed a
>64-bit system, even if parts of that address range doesn't really point
>to real (or even virtual) memory.
If you do all address arithmetic on 64-bit registers, "the largest flat
address range you can easily handle" on such a system is still 48-bit,
period. Therefore, by your *own* definition, it is a 48-bit architecture.
>> The traditional Cray vector processors fall into this category.
>
>In the paragraphs you snipped, I mentioned how being allowed to use the
>64-bit MMX registers to address the 36-bit physical address range of
>some x86 cpus would have made them (ugly) 64-bit cpus.
Which doesn't make any sense, of course. "The largest flat address
range you can easily handle" in this scenario is still 36-bit, period.
You were not consistent with your own definition. According to your
definition, that would make it a 36-bit processor.
You're confusing the integer arithmetic capabilities of the CPU and its
addressing capabilities. It makes no sense to talk about 64-bit
addressing, unless the architecture defines a biunivocal relationship
between the address range and the range of values representable in a
64-bit CPU register.
Terje Mathisen
> In <bo88he$ni8$1...@osl016lin.hda.hydro.com> Terje Mathisen <terje.m...@hda.hydro.com> writes:
>
>>Dan Pop wrote:
>>>The traditional Cray vector processors fall into this category.
>>
>>In the paragraphs you snipped, I mentioned how being allowed to use the
>>64-bit MMX registers to address the 36-bit physical address range of
>>some x86 cpus would have made them (ugly) 64-bit cpus.
>
> Which doesn't make any sense, of course. "The largest flat address
> range you can easily handle" in this scenario is still 36-bit, period.
By "handle" I meant which size would a pointer be, and how would I do
address arithmetic on it. I don't care how many of the bits are actually
brought out on the memory bus, only that the total is large enough for
the task I'm doing.
> You were not consistent with your own definition. According to your
> definition, that would make it a 36-bit processor.
>
> You're confusing the integer arithmetic capabilities of the CPU and its
> addressing capabilities. It makes no sense to talk about 64-bit
> addressing, unless the architecture defines a biunivocal relationship
> between the address range and the range of values representable in a
> 64-bit CPU register.
I don't think I'm confused, but I seem to be confusing, at least to you.
Sorry about that.
Jean-Marc Bourguet
> Dan Pop wrote:
>
> > In <bo88he$ni8$1...@osl016lin.hda.hydro.com> Terje Mathisen <terje.m...@hda.hydro.com> writes:
> >
> >>Dan Pop wrote:
> >>>The traditional Cray vector processors fall into this category.
> >>
> >> In the paragraphs you snipped, I mentioned how being allowed to use the
> >> 64-bit MMX registers to address the 36-bit physical address range of
> >> some x86 cpus would have made them (ugly) 64-bit cpus.
> > Which doesn't make any sense, of course. "The largest flat address
> > range you can easily handle" in this scenario is still 36-bit, period.
>
> By "handle" I meant which size would a pointer be, and how would I do
> address arithmetic on it. I don't care how many of the bits are actually
> brought out on the memory bus, only that the total is large enough for the
> task I'm doing.
8 bits processors -- like Z80 -- handle easely address arithmetic on
16 bits adresses.
A+
--
Jean-Marc
Dan Pop
>Dan Pop wrote:
>
>> In <bo88he$ni8$1...@osl016lin.hda.hydro.com> Terje Mathisen <terje.m...@hda.hydro.com> writes:
>>
>>>Dan Pop wrote:
>>>>The traditional Cray vector processors fall into this category.
>>>
>>>In the paragraphs you snipped, I mentioned how being allowed to use the
>>>64-bit MMX registers to address the 36-bit physical address range of
>>>some x86 cpus would have made them (ugly) 64-bit cpus.
>>
>> Which doesn't make any sense, of course. "The largest flat address
>> range you can easily handle" in this scenario is still 36-bit, period.
>
>By "handle" I meant which size would a pointer be, and how would I do
>address arithmetic on it. I don't care how many of the bits are actually
>brought out on the memory bus, only that the total is large enough for
>the task I'm doing.
But that total is still not (necessarily) determined by the size of the
registers used for computing the address. See my examples.
>> You were not consistent with your own definition. According to your
>> definition, that would make it a 36-bit processor.
>>
>> You're confusing the integer arithmetic capabilities of the CPU and its
>> addressing capabilities. It makes no sense to talk about 64-bit
>> addressing, unless the architecture defines a biunivocal relationship
>> between the address range and the range of values representable in a
>> 64-bit CPU register.
>
>I don't think I'm confused, but I seem to be confusing, at least to you.
Regardless of what you think, you are confusing arithmetic capabilities
and addressing capabilities. You have provided ample proof in this
thread. Your definition is broken for 8-bit CPUs and for many 64-bit
CPUs, as well as for a fair number of historical architectures.
Stephan Schulz
>In <bnlki3$j1k$1...@pegasus.csx.cam.ac.uk> nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>
>Sez who? What is preventing the design of an OS whose processes can
>address more than 4GB, through segmentation, just as MSDOS allowed its
>processes to access more than 64 KB?
Not "what", but "who"! I and my baseball bat both volunteer, and I
strongly believe there are thousands more who are willing to resort to
any type of action to spare us a return to those dark ages!
;-)
Bye,
Stephan
--
-------------------------- It can be done! ---------------------------------
Please email me as sch...@informatik.tu-muenchen.de (Stephan Schulz)
----------------------------------------------------------------------------
Robert Wessel
> Sez who? What is preventing the design of an OS whose processes can
> address more than 4GB, through segmentation, just as MSDOS allowed its
> processes to access more than 64 KB?
Since all segments descriptors are mapped into a single 4GB linear
address for each process on x86, you can't extend addressing past 4GB
using segmentation. The architectural change required to allow that
would be minor, however, but it's not present in any x86 currently
available.
An OS could play games by dynamically remapping the page and segment
tables at each segment register load, but it's ugly, and hasn't been
implemented by anyone that I know of. See the following for a
somewhat longer discussion of the technique:
Ancra
wrote:
>I heard at one point a long while ago that AMD was considering a generation
>of 32-bit Athlons on 754. Don't know if that's gone anywhere.
Well, AMDs roadmap recently started to feature a "Paris" late '04 as
next AthlonXP generation. 0.13 just as the Barton, no other
information, so something else must be new.
Rumours suggest this Paris is composed out of pieces of the K8 design,
rather than K7. It will get a smaller cache, 256KB, K8s larger
(deeper) executionunit for higher clocks and SSE2 support, and finally
an onboard memorycontroler and 754pin package.
This is just so like speculation that I wonder whether it just is, or
if there is some real basis? I also think the speculations appeared
before 'Paris', so they might just have adopted Paris as a target?
What I don't understand, the 754 is single channel only mobos, right?
(or am I really misunderstanding things?)
What's the point with a 800-1600MHz memorybus controler?
And why should this 754pin 32-bit cpu be cheap enough to manufacture
that it makes sense instead of the 754pin 64-bit cpu? Double why,
since AMD should have a vested interest in moving customers and apps
to 64-bit. Triple why, since 64-SSE2 is AMDs real opportunity to beat
Intel at their benchmark con. SSE2 won't do, judging by Athlon64
32-bit benchmarks.
ancra
Zak
> What I don't understand, the 754 is single channel only mobos, right?
> (or am I really misunderstanding things?)
> What's the point with a 800-1600MHz memorybus controler?
That is the AGP connection so to speak. The memory attachment is not
through the 800 MHz bus, but through an on-chip interface.
> And why should this 754pin 32-bit cpu be cheap enough to manufacture
> that it makes sense instead of the 754pin 64-bit cpu? Double why,
> since AMD should have a vested interest in moving customers and apps
> to 64-bit.
I guess this will only be launched if 64 bit has become a no brainer. Or
just as Celeron competition.
At least it gives AMD some more ways to differentiate the product line
for single CPU:
- clock speed
- memory bus width
- 32 / 64 bit ISA
- cache size
I'd think that cache size would be the real cost saver, and that a small
cache 754 64 bit chip would be most in line with what AMD wants. But if
there are 32 bit benchmarks to be met, a 32 bit only version may be the
way to prevent cannibalization of the 64 bit line.
Thomas
Wes Felter
> And why should this 754pin 32-bit cpu be cheap enough to manufacture
> that it makes sense instead of the 754pin 64-bit cpu? Double why,
> since AMD should have a vested interest in moving customers and apps
> to 64-bit.
The conspiracy theory is that a certain PC maker has a deal with Intel
that prevents them from using AMD64 processors. Thus AMD creates a
crippled 32-bit-only version of ClawHammer, calls it a Socket 754 Athlon
XP, and everyone is happy. This way you can use newer Socket 754
motherboards. But I never believe such theories.
--
Wes Felter - wes...@felter.org - http://felter.org/wesley/
Douglas Siebert
>On Thu, 23 Oct 2003 22:16:55 -0700, arch...@sfchat.org (Nate Edel)
>wrote:
>>I heard at one point a long while ago that AMD was considering a generation
>>of 32-bit Athlons on 754. Don't know if that's gone anywhere.
>Well, AMDs roadmap recently started to feature a "Paris" late '04 as
>next AthlonXP generation. 0.13 just as the Barton, no other
>information, so something else must be new.
AMD said at the beginning of the week that they planned to ship "tens of
millions" of 64 bit processors in 2004, according to their VP of AMD's
Microprocessor Business Unit. They also said they'd probably stop selling
32 bit CPUs by the end of 2005 (based on customer demand, etc.) See:
http://www.infoworld.com/article/03/11/18/HNamddays_1.html?s=feature
So I think the "32 bit Athlon on socket 754" thing was a mistake from
people who misinterpreted their plans and thought they'd try to keep the
64 bit CPUs as higher end only, but sell cut down K8 cores on socket 754
that were 32 bit only. Looks to me like they'll just keep selling the
socket 462 stuff for the 32 bit line as long as people want it for upgrade
purposes and very low cost systems in developing countries. i.e., the
same function that the Duron serves right now.
They plan to have even low end Celeron competitors in 64 bit form by the
end of 2004 according to their latest roadmaps. Yeah, we all know that
64 bits on a Celeron class system is pretty silly, but there's no point
for them deliberately hobble the core to be 32 bit only, especially since
it saves only a tiny amount (a couple sq mm) of chip area and would
require additional qualification, more work for developers, etc. Plus
there's always the marketing points they get from selling them as 64 bit
CPUs.
It'll be interesting to see which useless (for 2004 entry level systems)
marketing feature consumers will like the most next year, 3GHz clock rates
from Intel or 64 bits from AMD.
--
Douglas Siebert dsie...@excisethis.khamsin.net
"I feel sorry for people who don't drink. When they wake up in the morning,
that's as good as they're going to feel all day" -- Frank Sinatra
Tony Hill
wrote:
>On Thu, 23 Oct 2003 22:16:55 -0700, arch...@sfchat.org (Nate Edel)
>wrote:
>
>>I heard at one point a long while ago that AMD was considering a generation
>>of 32-bit Athlons on 754. Don't know if that's gone anywhere.
>
>Well, AMDs roadmap recently started to feature a "Paris" late '04 as
>next AthlonXP generation. 0.13 just as the Barton, no other
>information, so something else must be new.
My understanding is that "Paris" is to be made on the same 130nm SOI
fab process that the Opteron's are produced on. The "Barton" chips
are made on a 130nm bulk silicon process.
>Rumours suggest this Paris is composed out of pieces of the K8 design,
>rather than K7. It will get a smaller cache, 256KB, K8s larger
>(deeper) executionunit for higher clocks and SSE2 support, and finally
>an onboard memorycontroler and 754pin package.
>This is just so like speculation that I wonder whether it just is, or
>if there is some real basis? I also think the speculations appeared
>before 'Paris', so they might just have adopted Paris as a target?
There have been some rumors that Paris will be basically an Athlon64
with the 32-bit portion removed/disabled. I'm not sure that this
makes very much sense for AMD, removing the 64-bit capabilities would
cost a lot of development money for only a ~5% reduction in die size,
doesn't seem worth it. Disabling the 64-bit capabilities might have
some benefit from the marekting/market segmentation standpoint, but
given that AMD really wants to push their AMD64 instruction set as
much as possible, this seems like a poor idea as well.
Personally my guess is that "Paris" is nothing more than a 130nm SOI
version of the AthlonXP. No other changes except maybe higher clock
speeds.
>What I don't understand, the 754 is single channel only mobos, right?
>(or am I really misunderstanding things?)
Socket 754 chips are designed for a single, 64-bit wide memory channel
only. I haven't looked at the pinouts too closely, but I don't think
there are sufficient pins to increase the width of this memory
channel.
>What's the point with a 800-1600MHz memorybus controler?
Umm.. huh? What the heck are you talking about here? Are you
referring to Hypertransport, which runs at 800MHz DDR (1600MT/s)?
It's not a "memorybus controler", or even a memory bus controller for
that matter. It's an I/O port.
>And why should this 754pin 32-bit cpu be cheap enough to manufacture
>that it makes sense instead of the 754pin 64-bit cpu? Double why,
>since AMD should have a vested interest in moving customers and apps
>to 64-bit. Triple why, since 64-SSE2 is AMDs real opportunity to beat
>Intel at their benchmark con. SSE2 won't do, judging by Athlon64
>32-bit benchmarks.
I don't understand the move either, which is why I'm guessing it won't
happen. AMD already has some plans for lower-cost Athlon64 designs
(perhaps a "Duron64" or some such thing). Their plans for "Paris"
seem to be something else altogether. In any case, at the moment
there is a lot of rumors flying around purporting to be the truth.
Until we get any sort of official comment from AMD, I'd take any of
this info with a nice big grain of salt.
As for Intel's "benchmark con" with SSE2, there isn't much of a con.
Intel and AMD's SSE2 units are VERY similar when run in 32-bit mode
(in 64-bit mode, AMD doubles the number of SSE/SSE2 registers). The
only real difference is that AMD operates their SSE2 unit at 2.0GHz
(or thereabouts) while the Intel SSE2 units operate at up to 3.2GHz.
As such, it's not a huge surprise that the Intel version tends to be a
bit faster. Of course, things like the integrated memory controller
and larger cache help AMD out here, but not enough to even out the
clock difference. This is quite different from the standard ALUs and
FPUs, where AMD and Intel have quite different designs with the AMD
units doing more per clock cycle than the Intel ones.
-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Tony Hill
wrote:
>The conspiracy theory is that a certain PC maker has a deal with Intel
>that prevents them from using AMD64 processors. Thus AMD creates a
>crippled 32-bit-only version of ClawHammer, calls it a Socket 754 Athlon
>XP, and everyone is happy. This way you can use newer Socket 754
>motherboards. But I never believe such theories.
The conspiracy theory held that it was HP that wouldn't seem AMD64
processors.
HP just this week announced that they WILL sell AMD64 processors, so
this conspiracy theory can pretty much be thrown out the window.
Felger Carbon
news:8d0c8e0b78fbaedd...@news.1usenet.com...
>
> As for Intel's "benchmark con" with SSE2, there isn't much of a con.
> Intel and AMD's SSE2 units are VERY similar when run in 32-bit mode
> (in 64-bit mode, AMD doubles the number of SSE/SSE2 registers). The
> only real difference is that AMD operates their SSE2 unit at 2.0GHz
> (or thereabouts) while the Intel SSE2 units operate at up to 3.2GHz.
> As such, it's not a huge surprise that the Intel version tends to be a
> bit faster.
As George McD has pointed out (IIRC), things come to a screeching halt on
Intel SSE2 when FPU underflows occur, which is what happens too often in
digital audio applications. In that case, AMD SSE2 is not only better, it's
also faster!
All a part of the tradeoffs Intel made in the P4 microarchitecture to get good
(hell, excellent!) video streaming performance. You pays yer gelt and you
takes yer choice.
glen herrmannsfeldt
(snip)
> AMD said at the beginning of the week that they planned to ship "tens of
> millions" of 64 bit processors in 2004, according to their VP of AMD's
> Microprocessor Business Unit. They also said they'd probably stop selling
> 32 bit CPUs by the end of 2005 (based on customer demand, etc.) See:
(snip)
> They plan to have even low end Celeron competitors in 64 bit form by the
> end of 2004 according to their latest roadmaps. Yeah, we all know that
> 64 bits on a Celeron class system is pretty silly, but there's no point
> for them deliberately hobble the core to be 32 bit only, especially since
> it saves only a tiny amount (a couple sq mm) of chip area and would
> require additional qualification, more work for developers, etc. Plus
> there's always the marketing points they get from selling them as 64 bit
> CPUs.
It was discussed in some newsgroup, maybe this one, that only a very
small fraction of code needs 64 bits. You only need 64 bit addressing
for really large programs (there is always PAE if you need it).
64 bit arithmetic isn't hard to do in two 32 bit operations on a 32 bit
processor. Maybe divide is a little harder, but it doesn't occur all
that often in most programs.
-- glen
Linus Torvalds
>
> It was discussed in some newsgroup, maybe this one, that only a very
> small fraction of code needs 64 bits. You only need 64 bit addressing
> for really large programs (there is always PAE if you need it).
That really doesn't matter.
It's not a question of "most people don't need it".
It's a question of having advantages of a mass market. If AMD continues to
produce 32-bit versions of the Athlon chip (regardless of whether they base
it on the old K7 architecture or just a cut-down K8) they automatically
kill off interest in their 64-bit architecture.
This is the same problem Intel has with Itanium: it's not going to be a
successful architecture as long as the 32-bit chips compete with it. You'd
have to be *CRAZY* to buy an Itanium box when you can buy Xeon's that
perform better for 99% of all workloads for a third of the price.
(Yeah, some people care about that 1% where 64-bit matters, but it's not
enough to maintain an interesting market).
To maintain an interesting market, AMD needs to stop producing the 32-bit
versions, and needs to be able to say that every x86 CPU they ship (with
the exception of specialized markets like embedded) is 64-bit capable.
That's the only way they can get enough of the chips on the market that
anybody will bother buying them.
Remember: the reason the Alpha died was not technology. The reason the alpha
died is that you can't afford to push an architecture that doesn't have a
wide appeal.
This is why AMD64 and the Power architectures are interesting, and why
Itanium eventually _will_ die unless Intel starts seriously changing their
approach to it. AMD64 and Power - in Opteron and the 970 respectively -
both have 64-bit architectures with a very real wide appeal, which helps
widen the market for them without fragmenting it.
In contrast, Intel is _consciously_ trying to fragment the market, which may
be in their own business interests ("gotta keep those high ASP's for those
high-end CPU's..") but it's against the interest of the consumers. And the
thing is, when you start doing things that are against the interest of your
marketplace, you are well on your way to disaster.
So if you see AMD actively pushing their 32-bit offerings next year, you'll
know that the Athlon64 is in deep trouble.
Linus
Nick Maclaren
Linus Torvalds <torv...@osdl.org> wrote:
>glen herrmannsfeldt wrote:
>>
>> It was discussed in some newsgroup, maybe this one, that only a very
>> small fraction of code needs 64 bits. You only need 64 bit addressing
>> for really large programs (there is always PAE if you need it).
>
>That really doesn't matter.
>
>It's not a question of "most people don't need it".
>
>It's a question of having advantages of a mass market. If AMD continues to
>produce 32-bit versions of the Athlon chip (regardless of whether they base
>it on the old K7 architecture or just a cut-down K8) they automatically
>kill off interest in their 64-bit architecture.
"Kill off"? Oh, come, now! "Cut down".
Regards,
Nick Maclaren.
Robert Myers
wrote:
>On Fri, 24 Oct 2003 11:21:56 -0700, arch...@sfchat.org (Nate Edel)
>wrote:
>
<snip>
>>What sort of stuff are you running?
>
>Hmm, 'Topologic' is how I would describe it.
>Large memory requirements. Actually almost using the entire 2GB space.
>Computing times are in the 'hours' cathegory.
>Otherwise and private, as I said, no SSE2 stuff.
>I'm a fairly recent Athlon convert. Basically because all the P4s
>prooved to be disappointments. The Athlon hacks it by a different
>magnitude. If the libs were ported to SSE2, and if I didn't really
>need x86-64 instead, I might have tried another P4. As it is, I have
>no confidence in that the 800FSB have worked miracles.
>
Are you chasing pointers?
RM
Linus Torvalds
No, I mean "kill off".
Yes, it will obviously "cut down" too. But the thing is, if you continue to
cut down, you'll eventually have nothing left.
Introducing new architectural features is an uphill battle every time. It's
hard if you're a market leader, and it's doubly worse if you're already the
underdog in the market. See what happened to 3dnow etc.
AMD already has Intel trying to undercut their market from them (P4EE etc).
They sure as hell don't need to do it themselves.
The K8 has a huge leg up thanks to backwards compatibility. That makes it
possible to sell it in the first place. But if you actually expect the new
architecture to matter and make a difference, it has to become common
enough that people will care.
And the only way it becomes common is by always including support for
64-bit. If you have a low-end 32-bit version, most people will just look at
the price difference and say "the 64-bit stuff doesn't buy me anything
today, so I'll just wait until there are applications taking advantage of
it".
And they'll wait literally forever, because it's a circular argument...
So AMD needs to drop the 32-bit versions to break the circle.
Linus
Robert Myers
wrote:
<snip>
>
>This is why AMD64 and the Power architectures are interesting, and why
>Itanium eventually _will_ die unless Intel starts seriously changing their
>approach to it.
Anybody who is paying close attention, and I'm assuming that ISV's
thinking about investing money in developing software for Itanium
would at least be trying to pay close attention, knows that Intel *is*
going to change its approach to Itanium, and that may be part of the
problem.
The change that is inevitable is that Intel has to do something about
the inability of single-thread, statically-scheduled code to take
account of actual conditions at run-time. I personally think that
Intel is headed toward helper threads using SMT. Out of order is
clearly under study, but I don't think Intel can make that happen fast
enough.
When either one of those changes takes place, Itanium will be a
dramatically different processor to write software for, and, until one
of those things happens, Itanium will remain confined to the very
highest-end niche that Intel was aiming at to begin with.
Either one of those changes would improve the performance of
Itanium--how much for highly-tuned code running under controlled
conditions, I would hesitate to speculate, but dramatically so for
less intensively-optimized code running in an unpredictable
environment.
Among other things, it would make Itanium competitive in the
workstation market, where right now it is mostly a research toy. It
should also make it much easier to port software to Itanium, which
will be a much more forgiving processor.
RM
glen herrmannsfeldt
> glen herrmannsfeldt wrote:
>
>>It was discussed in some newsgroup, maybe this one, that only a very
>>small fraction of code needs 64 bits. You only need 64 bit addressing
>>for really large programs (there is always PAE if you need it).
>
>
> That really doesn't matter.
>
> It's not a question of "most people don't need it".
>
> It's a question of having advantages of a mass market. If AMD continues to
> produce 32-bit versions of the Athlon chip (regardless of whether they base
> it on the old K7 architecture or just a cut-down K8) they automatically
> kill off interest in their 64-bit architecture.
Yes, and convincing people that they need something that they really
don't. Those people reading mail, or word processing, but like the
idea of having a 64 bit processor so they can read mail faster, or
process words faster.
What would we do without marketing departments.
-- glen
Andy Freeman
> Secondly, you're off target a bit:
> Win32 only gives an app 2GB process space, not 4.
2GByte is the max user space in the default configuration for Win32.
However, there's a boot-time option for later versions of Win32 OSes
that let specially configured applications have 3GByte of user space.
These Win32 OSes aren't as happy running with this configuration, but
it is the right choice in some cases.
I predict that more and bigger registers, not address space, is the
first thing that will move high end games to x86-64.
Tony Hill
<g...@ugcs.caltech.edu> wrote:
>> It's a question of having advantages of a mass market. If AMD continues to
>> produce 32-bit versions of the Athlon chip (regardless of whether they base
>> it on the old K7 architecture or just a cut-down K8) they automatically
>> kill off interest in their 64-bit architecture.
>
>Yes, and convincing people that they need something that they really
>don't. Those people reading mail, or word processing, but like the
>idea of having a 64 bit processor so they can read mail faster, or
>process words faster.
One of the big benefits of AMD's 64-bit design though is that it's
basically "free". Even on current 130nm manufacturing process the
extra die space to accommodate the 64-bit architecture is only ~5%.
Once we move to 90nm and beyond, that difference quickly becomes
negligible.
Sure, we still have the question of "Do users need a fast but
expensive processor when a slow but cheap processor will do the task",
but AMD will soon (end of next year once 90nm production ramps) be
able to make cheap 64-bit chips. Actually, they could probably make a
reasonably priced "Duron64" (or some such thing) in the near future on
a 130nm process. Just get rid of two of the three hypertransport
links on the current Athlon64/Opteron die, remove the top 72-bits of
the memory controller and reduce the cache to 256K. Die size for such
a chip would probably be around 130mm^2, not much more than the
current ~105mm^2 of the AthlonXP and less than current P4s.
In short, the question of whether or not someone "needs" 64-bit
quickly becomes moot.
Linus Torvalds
>
> Yes, and convincing people that they need something that they really
> don't. Those people reading mail, or word processing, but like the
> idea of having a 64 bit processor so they can read mail faster, or
> process words faster.
>
> What would we do without marketing departments.
Hey, far be it from me to speak up for marketing, but the fact is, 64-bit
architectures _do_ help even people who only read mail and do word
processing.
Sure, the mail app or word processor may not need it, but the 64-bit stuff
does help other parts of the system, notably the infrastructure that helps
the mail reader/word processor do its job.
32-bit is getting quite cramped for operating systems when even normal
desktop (and laptop) machines have a gigabyte of RAM. PAE made us jump
through hoops, and it's getting worse.
512MB and 1GB machines are _normal_ today. And the virtual address space is
supposed to be noticeably *larger* than physical memory to be useful for a
number of things.
You can believe Intel marketing all you want ("the desktop doesn't need more
than 4GB of RAM in the next few years"), but that's a *lie*. Exactly
because the 32-bit virtual limit is _not_ at 4GB, but hits us much before
that (ie it hits at about 1GB of RAM - that's when the OS starts having
trouble mapping all of physical memory _and_ user space at the same time
without starting to have problems.
It's "highmem.sys" time all over again. And take it from me: that isn't five
years down the road - it's been that way for a couple of years already.
Every time I see a report on the 'net quoting some Intel person saying they
don't need to worry about it for a few years, I just cringe. They are
either incompetent or actively dishonest.
(Don't get me wrong, btw. I actually _like_ Intel. The x86 is my favourite
architecture simply because it beats everybody else hands down when it
comes to choice and bang-for-buck. I just can't stand the public
posturing).
Anyway: even if the mail reader doesn't need any more than 32-bit VM, other
parts of the system definitely would be improved by it.
And AMD64 actually gets this right - you can continue to happily use your
32-bit apps that don't need the bigger address space, without any
performance downsides. While the (much smaller) part of the installation
that actually can take advantage of 64-bit addressing can do so.
Linus
Douglas Siebert
>Linus Torvalds wrote:
You can believe its marketing if you want, but there are already people
running into limits (which are more like 2GB than 4GB for the way most
OSes work) And with RAM cheap enough that it isn't unusual for normal
people to buy a system with 1GB these days, we need only wait until next
year for the 1Gbit DRAMs to become the mass market and we've hit 2GB
(since the mass market CPUs are all dual channel you sell them with two
DIMMs) You want to build any useful expansion capability, and you better
have a 64 bit CPU.
The thing that'll make AMD64 successful in the mass market but will
keep Itanium always on the high end, looking at the mass market longingly
but never coming in is that in three years when pretty much every PC sold
will have 2GB or more and need a 64 bit OS for efficient operation AMD
will have an installed base of 100 million+. Itanium will have maybe a
million, with 95% of those in computational clusters and datacenters.
Intel knows this, so they'll do 64 bit x86, and their silly claims that
64 bits isn't needed for another five years will suddenly be forgotten,
just like how they conveniently ignore clock rate where Pentium M is
concerned. They just delay it for now, probably partly because Microsoft's
pressure forced to them to be compatible (in some form) with AMD64, and
partly because of internal politics with the pro-Itanium crowd holding
onto their vain hope Itanium can replace x86.
Stephen Sprunk
news:9XCvb.206337$275.773851@attbi_s53...
> It was discussed in some newsgroup, maybe this one, that only a very
> small fraction of code needs 64 bits. You only need 64 bit addressing
> for really large programs (there is always PAE if you need it).
It's arguable that a small fraction of code benefits from 64-bit GPRs, but
pretty much all code will benefit from having double the number of GPRs
(even if used as 32-bit).
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Felger Carbon
>
> Yes, and convincing people that they need something that they really
> don't. Those people reading mail, or word processing, but like the
> idea of having a 64 bit processor so they can read mail faster, or
> process words faster.
>
> What would we do without marketing departments.
Remember the muscle cars? People finally figured out they didn't need
600HP to drive to the store for a loaf of bread and a quart of milk,
so the muscle cars went away. That's when cars got really cheap.
Hey, wait a minute... ;-)
Michael S
> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
> news:9XCvb.206337$275.773851@attbi_s53...
> > It was discussed in some newsgroup, maybe this one, that only a very
> > small fraction of code needs 64 bits. You only need 64 bit addressing
> > for really large programs (there is always PAE if you need it).
>
> It's arguable that a small fraction of code benefits from 64-bit GPRs, but
> pretty much all code will benefit from having double the number of GPRs
> (even if used as 32-bit).
>
> S
Not for my definition of "benifit", which is "improve performonce by 5% or more".
Terje Mathisen
> glen herrmannsfeldt wrote:
>
>>Yes, and convincing people that they need something that they really
>>don't. Those people reading mail, or word processing, but like the
>>idea of having a 64 bit processor so they can read mail faster, or
>>process words faster.
>>
>>What would we do without marketing departments.
>
>
> Hey, far be it from me to speak up for marketing, but the fact is, 64-bit
> architectures _do_ help even people who only read mail and do word
> processing.
>
> Sure, the mail app or word processor may not need it, but the 64-bit stuff
> does help other parts of the system, notably the infrastructure that helps
> the mail reader/word processor do its job.
>
> 32-bit is getting quite cramped for operating systems when even normal
> desktop (and laptop) machines have a gigabyte of RAM. PAE made us jump
> through hoops, and it's getting worse.
>
> 512MB and 1GB machines are _normal_ today. And the virtual address space is
> supposed to be noticeably *larger* than physical memory to be useful for a
> number of things.
OTOH, with the increasing gap between memory and disk in
latency/bandwidth, the maximum sustainable overcommitment factor have
been dropping like a stone, from (say) 2 to 4 X around the time virtual
memory was invented, to 0.95 to 1.5 x these days, at least with a
Microsoft OS and 'jump all over the memory map' object-oriented programming.
> You can believe Intel marketing all you want ("the desktop doesn't need more
> than 4GB of RAM in the next few years"), but that's a *lie*. Exactly
> because the 32-bit virtual limit is _not_ at 4GB, but hits us much before
> that (ie it hits at about 1GB of RAM - that's when the OS starts having
> trouble mapping all of physical memory _and_ user space at the same time
> without starting to have problems.
These days my dual Xeon workstation has 2 GB RAM, and my three year old
laptop has 512 MB (because that was the maximum for a laptop at the time).
I'm replacing the laptop, mostly so I can get at least 2 GB there as
well (disk, graphics and cpu are all more or less still fast enough for
what I do, while RAM is really critical), while the next workstation
replacement will almost certainly have 4 to 8 GB with a 64-bit OS.
> It's "highmem.sys" time all over again. And take it from me: that isn't five
> years down the road - it's been that way for a couple of years already.
> Every time I see a report on the 'net quoting some Intel person saying they
> don't need to worry about it for a few years, I just cringe. They are
> either incompetent or actively dishonest.
"The difference between a computer vendor and a used car salesman is
that the used car dealer knows when he's lying."
I.e. I've been in many vendor announcements/presentations where the
presenter have been simply wrong, but almost certainly didn't know better.
>
> (Don't get me wrong, btw. I actually _like_ Intel. The x86 is my favourite
> architecture simply because it beats everybody else hands down when it
> comes to choice and bang-for-buck. I just can't stand the public
> posturing).
>
> Anyway: even if the mail reader doesn't need any more than 32-bit VM, other
> parts of the system definitely would be improved by it.
>
> And AMD64 actually gets this right - you can continue to happily use your
> 32-bit apps that don't need the bigger address space, without any
> performance downsides. While the (much smaller) part of the installation
> that actually can take advantage of 64-bit addressing can do so.
Which is why I'm sure that Dell will have to reconsider/renegotiate
their current 'Intel ONLY Inside' policy.
Either that, or Intel will have to bite the 64-bit x86 bullet within not
more than 2 years.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Anne & Lynn Wheeler
> Remember the muscle cars? People finally figured out they didn't need
> 600HP to drive to the store for a loaf of bread and a quart of milk,
> so the muscle cars went away. That's when cars got really cheap.
foreign imports seemed to have contributed to making cars really cheap
... that was somewhat reversed with import quotas. government mandated
MPG had big effect on muscle cars .... however note that the large
SUVs are effectively the same class as the muscle cars (there may
actually be higher percentage than during the muscle car days).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Paul Repacholi
> So AMD needs to drop the 32-bit versions to break the circle.
AMD has issued a sort of EOL of late '05 for the 32 bit chips,
`subject to demand'.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Toon Moene
> You can believe its marketing if you want, but there are already people
> running into limits (which are more like 2GB than 4GB for the way most
> OSes work) And with RAM cheap enough that it isn't unusual for normal
> people to buy a system with 1GB these days,
Indeed. Just a couple of months ago I was contacted by some researchers
who wanted to write > 2Gb unformatted records from their code (just
because they wanted to dump an array that large at once).
Guess what ? I have the update for that in my local g77 tree now for
two months, but I don't dare to commit it, because - on my feeble 256
Mbyte Powerbook - I can only test that it doesn't break existing code -
I can't *run* a program that does what those people want.
My next system has to have more than 4 Gbytes (probably 6 is a good
number) and I need it in 2004, because otherwise I'll routinely depend
on others to run my tests.
--
Toon Moene - mailto:to...@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)
Robert I. Eachus
> It's a question of having advantages of a mass market. If AMD continues to
> produce 32-bit versions of the Athlon chip (regardless of whether they base
> it on the old K7 architecture or just a cut-down K8) they automatically
> kill off interest in their 64-bit architecture.
> know that the Athlon64 is in deep trouble.
Since I have been following x86-64 as a technology closely for a
while, and AMD as a stock for years, let me contribute what I know on
this subject.
First, way back when, AMD had two Hammer designs, Clawhammer with a
256k L2 cache, and Sledgehammer with dual-DDR channels and a 1 Meg L2
cache. But a funny thing happened on the way to market, one of those
Duh! things that is obvious in retrospect. The design of the on-die
memory management software is such that ALL data being accessed from
main memory goes into L2 cache. This has some advantages for paging
and writing to disk, but it also means that when the graphics card
reads large texture files, they go into L2 on their way to the
graphics chip. Result? Too much cache pressure when running 3d games
on a 256k L2 cache Hammer.
Once AMD discovered this issue they designed a varient of Clawhammer
that was apparently intended to fix this problem. This design was
called Paris. When the Athlon64 was launched the market expectation
was for Paris chips to begin with, then a high-end variant based on
the Sledgehammer core.
What happened was that AMD started talking just before launch about a
manufacturing glitch, and the two introductory Athlon64 chips were the
Athlon64 FX-51, a Sledghammer in 940-pin packaging, and Athlon64
3200+, a Sledgehammer chip in a Socket 754 package, with only one DDR
channel available (due if nothing else, to the packaging).
As of this month, AMD has a new product roadmap,
http://tinyurl.com/a23 Notice that AMD now has a third new design as
the 0.13 micron Athlon64, called Newcastle, and Paris is to eventually
be sold as an Athlon XP.
(What follows is speculation, but informed speculation.) What is
going on? My guess is that the fix in Paris provided decent graphics
performance in 32-bit mode, but that in 64-bit mode a 256k L2 cache
was still too small. So Paris will be sold as an Athlon XP in Socket
754 packaging. I don't know whether Paris will be sold as a 32-bit
only chip, or a chip with best performance as a 32-bit CPU, but with
64-bit addressing available. In other words, on Sledgehammer, and
presumably Newcastle, Athens, etc., 64-bit code runs faster than
32-bit code (mostly due to the added registers), while on Paris the
opposite is true due to cache pressure. My guess is that Newcastle
will have a 512k L2 cache, but it may be 1 Meg. Winchester, the 90 nm
version of Newcastle is more likely to have a 1 Meg cache. (But San
Diego, the 90 nm Athlon64 FX will have a 1 Meg cache, and dual-DDR, so
it will be the chip of choice for those who want performance.)
Whew! A lot of Hammer code-names in there with not much information
available without signing an NDA. But the important things to note
are: AMD is abandoning the Socket A that has been used since
Thunderbird. The last Socket A parts will be manufactured next year,
new wafer starts may end as soon as 2Q04, but will certainly end in
3Q04, with the last volume sales in 4Q04.
Second, the Athlon XP family will be Hammer compatible. If not with
Paris and Dublin next year, with Polermo and Trinadad in 2005. It is
possible right now to separate the added registers from the 64-bit
address support. The 64-bit address support in Hammer depends on, of
all things, the PAE flag. There is a separate bit that indicates
64-bit long mode with the added registers. I don't know how much of
the current PAE pain occurs if you try to use it with a Hammer chip in
"compatibility" 32-bit mode. I don't even know if it is currently
possible. But either Intel could go this route with Xeons, or AMD
with the Athlon XP family, and there would be 64-bit addressing
support without the added registers. (The current non-FP registers
would need to be 64-bit though.)
So my suspicion is that Linus has it right. AMD is going to leave
32-bit only x86 chips in the dust, while continuing to support
compatibility mode software. In fact, with current Hammer chips once
you are running a long-mode OS, you are ahead of the game.
Compatibility-mode user processes can have a 4 Gig address space for
non addition cost. I don't know how they will distinguish the Athlon
XP chips from the Athlon64 chips, but I expect it to be on performance
and only performance.
Del Cecchi
"Felger Carbon" <fms...@jfoops.net> wrote in message
news:VD%vb.12111$n56....@newsread1.news.pas.earthlink.net...
old males had a lot of accidents and stopped insuring them, and then the
arabs tripled the price of gas. Then government passed CAFE. Game over.
Bad analogy.
del cecchi
>
News sbc
Some of the applications that most desperately need >32 bits
of virtual address are the applications Intel needs to assemble
and tape out a chip.
I know, from when I was at Intel, that around the end of P6 (1995)
some of these had to be rewritten to partition the database into
chunks that fit in a 32 bit address space.But that trick doesn't
work forever.
I don't know if Willamette taped out using such kluges, or if
it taped out on 64 bit HP-PAs or Itanics.
Continuing to tape out on Itanics is probably not so good an idea,
since these apps are often the type that run most poorly on Itanic.
HP PA probably has not kept up. I doubt that anyone at Intel would
risk using AMD 64 bit chips to tape out, even if they are significantly
better price performance wise for the task than Itanium.
Which leads to my flash:
If, as is widely conjectured, some Intel chip has a non-EPIC 64 bit
extension to the x86, perhaps Intel may not release that chip for
sale to the outside world? Perhaps they would use it just for internal
use, as in taping out a new CPU?
If Intel is using 3rd party tools, this would probably imply that Intel has
implemented the AMD-64 instruction set --- since such 3rd party tools
are unlikely to be available for an unreleased Intel x86-64 that is
incompatible with AMD-64.
(Less likely scenario: Intel has secretly contracted some CAD vendor
to port to a hypothetical non-AMD-64 compatible Intel x86-64. Or,
Intel is using internal tools only.)
I wonder if Intel has purchased any AMD-64 licences for CAD tools?
I suppose if they had, they would have tried to make it untraceable.
---
This post is purely based on conjecture, extrapolating from news reports.
Anton Ertl
You keep us on our toes: Never ignore postings by people with
obviously misconfigured news readers, it might be you:-)
>I don't know if Willamette taped out using such kluges, or if
>it taped out on 64 bit HP-PAs or Itanics.
Alphas?
>Continuing to tape out on Itanics is probably not so good an idea,
>since these apps are often the type that run most poorly on Itanic.
How important is performance for this task?
...
>If, as is widely conjectured, some Intel chip has a non-EPIC 64 bit
>extension to the x86, perhaps Intel may not release that chip for
>sale to the outside world? Perhaps they would use it just for internal
>use, as in taping out a new CPU?
If they really intend to release such a chip to the public under no
circumstances, then that would probably be uneconomical. It would
probably be cheaper to get the same speedup by investing in the
compiler (which also helps the Itaniums elsewhere) and by tuning the
application; or maybe just lose some time on every tapeout.
However, I find it hard to believe that they do not develop such a
chip as a backup plan if IA64 does not catch on (and announce it when
it is ready, or when AMD64 catches on, whichever is later). In that
case they could just as well use it internally.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Stefan Monnier
> fraction of code needs 64 bits. You only need 64 bit addressing for really
> large programs (there is always PAE if you need it).
Immediate need is irrelevant. You need to have 64bit machines everywhere
by the time it's needed. That's why SGI made the R4000 a 64bit CPU even
though they only came up with a 64bit OS several years later.
The production costs of having the AMD64 support are basically nil:
the only real cost is in the design stage. So if you've designed it,
it makes no sense not to include it on every chip.
I.e. it's basically like "support for CMOVE" or "support for full
virtualization", ... maybe very few people need it, but it doesn't make any
sense not to provide it if you've done the work already.
Stefan
Tony Hill
<andy-gle...@sbcglobal.net> wrote:
>I just had a vision, a flash:
>
>Some of the applications that most desperately need >32 bits
>of virtual address are the applications Intel needs to assemble
>and tape out a chip.
Yes, Intel and every other vendor doing this sort of design.
>I know, from when I was at Intel, that around the end of P6 (1995)
>some of these had to be rewritten to partition the database into
>chunks that fit in a 32 bit address space.But that trick doesn't
>work forever.
I don't know exactly when these tools were rewritten, but yeah, a lot
of them are designed to use all the ugly hacks that make them work on
x86 (32-bit) chips with more than 4GB of memory.
>I don't know if Willamette taped out using such kluges, or if
>it taped out on 64 bit HP-PAs or Itanics.
>
>Continuing to tape out on Itanics is probably not so good an idea,
>since these apps are often the type that run most poorly on Itanic.
I don't see what that should be the case, given a sufficiently
intelligent compiler. SPEC CINT2000 has a couple sub-tests that are
related to this in 175.vpr and 300.twolf tests (both are targeting
FCPG Place 'n Route, not quite the same thing but should have similar
performance characteristics). The Itanium2 isn't exactly running away
with it here, but in both tests the Itanium2 (1.5GHz/6MB L3) is
roughly equal to the Opteron 246 (2.0GHz) processor, and both are near
the top (P4's and Athlon64 FX chips are slightly ahead). There's
nothing in taping out that I can think of which would make the code
very bad for the explicitly parallel architecture of IA-64.
Either way, you better believe that the Itanium is EXACTLY what Intel
wants the whole world to use for this sort of task. It's also what
Intel uses internally.
>HP PA probably has not kept up. I doubt that anyone at Intel would
>risk using AMD 64 bit chips to tape out, even if they are significantly
>better price performance wise for the task than Itanium.
Hell no! It's IA-64 all the way!
>Which leads to my flash:
>
>If, as is widely conjectured, some Intel chip has a non-EPIC 64 bit
>extension to the x86, perhaps Intel may not release that chip for
>sale to the outside world? Perhaps they would use it just for internal
>use, as in taping out a new CPU?
>
>If Intel is using 3rd party tools, this would probably imply that Intel has
>implemented the AMD-64 instruction set --- since such 3rd party tools
>are unlikely to be available for an unreleased Intel x86-64 that is
>incompatible with AMD-64.
Intel is the #1 customer for third-party tools for chip design in the
world. And guess what? When your number 1 customer comes up and says
"Give us an IA-64 port ASAP!", the tool vendors listen.
>I wonder if Intel has purchased any AMD-64 licences for CAD tools?
>I suppose if they had, they would have tried to make it untraceable.
Intel likely doesn't need an AMD64 license for any reason, the
cross-licensing agreement they have with AMD should cover them.
Terje Mathisen
> <andy-gle...@sbcglobal.net> wrote:
>>I wonder if Intel has purchased any AMD-64 licences for CAD tools?
>>I suppose if they had, they would have tried to make it untraceable.
>
> Intel likely doesn't need an AMD64 license for any reason, the
> cross-licensing agreement they have with AMD should cover them.
Not the same thing at all!
Andy was wondering about chip design sw compiled for AMD64, not a
license to produce (plug-)compatible chips!
Anyway, you're almost certainly right, in that Intel would use IA64 for
these tasks.