Intel confirmed: 64-bit tech by 1H 2004!!!

Mephistopheles

Distinguished
Feb 10, 2003
2,444
0
19,780
For anyone out there who still hasn't seen anything...

Intel opened IDF by showing a 64-bit processor, fully compatible with x86-64, running on a desktop version of Win64 for extended systems, and the thing was fully functional.

Xeon/Nocona parts are expected to be launched within the 1st half of 2004, with 64-bit technology enabled and possibly some other architectural improvements that are disabled on prescott. Read <A HREF="http://www.xbitlabs.com/news/cpu/display/20040217105329.htm" target="_new">Xbitlabs' article</A>, it's nice...

Microsoft also confirmed <A HREF="http://zdnet.com.com/2100-1103_2-5160169.html" target="_new">that Intel's implementation is fully compatible with AMD's</A>; however, this still doesn't mean there's nothing more to it than an exact copy of AMD64 technology.

Finally, <A HREF="http://www.theinquirer.net/?article=14189" target="_new">the inquirer</A> was quick to point out Barrett's first speech on 64-bit extensions, though it didn't say anything about instructions, and gave <A HREF="http://www.theinquirer.net/?article=14192" target="_new">more info on compatibility</A> later on as well.

Interestingly enough, they tried to play all cards on itanium as well. It will get explicitly multithreaded and multicored, plus get a faster system bus and PCIe... An attempt to put Itanium on an Ivory Tower, apparently... Isolated, unreachable, big...

More on all of this will probably be available for reading when THG's, Xbitlabs and anandtech all publish their "1st day coverage" links...

<i><font color=red>You never change the existing reality by fighting it. Instead, create a new model that makes the old one obsolete</font color=red> - Buckminster Fuller </i>
 
<rumor>

>Xeon/Nocona parts are expected to be launched within the

>1st half of 2004, with 64-bit technology enabled and

>possibly some other architectural improvements that are

>disabled on prescott. Read Xbitlabs' article, it's nice...

This isnt right its called IA32<b>e</b> not x86-64...which means support for 64-bit adressing.

Yeah that's right, Go <A HREF="http://www.theinquirer.net/?article=14191" target="_new">here</A>

DUH..

<i>
During his keynote, Barrett demonstrated a 64-bit x86 chip running on a Dell Dimension XPS desktop machine.

The move to add 64-bit extensions to the existing x86 architecture is a long time in coming for Intel. Rival AMD has been planning such an approach for a while, having already shipped both its Opteron server chips and its Athlon 64 desktop processors.

Their hand was forced," said Anil Vasudeva, an analyst at
Imex Research. Still, Vasudeva said the opportunity for chips
like Nocona is much larger than that for Itanium.
...
Intel's approach is compatible with AMD's, the representative
said. "There will be one operating system that will support all
(64-bit) extended systems," the representative said.

Linux could arrive earlier, though. SuSE Linux Enterprise
Server 9 from Novell is scheduled to arrive in July with support
for Intel's 64-bit extensions, spokesman Joe Eckert said.
A beta version is due in March, he added.
</i>

There is no way INTEL can make use an 32/64 in less than two quaters..so

Say with me like POPE always says : <A HREF="http://news.com.com/2100-1006_3-5160169.html?tag=nefd_top" target="_new">TEJAS!</A>

</rumor>
--------------

(Unknown MAge)<P ID="edit"><FONT SIZE=-1><EM>Edited by trolly on 02/17/04 03:12 PM.</EM></FONT></P>
 
Maybe IA32e is the name of the ISA...you never know...that way there is still some luck, but don't count on that either...

--------------

(Unknown MAge)
 
Okay, some minot nitpicking here:

>This isnt right its called IA32e not x86-64

Why would that make it wrong ? of course intel gives it another name, you seriously expected intel to call their implementation AMD64 ? Or even x86-64 ? In fact, its funny to see how intel tries to downplay the 64 bitness in this chip by calling it IA<b>32</b>e, while calling Itanium IA<b>64</b>.. I find that rather amusing :)

>which means support for 64-bit adressing.

semantics here, but: no. It means support for 64 bit registers. It probably means support for 64 bit integers (although it could also be 2x32 bit), and it definately means not 64 addressing. 1 Terrabyte means 40 bit addressing (physical most likely, so RAM), and probably 48 or so virtual. This is no different as Opteron and the first Itanium, there is just no use in spending silicon to allow up to 16 million terrabyte. 256 terrabyte (48 bit) is sufficient for now I think.

Linux could arrive earlier, though. SuSE Linux Enterprise
Server 9 from Novell is scheduled to arrive in July with support
for Intel's 64-bit extensions, spokesman Joe Eckert said.
this is interesting.. SuSE is already available for AMD64.. so either this means IA32e is somewhat different, or it just means SuSE wants to validate their OS for this new chip. Curious;...

>There is no way INTEL can make use an 32/64 in less than
>two quaters..s

What do you mean by this ?


= The views stated herein are my personal views, and not necessarily the views of my wife. =
 
heee, i guess youre right...

<A HREF="http://www.theinquirer.net/?article=14189" target="_new">This pretty much confirm's they are familiar...</A>

>What do you mean by this ?

I dont know...my username says it all 😀.

--------------

(Unknown MAge)
 
I'm curious if the nay sayers will now start embracing 64 bit, once intel's marketing starts showing off benchmarks, and predicting future trends.. The intel troopers will no doubt soon urge you to wait for intels 64bit desktop chip before buying anything :)

>Interestingly enough, they tried to play all cards on
>itanium as well

Of course they are.. why wouldnt they ? its not like they ever wanted to launch CT "crack in my ass" 😉 and its not like they'll burry Itanium now either. on the contrary, more than ever it will need any vocal support intel can give it. CT will sell itself, no need to hype it.

> An attempt to put Itanium on an Ivory Tower, apparently...
>Isolated, unreachable, big...

Hmm.. Ct chips already support multithreading, are likely to go multicore next year (AMD for sure), will also get faster busses and PCIe support. So, none if this is really all that impressive IMHO. performance might be though, remains to be seen.

= The views stated herein are my personal views, and not necessarily the views of my wife. =
 
Maybe IA32e is the name of the ISA...you never know...that way there is still some luck, but don't count on that either...
Aside from the marketing reasons for the name, I think there's also some logic behind it.

Let's face it, current 64-bit desktop technology, either from Intel or AMD, isn't truely a 64-bit chip. What I mean is, the main data type will remain 32-bit for a long time to come. Nearly anything you want to represent can fit inside 32-bit. That's 4 billion combinations still! And nearly every game only uses 32-bit floating-point numbers. And we've had 64-bit MMX and 128-bit SSE for years so register width for arithmetic operations was never a problem. Only for data blocks, 4 GB can start to become a limit and 64-bit pointers become necessary.

On servers, things are nearly the other way around. Lot's of data, like my account, can't be represented in 32-bit. :wink: Also, floating-point data is at least double precision 64-bit for scientific applications. Either way they really make use of 64-bit arithmetic operations.

So it makes sense that they named it '32-bit with 64-bit extensions', while Itanium is a true 64-bit processor.
 
Logical falacy; you assume (IMHO incorrectly) that desktop 64 bit chips would not be used to run 64 bit code, therefore they are not real 64 bit chips worthy of the name. That makes no sense. The chips really *are* 64 bit (at least I know that for K8, I doubt CT will be different). They fully support 64 bit long registers, integers and addressing (limited by implementation). Its not because 386/486/Pentiums where used mainly to run 16 bit windows and dos apps, that these chips werent true 32 bit cpu's. They where. That being said..:

>What I mean is, the main data type will remain 32-bit for a >long time to come.

If you don't need 64 bit ints, don't use them. no on does this on Itanium, Alpha, PA risc or SPARC either, cause its slower. Arent those real 64 bit architectures ?

> And nearly every game only uses 32-bit floating-point
>numbers

Excuse me ? Ahem, NO. you do realise x86 FPU has been 80 bit since the 386 coprocessor (i387) ? 32 bit FP is NOT enough precession for just about any app.

>On servers, things are nearly the other way around. Lot's
>of data, like my account, can't be represented in 32-bit

You mean all those million Xeons out there are useless ? Or not used in servers ?

>Also, floating-point data is at least double precision
>64-bit for scientific applications

BS.

>So it makes sense that they named it '32-bit with 64-bit
>extensions', while Itanium is a true 64-bit processor.

None whatsoever. There is nothing more 64 bit about Itanium than Xeon CT or opteron. One thing maybe, if I'm not mistaken Itanium support the full 64 bit virtual addressing (16 million terrabyte), maybe even 64 bit physical addressing, while Opteron/XeonCt current implementations are "limited" to 48bit virtual, 40 bit physical if I'm not mistaken.

If you think that matters, keep in mind that to exceed 48 bit virtual addressing, you'd need around 3600 72 GB SCSI disks <b>per process</b>. To make full "use" of 64 bit virtual addressing you'd need 230 million of those harddisks per process, and for its phyical addrssing, it means 8.5 billion of the highest density memory dimms. Thats more than exist on the entire planet, or will exist for decades to come. not really a usefull way to spend transistors and adress lines IMHO.

x86-64 is just as 64 bit as any other 64 bit architecture. don't let intel marketing try to tell you any different.

= The views stated herein are my personal views, and not necessarily the views of my wife. =<P ID="edit"><FONT SIZE=-1><EM>Edited by P4Man on 02/17/04 05:49 PM.</EM></FONT></P>
 
A little miskate on your part you cannot do 64 bit branch on Opteron unlike Itanium and others bigtin.
On data precision they all work the same with IEEE.

64 bit code?? that new what is a 64 bit code.

Just to show dad
 
> you cannot do 64 bit branch

64 bit branch ?

>64 bit code?? that new what is a 64 bit code.

Not "a" code, just code.. software, like programs and all that? code.

= The views stated herein are my personal views, and not necessarily the views of my wife. =
 
> you cannot do 64 bit branch

64 bit branch ?
He means that while AMD64 can do jumps to any address based on no condition (JMP instruction), conditional jumps (branching, J<i>cc</i> instructions) can only go to relative 32-bit addresses.

FWIW most (all?) IA32 kit had similar limitations--a conditional jump can't jump to just anywhere in memory. In general, though, it doesn't matter, because locality is characteristic of almost all conditional jumps. When conditionally jumping, the code likely won't have very far to jump--unless you put an obscenely large block of contiguous code inside an "if() {} else {}" sequence (and I mean <i>obscenely</i> large). For the extremely rare cases where a 32-bit relative jump by itself isn't enough, you simply do a double jump--have the relative conditional jump go to a nearby block of code, and have that block of code do an absolute jump wherever you please.

You generally only have to worry about arranging jumps like this if you're coding in assembly language or writing a compiler.

<i><Lionel Hutz> I'll be defending...The SCO Group!!!??? Even if I lose, I'll be famous!</i>
 
Logical falacy; you assume (IMHO incorrectly) that desktop 64 bit chips would not be used to run 64 bit code, therefore they are not real 64 bit chips worthy of the name. That makes no sense. The chips really *are* 64 bit (at least I know that for K8, I doubt CT will be different). They fully support 64 bit long registers, integers and addressing (limited by implementation). Its not because 386/486/Pentiums where used mainly to run 16 bit windows and dos apps, that these chips werent true 32 bit cpu's. They where.
Sure, eventually all applications will nearly only use 64-bit arithmetic. I'm just saying the transistion will be quite slow, definitely slower than the 16-bit to 32-bit transition. So I think it makes sense that Intel names it IA32e, so they can really advertise 64-bit for Itanium and in the future for a whole new desktop chip. Just wanted to give a possible explanation for the name, that's all...
Excuse me ? Ahem, NO. you do realise x86 FPU has been 80 bit since the 386 coprocessor (i387) ? 32 bit FP is NOT enough precession for just about any app.
That's only the internal precision. There's even no 80-bit extended precision format defined in any high-level language. Only single-precision and double-precision are really used. And SSE only has 32-bit precision internally (plus the three rounding bits of course), SSE2 only has 64-bit precision. And all game code I know uses nearly only single-precision.
You mean all those million Xeons out there are useless ? Or not used in servers ?
Not at all. You can perfectly do 64-bit arithmetic with 32-bit instructions. You'll just need at least two instructions so it will be noticably slower. Lots of server applications do use 64-bit arithmetic.
It's a very simple fact.
 
That's only the internal precision. There's even no 80-bit extended precision format defined in any high-level language.
Um...many C/C++ compilers have that type, typically called "long double." IIRC 3DSMax made heavy use of it, which is at least partly why it was so difficult to optimize it for SSE2.

Even C99 notices the existence of "long double":

<A HREF="http://grouper.ieee.org/groups/754/meeting-materials/2001-07-18-c99.pdf" target="_new">-Click-</A> (page 4, and several other places)

Just a minor nitpick. The rest of the argument just gets into a lot of semantic details as to "what constitutes 64-bit;" right now I'd sooner stick my nose in politics. However, I <i>will</i> point out that gcc on Alpha still recognizes the default size of int as 32 bits. If it didn't, coders would likely have to resort to the more recent, less portable fixed-size types like "int32" just to get a 32-bit integer...

<i><Lionel Hutz> I'll be defending...The SCO Group!!!??? Even if I lose, I'll be famous!</i>
 
Um...many C/C++ compilers have that type, typically called "long double."
True. But most of these compilers use it as a synonym for double, so it's effectively just 64-bit in most cases.
IIRC 3DSMax made heavy use of it, which is at least partly why it was so difficult to optimize it for SSE2.
I find that very hard to believe. The only reason I can think of why it was so difficult was because everything had to be manually optimized. I'm quite sure they never required a 80-bit floating-point format because of precision limitations.
Even C99 notices the existence of "long double":
It also states that it's not required to be supported, and it's allowed to use it as a synonym for double. Many processors don't support anything longer than 64-bit double, so for portability reasons it's advised to make long double equal to double anyway.
 
All I have to say is pot meet kettle.

Didn't Intel say they didn't see 64-bit emerging for several years? (But they would be there to meet the need?)

Apparently the AMD 64-bit machine has caused them a bit of concern?

Especially from this article that seems to indicate such.
http://biz.yahoo.com/rf/040217/tech_intel_2.html

Don't know the code on this board. If someone would be so kind as to make that hyperlink. I would appreciate it.


Missed this little blurb at the end of the article.

"They saw customers go to AMD, they listened hard, and now they've got a solution," Doherty said

Maybe they saw that the market was ready to accept a transitory chip instead of making the "BIG" jump? (By big I mean to a purely 64-bit chip like the IA?)



<P ID="edit"><FONT SIZE=-1><EM>Edited by GGS430 on 02/18/04 00:03 AM.</EM></FONT></P>
 
>Sure, eventually all applications will nearly only use
>64-bit arithmetic.

Not likely, and not what constitutes "64 bit computing" in the first place. I think this is an odd way of defining it, as even 32 bit cpu's can cope with 64 bit arithmetic just fine, even if slower. Instead let me use <A HREF="http://yarchive.net/comp/n_bit_cpu.html" target="_new"> this definition </A>:

As has been discussed here, and in that old BYTE article, there is a *long*
history in computing that the phrase "X is an N-bit CPU" meant that that
architecturally-visible size of the integer (or general-purpose) registers
was N bits.

>I'm just saying the transistion will be quite slow,
>definitely slower than the 16-bit to 32-bit transition.

Defintaly ? depends what you call "64 bit" If you use 64 bit arithmetic, it may take forever, but I think you're only one using that definiton. Using the more common definition, I definately think it will be MUCH faster. It took more than 10 years after the introduction of the CPU's before 32 OS and apps became widespread available (386 in 1985, W95/NT ~1995).

> so they can really advertise 64-bit for Itanium and in the
>future for a whole new desktop chip

You really think this is still going to happen now ? I'd rate its chances less than 1/100 now.

>That's only the internal precision

Again, you seem to use strange conventions determining the "bitness" of a cpu. Let me quote the same post:
Size of FP registers is also irrelevant to common nomenclature:

>Not at all. You can perfectly do 64-bit arithmetic with
>32-bit instructions. You'll just need at least two
>instructions so it will be noticably slower. Lots of server
>applications do use 64-bit arithmetic.

Which makes them 64 bit servers then ? Please do give us your definiton of 64 bit before we discuss this any further.


= The views stated herein are my personal views, and not necessarily the views of my wife. =
 
Didn't Intel say they didn't see 64-bit emerging for several years? (But they would be there to meet the need?)
Isn't that exactly what they're doing? There's not a single desktop applications I know that instantly terminates with an error "you need 64-bit". Do you?

For servers, x86-64 is a lot more interesting, but Intel had Itanium for years. So, while I have absolutely nothing against the success of Athlon 64, I find it stange that people accuse Intel for not supporting 64-bit sooner.
 
Not likely, and not what constitutes "64 bit computing" in the first place. I think this is an odd way of defining it, as even 32 bit cpu's can cope with 64 bit arithmetic just fine, even if slower.
What I mean is that eventually 64-bit will become the standard data format. It's like today we use many 32-bit variables in our programs even though only 16-bit or even 8-bit range is required. But this transition won't be very fast.
You really think this is still going to happen now ? I'd rate its chances less than 1/100 now.
Why not? They even announed new Itanium dual-core processors. They won't just stop with Itanium.
Again, you seem to use strange conventions determining the "bitness" of a cpu.
How useful is this bitness if 80-bit is nearly not used any more? Sure, internally it's 80-bit but would you name a processor with 128-bit internal precision that is only capable of writing it to memory in 32-bit format a 128-bit processor?
Which makes them 64 bit servers then ? Please do give us your definiton of 64 bit before we discuss this any further.
Sigh. All I'm trying to say is that any 32-bit x86 chip can do the same tasks an x86-64 chip can do, just a bit slower. That's for the arithmetic part. For addressing, 64-bit pointers does make a lot of difference. So essentially, x86-64 chips are mainly still used for the same 32-bit applications, but now they can address more memory linearly. Don't forget we've had 64-bit arithmetic for years with MMX. So it makes sense, at least to me, that Intel names it IA32e. I'm not at all saying it is the best or the better name.

In the end, it's all just marketing. Just like AMD64, for the desktop market, is still only marketing as well. But I'm ok with that and my next chip might be an Athlon 64. Can you just chill a little and feel ok with that too?
 
>What I mean is that eventually 64-bit will become the
>standard data format. It's like today we use many 32-bit
>variables in our programs even though only 16-bit or even
>8-bit range is required. But this transition won't be very
>fast.

Well, this doesnt really sound like a transition of any kind, more like coders getting lazy and wasting memory and bandwith really :) Hardly a reason for a different marketing name that excludes "64".

>Why not? They even announed new Itanium dual-core
>processors. They won't just stop with Itanium.

No, they won't stop, but it will remain a high end niche product. I just don't see how it could move down now that 64 bit x86 will become the norm. Chicken and egg, no users, means no software, no software means no users. With a massive performance lead you could perhaps convince ISV's to port ahead of an installed user base, and you could persuade some users to switch for even though there are only a handfull of apps; but even Alpha never managed this in spite of windows support, FX!32 compatibility and a 2x perfomance lead over x86. lack of 64 bit addrssing could have a reason for ISV's and consumers to drop x86 and switch to IA64, but with that argument gone, its not gonna happen anymore IMHO. in fact, I firmly expect MS to drop Windows support for it, like they dropped it for Alpha. Its just not making them any money at all.

> Sure, internally it's 80-bit but would you name a
>processor with 128-bit internal precision that is only
>capable of writing it to memory in 32-bit format a 128-bit
>processor?

I would never call a CPU a x-bit CPU based on FP precission, nor FP register length, but only on (GP) register length and addressability. A 386SX was a real 32 bit cpu for me, even though it didnt even have a FP unit, and it only had a 16 bit wide memory bus (physical). Still, it had all the features that make a cpu 32 bit by my definition (32 bit registers and 32 bit flat memory addressing). Would you call it a zero bit cpu ? or a 16 bit cpu because everyone used it with DOS/Windows 3.11 ?

>Sigh. All I'm trying to say is that any 32-bit x86 chip can
>do the same tasks an x86-64 chip can do, just a bit slower. >That's for the arithmetic part

Which nicely shows how useless arithmetic is to determine wether a architecture is 32 bit or 64 bit, wouldnt you agree ?

Look, you call the CPU perhaps 64 bit, but the software 32 unless it uses 64 bit INTs. I find that nonsense, cause by that definition, you could run 64 bit software without problem on a 32 bit (or even 16 bit) cpu. And most 64 bit cpu's, including 64 bit only cpu's like Alpha or Itanium would run "32 bit" code. Thats bogus, no one calls it that. Software is 64 bit if it makes use of the available register size and flat memory addressing, well that is my definition.

> Can you just chill a little and feel ok with that too?

no :) I have some issues with people that buy into marketing crap, especially when those people seem intelligent otherwise. IA32e (especially with the undercase "e", LOL), is nothing more than an attempt by intel to downplay its 64 bit capabilities compared to Itanium. There is however, no technical difference whatsoever, its just as 64 bit as Itanium, Alpha, Sparc, Mips or Power.

And as for 64 bit being purely marketing on the desktop for now, we'll, lets just agree to disagree. I am looking forward to have more than 2Gb address space, because I regulary need it, even being a desktop user. Not many people may need it, but that doesnt make it any less valueable for those that do.

= The views stated herein are my personal views, and not necessarily the views of my wife. =
 
Divx with win64 + 15% gain, Valve and others say >30% gains in thier games. No, we dont need A64, but it's as good to have as say Intel
That's mostly thanks to the extra registers, not because the registers are longer. A 32-bit chip with twice the number of registers would show comparable gains. Only things like encryption run a lot faster on 64-bit processors, but for desktops that's not used very often. Games definitely won't benefit from 64-bit registers alone, they've used 64-bit MMX and 128-bit SSE for long.

Not that I don't welcome the longer registers! Just wanted to make clear that 64-bit, mostly, isn't strictly <i>needed</i> yet. But it's good to have, I can definitely agree. And my next CPU will be 64-bit for sure.
 
Well, this doesnt really sound like a transition of any kind, more like coders getting lazy and wasting memory and bandwith really :) Hardly a reason for a different marketing name that excludes "64".
I never said '64' should be excluded. There truely is a big '64' aspect to it. But I can understand Intel's reason to name it IA-32e, other than for marketing reasons. Even in long mode, the standard data sizes are 32-bit for arithmetic, 64-bit for addressing. That's without using a prefix and that's how most instructions are 'meant' to be used so the code size is short. I can almost say it's a 32-bit chip with 64-bit addressing. But for that it requires 64-bit general-purpose registers which immediately seems to make it a full 64-bit processor. It's nitpicking, I know, but I just want to show that naming it '32-bit with 64-bit extensions' is just as correct as naming it 64-bit. Neither AMD or Intel is completely correct as this is a transition.
No, they won't stop, but it will remain a high end niche product. I just don't see how it could move down now that 64 bit x86 will become the norm. Chicken and egg, no users, means no software, no software means no users.
Very true. It's a shame though, since Itanium would really shine if it had a lot of applications optimized for it. Compilers for IA-64 still improve with every release. I never expect it to make the transition to the desktop market, but x86-64 might kill it even in the server market. Still hoping for the best...
Would you call it a zero bit cpu ? or a 16 bit cpu because everyone used it with DOS/Windows 3.11 ?
No. But I might have called it IA-16e and call the 486 or Pentium IA-32. It's just a name you know, and I wouldn't directly link general-purpose register length to architecture names. Besides, IA-64 was already reserved for Itanium. Either way, I find IA-32e a good name.
Which nicely shows how useless arithmetic is to determine wether a architecture is 32 bit or 64 bit, wouldnt you agree ?
I agree. But so is every physical measure. How would we call an architecture with 64-bit general-purpose registers where only the lower 32-bit can used for addressing? Or the other way around? I think it's much easier to name a 64-bit architecture one that is percieved as such. And IA-32e is still mainly used for 32-bit operations, it's just capable of addressing more than 4 GB linearly.
Software is 64 bit if it makes use of the available register size and flat memory addressing, well that is my definition.
Well, you clearly write "and". Very little applications make use of 64-bit integer variables, but when compiled for IA-32e/AMD64 they'll transparantly use 64-bit pointers. In C++ there's not even a 100% portable 64-bit integer keyword. Microsoft Visual C++ uses '__int64' but the double underscore clearly indicates it isn't standard. Nearly all 64-bit instructions are truely meant for pointer arithmetic. So, I find it very understandable to keep calling this 32-bit software. Which doesn't mean I find it incorrect to call it 64-bit software.
I have some issues with people that buy into marketing crap, especially when those people seem intelligent otherwise.
I said from the start that I wanted to give an explanation -aside- from marketing reasons, so I'll just take this as a compliment. :wink: I can't blame either Intel or AMD for their marketing but I can technically accept Intel calls it IA-32e and AMD calls it AMD64. I can't see why you don't feel even the slightest logic behind it.
There is however, no technical difference whatsoever, its just as 64 bit as Itanium, Alpha, Sparc, Mips or Power.
Technically, yes, the difference is small to non-existent. But applications written for Itanium or any other server 64-bit chip use 64-bit arithmetic operations frequently. So I just find it a tiny bit hard to put the desktop '64-bit' applications on the same level as server 64-bit applications. Just out of curiousity, how would you have named it?
And as for 64 bit being purely marketing on the desktop for now, we'll, lets just agree to disagree. I am looking forward to have more than 2Gb address space, because I regulary need it, even being a desktop user. Not many people may need it, but that doesnt make it any less valueable for those that do.
Aha! I wouldn't let my personal needs influence the opinion about hardware for the big public. I admit myself to have some preference for Intel because of my SIMD programming, but that influences in no way how I think about AMD chips. As a matter of fact I've advised people many times to buy an AMD chip because of price considerations. But my main argument to advise people to buy an Athlon 64 won't be because they'll be able to run programs with more than 2 GB addressing space, but rather the great performance and price, mainly for 32-bit applications. Some 64-bit arithmetic might eventually get used too but I'm very sure most applications will remain purely 32-bit or at least provide a 32-bit implementation as well.

I'm just curious, what well-written desktop application crashes because of 32-bit limitations?
 
>But I can understand Intel's reason to name it IA-32e,

So can I: trying to market it differently from Itanium, when really, there is no technical reason to do so.

>Even in long mode, the standard data sizes are 32-bit for
>arithmetic

Which you admitted is hardly relevant to anything. Is it not standard on Alpha and even Itanium as well ? I would be most surprised if it werent. And how about power, ultrasparc and mips ?

> I just want to show that naming it '32-bit with 64-bit
> extensions' is just as correct as naming it 64-bit

The same logic would make you call power, mips, sparc and pa-risc 32 bit cpu's with 64 bit extentions.. Let me suggest an alternative: lets call Itanium a 64 bit cpu, Power a 96 bit, and AMD64 a 112 bit processor (64+32+16) ?

>Very true. It's a shame though,

You must be one of the few people that wished for Itanium to become standard. Surely you realise that would mean >$1500 cpu's again ? slowing innovation ? I have no problems with Itanium competein (succesfully or not) in the big tin market, but I am damn happy I know I will now still be able to pick up a lightening fast, off the shelve desktop cpu or even dual server chip for less than $200 a piece. Thank God for competition.

> How would we call an architecture with 64-bit
>general-purpose registers where only the lower 32-bit can
>used for addressing?

32 bit obviously.

>Or the other way around?

The eight world wonder 😀 or a broken chip.

>I think it's much easier to name a 64-bit architecture one
>that is percieved as such.

Perception is the eye of the beholder. I do not perceive those as 32 chips, I see them as 64 bit chips with backwards compatiblbe 32 bit capability. Name them for their specs and capabilities, not their perception since your perception is already different than mine. Or would you call a Xeon CT used in IBMs future 64 way Xeon servers a 64 bit chip, while that same chip in a uniprocessor machine would be a 32+ bit chip ? Doesnt sound very rational to me.

>And IA-32e is still mainly used for 32-bit operations, it's
>just capable of addressing more than 4 GB linearly.

"just" ? yeah, its "just" capable of 64 bit math, 64 bit addressing and it has 64 bit registers (which is pretty much a must to allow 64 addressing. You need to store these pointers somehow). So, really, its "just" a 64 bit cpu. There is no way to achieve this on a 32 bit cpu, period.

>Besides, IA-64 was already reserved for Itanium. Either
>way, I find IA-32e a good name

IA-64 was taken, but AMD64 was still free 😀

> So, I find it very understandable to keep calling this
>32-bit software.

Okay, here is a challenge: find me ONE program or OS that uses 64 addressing and pointers on a 64 bit capable cpu, but uses 32 arithmetic and is therefore referred to by anyone somewhat credible (like the author, ISV, reviewer, analyist, intel, amd, who ever) as a 32 bit program. Just ONE example. I'm curious.

> but I can technically accept Intel calls it IA-32e and AMD
>calls it AMD64. I can't see why you don't feel even the
>slightest logic behind it.

intel can call it "Crack in My Ass Technology" if they like, but the logic behind it has nothing to do with technicallities (word?) such as 32 arithmetic, but everything with a rather desperate marketing attempt. I'm just kinda sensitive to these things, just like people used to rave "centrino". Centrino is crap; its just a perverse marketing mix of a superb mobile cpu (pentium m), a reasonable chipset (855) and an obsolete crappy 11 Mb WLAN chip from intel. I hate it when people end up buying a pentium m with that crap lan adapter instead of a cheaper, better, faster 54 Mb "g" card for the same price, or less.

> But applications written for Itanium or any other server
>64-bit chip use 64-bit arithmetic operations frequently

I hope you realize the irony of what you are saying here ? "other 64 bit server chip". Like what ? like Opteron/XeonCT ?

> Just out of curiousity, how would you have named it?

Named what ? Intels extentions ? AMD64 woudl have been my preference, but a bit much to hope for I guess. x86-64 would have been perfect though. neutral, and perfectly desciptive of the technology.

>I'm just curious, what well-written desktop application
>crashes because of 32-bit limitations?

Photoshop, MS OLAP (using a ~50 Mb database :) and sometimes games when still running one of the other apps.

= The views stated herein are my personal views, and not necessarily the views of my wife. =
 
intel can call it "Crack in My Ass Technology" if they like, but the logic behind it has nothing to do with technicallities (word?) such as 32 arithmetic, but everything with a rather desperate marketing attempt. I'm just kinda sensitive to these things, just like people used to rave "centrino". Centrino is crap; its just a perverse marketing mix of a superb mobile cpu (pentium m), a reasonable chipset (855) and an obsolete crappy 11 Mb WLAN chip from intel.
Erm... This is not a desperate attempt. Or would you think they can toss in 64-bit extensions in something like a couple of months and then rush it out the door in a sweat saying: "here, crack in my ass"... What is more likely is that they had their own implementation of 64-bit, and were probably forced by circumstance to change them over to AMD64-compatible stuff. And they did a quick job at it too; noone expected them to come out with 64-bit Noconas within the next 2-3 months from now. People were all raving about how it would take Intel at least another year from now to catch up. They weren't that unprepared, it would seem... This is still a blow to Itanium, and they know that. Which would make them very cautious with such a release. But this was unavoidable...

As for Centrino, noone is required to buy P-Ms with Centrinos. The problem is that people don't know the difference. You can't blame Intel for the world's ignorance, sorry. Plus, your reluctance to accept the great quality of Centrino's processor as one of its strengths before calling it crap is a little exaggerated.

<i><font color=red>You never change the existing reality by fighting it. Instead, create a new model that makes the old one obsolete</font color=red> - Buckminster Fuller </i><P ID="edit"><FONT SIZE=-1><EM>Edited by Mephistopheles on 02/18/04 11:36 AM.</EM></FONT></P>
 

TRENDING THREADS