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.

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. =

I just hope intel will let the market decide on what is the best between itanium and X86

Just to show dad

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. 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. =

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>

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...

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.

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.

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>