Sign in with
Sign up | Sign in
Your question

multi core cpus

Last response: in CPUs
Share
October 19, 2003 1:03:51 AM

http://www.theregister.co.uk/content/61/33429.html

Amd is going to put out a dual core chip in their opteron range and intel plans on it as well. I just hope that intel doesn't try to put two prescotts on the same chip, 90-100watts x2 = one [-peep-] hot chip!

Join the TomsHardware IRC channel <A HREF="http://skulls.sytes.net/tom/ " target="_new">http://skulls.sytes.net/tom/ </A>

More about : multi core cpus

a b à CPUs
October 19, 2003 3:55:49 AM

This is the chip the Athlon 64 was supposed to be, according to what I remember from around 1999 when the plans were first mentioned. A dual 32-bit core that operates in true 64-bit mode by splitting operations, or dual 32-bit mode, if I recall correctly. No, I don't know how that works.

<font color=blue>Only a place as big as the internet could be home to a hero as big as Crashman!</font color=blue>
<font color=red>Only a place as big as the internet could be home to an ego as large as Crashman's!</font color=red>
Related resources
a b à CPUs
October 19, 2003 7:17:03 AM

That's something else I don't really understand, isn't the A64 just a 32-bit processor with 64-bit extensions?

<font color=blue>Only a place as big as the internet could be home to a hero as big as Crashman!</font color=blue>
<font color=red>Only a place as big as the internet could be home to an ego as large as Crashman's!</font color=red>
October 19, 2003 7:26:58 AM

I thought that was the example of Prescott/Tejas with 64 bit extensions (Aka Yamhill). I was pretty sure that the A64 was purely 64 bit with support for legacy 32 bit instructions

:cool: I run my AthlonXfx at 7.65 Exahertz :cool:
a b à CPUs
October 19, 2003 7:40:45 AM

And here I thought the A64 was just an enhanced Barton with 64-bit extensions.

<font color=blue>Only a place as big as the internet could be home to a hero as big as Crashman!</font color=blue>
<font color=red>Only a place as big as the internet could be home to an ego as large as Crashman's!</font color=red>
Anonymous
a b à CPUs
October 19, 2003 9:50:46 AM

It is really; just like the P4 is actually just a 16 bit 8086 core with some added 32 bit extentions, a few SIMD extentions and such.

The opteron/Athlon64 isnt any less a 64 bit cpu as the P4 is a 32 bit cpu.

= The views stated herein are my personal views, and not necessarily the views of my wife. =
October 19, 2003 8:47:17 PM

All you need for a 64bit cpu is the extensions, the unique thing about amd's 64bit offerings is that they can run both 64 and 32bit applications natively so there is no speed lost in emulation.

Join the TomsHardware IRC channel <A HREF="http://skulls.sytes.net/tom/ " target="_new">http://skulls.sytes.net/tom/ </A>
October 20, 2003 12:41:13 AM

Depends on what you mean by "emulation". Modern x86 MPU's could arguably all "emulate" x86. Since all x86 instructions are decoded and converted to internal risc-like micro-ops.
So what would make hardware decoding "native" and firmware or software decoding "emulation"?

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
October 20, 2003 1:32:23 AM

decoding 1 to 3 cycle
emulation multiple instruction for decoding

I dont like french test<P ID="edit"><FONT SIZE=-1><EM>Edited by juin on 10/20/03 11:09 AM.</EM></FONT></P>
October 20, 2003 6:43:44 AM

there is the itanium line which looses a substantial amount of speed in the conversion, it is designed specifically for 64bit operation. The way I used natively meant there was no conversion at all.

Join the TomsHardware IRC channel <A HREF="http://skulls.sytes.net/tom/ " target="_new">http://skulls.sytes.net/tom/ </A>
October 20, 2003 7:22:21 AM

However, like I said, modern x86 MPU's convert x86 instructions into RISC-like micro-ops. By your logic, they'd all be "emulating". And despite popular myth, Itanium and Itanium 2 do not convert x86 instructions. There is an entirely dedicated x86 processor latched on it. It just happens to run at the speed of a P2 450 (even though the chip is running at 1 GHz).
Emulation doesn't always cause significant slowdowns. Primary examples would be the FX!32 used on Alpha and Transmeta's "code morphing". Sometimes, converting one instruction set to another type of instruction set could actually help performance (look at any modern x86 MPU, the P4, Athlon, P3, etc, they all translate x86 instructions into RISC-like micro-ops).

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
Anonymous
a b à CPUs
October 20, 2003 12:26:10 PM

The semantics of emulation aside, there is little unique about AMD's approach; its the exact same approach that was used from 8 to 16 and from 16 to 32 bit in the x86 world. Also, any other 64 bit architecture except Itanium is fully capable of running older 32 bit binaries at full speed. Be it SPARC, Alpha, Power(PC), PA Risc,.. Itanium is just the only architecture with no real legacy.

= The views stated herein are my personal views, and not necessarily the views of my wife. =
October 20, 2003 3:20:16 PM

itanium support 32 bit FP code from is own ISA.

As far as i know itanium must switch mode between X86 and IPFISA and not all functinal unit can work on X86 ops code i not sure but branch are change also as they only support 64 bit branch.

Fx32 does hit hard on performance for the 1 run they trick is to cache flush the older code and replace it with the native code i guess the fx32 use predicate computing.Dynamo from Hp use the same concept.The good part is IA-32 support will be kill in itanium that will leave a great place just bettween cache and ALU and the desigh of alu will be much easier.Should move around 60% of the die of a P4 core.

I dont like french test
Anonymous
a b à CPUs
October 20, 2003 6:28:00 PM

"32 bit FP code from is own ISA"

You mean like 32 bit FP <b>precission</b> ? If such a thing even exists (even x87 does 80 bit, SSE2 does 64 AFAIK) it has *nothing* to do with the issue at hand.

>As far as i know itanium must switch mode between X86 and
>IPFISA and not all functinal unit can work on X86 ops code
>i not sure but branch are change also as they only support
>64 bit branch.

"64 bit branches" ?? WTF are you smoking ?

= The views stated herein are my personal views, and not necessarily the views of my wife. =
October 20, 2003 7:13:37 PM

Quote:
As far as i know itanium must switch mode between X86 and IPFIS

Im pretty sure the IA-64 Itanium doesnt execute x-86 code Juin......

At least that is what it seems like u r trying to say it does......

Does Itanium have an x-86 mode?? It has x-86 registers??? Hmm...sum 1 prove me otherwise...

<A HREF="http://www.anandtech.com/mysystemrig.html?id=13597" target="_new">-MeTaL RoCkEr</A><P ID="edit"><FONT SIZE=-1><EM>Edited by MeTaLrOcKeR on 10/20/03 03:15 PM.</EM></FONT></P>
October 20, 2003 7:37:05 PM

A little explanation about X86 and data precision
X86 op template mask and data and data precison

8086 ISA the base of X86

8 bit opcode
8 bit extra if long opcode
2 bit mode field
3 bit register field
3 bit register or memory field
16 reserve for displacement by the field more if that a long opcode (but i not sure about this one )
8 data for 8 bit mode (AL/AH)
extra 8 bit for 16 bit mode int in C language (ax)
extra 16 bit for 32 bit mode long int in C language (eax)
extra 32 bit for 64 bit mode (AMD64 long mode) (rax)

8 bit mode 32/40+8 =40+/48+
16 bit mode 32/40+16=48+/56+
32 bit mode 32/40+32=64+/72+
64 bit mode 32/40+64=96+/108+

some time there extra stuff like adresse range port or else.

The point is data precision is the last part of the instruction cuz in X86 there is no difference until it reach the front end of the cpu where it got decode between instruction opcode and data operand and store to they proper place as data are in GPR or FPR and decoding use rename register as each stuff will be place where it should go to not send to large information to the functional units.

In itanium or pentium pro,opteron,EV7 they allwayse a instruction and data size or precision and overflow register or something similar.In short you can allwasye have more precison even a 100000000000000000000000 bit precision it will just take few hour to calculate.Itanium support 32 FP data cuz it faster to excute also reduce chance of a bottlenerk in the delay of propagation,in others word the time it take to the electron flow to be stable at the new given voltage state.

I dont like french test
October 20, 2003 7:52:41 PM

yes it alu can work on X86 instruction and reg can take 32 data code but a lot stage in itanium do not aply to X86 like in I2 there a decoder (yes there one)call disparity stage as the I2 dont work on 3 instruction with 1 units so the 123 bit of instruction will be spilt and send to the sheduler and they will put in instruction buffer wich is very in I2 as in any case it almost empty unless there a event in the CPU like L1 miss misbranch or tlb miss wrong predicate instruction (wich can only happen in I2).In short there 3 state that must be bypass after not all of the 6 alu or 4 FPU support X86 like not all functinal support X86 opscode cuz it dont work with same size also path are made for 41 but instruction only if overflow it must wait for the next cycle (i speculate on that).Intl have guess that they were able to make work 2 isa in the same cpu wich trust me impossible if you do you will make sacrifice in instruction latency or clock speed it will as been easier to put a banias core inside still cache will get polute between mode switching and there will be lose in instruction cache and others probleme.

I dont like french test
October 20, 2003 7:54:47 PM

in fact X86 support at hardware level will be totaly deleted for moving a kind of vitual machine like java.

I dont like french test
October 20, 2003 9:50:29 PM

Quote:
The semantics of emulation aside, there is little unique about AMD's approach; its the exact same approach that was used from 8 to 16 and from 16 to 32 bit in the x86 world. Also, any other 64 bit architecture except Itanium is fully capable of running older 32 bit binaries at full speed. Be it SPARC, Alpha, Power(PC), PA Risc,.. Itanium is just the only architecture with no real legacy

Itanium 2 doesn't "support" legacy code because there *is no* IA-64 legacy code. IA-64 is completely new, it wasn't extended. PPC was extended. Although Alpha and Sparc were *never* 32-bit, same as IA-64. So I wonder what you mean by "32-bit binaries".
You can certainly use 32-bit integers on IA-64 if you wanted. And in most cases, people do. Microsoft has kept standard int to 32-bit even on IA-64 developement versions of Windows. Long is reserved for 64-bit integers. So please, stop equating IA-32 with "32-bit".

Quote:
You mean like 32 bit FP precission ? If such a thing even exists (even x87 does 80 bit, SSE2 does 64 AFAIK) it has *nothing* to do with the issue at hand.


Erm......x87 handles a *maximum* of 80-bit precision. The x87 ISA provides handles for Single-precision (32-bit) FP, double-precision (64-bit) FP and extended-precision (80-bit) FP. SSE provides SIMD instructions for handling single-precision FP only. SSE2 extended that functionality to include 64-bit FP.
The bulk of modern gaming as well as many other applications use 32-bit SP, there's simply no need for 64-bit DP in many cases, it only hurts performance. In some cases, double needs to be used, primary example would be 3D Rendering.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.
Anonymous
a b à CPUs
October 20, 2003 9:58:00 PM

Thats a nice post, but its <b>completely</b> beside the point. surely, FP bit precision has nothing to do with a cpu being 32 or 64 bit. The 486 could do double precision floating point (64 bit, 80 bit internally). What on earth are you trying to prove ? That the 486 (or even 386+387) is a 64 bit cpu ? Or the P4 and Athlon XP 128 bit cpu's (SSE) ?

Remember the point: I said just about every 64 bit cpu can handle legacy 32 bit code, be it Opteron, SPARC, Power, etc.. Itanium is just the only ISA that has not been extended from 32 to 64 bits, its been created from the ground up from nowhere as a 64 platform, hence there is no legacy 32 bit code. FP precision has about as much to do with this, as the 32 bit colour depth of its videocard or the 24 bit sound output.

= The views stated herein are my personal views, and not necessarily the views of my wife. =
October 20, 2003 10:01:09 PM

I2 GPR regiter cannot be split

I dont like french test
October 20, 2003 10:05:36 PM

64 bit CPU:D ata precision of 64 bit can fit in GPR.Again 80 bit internally can be overpass by assembly language easy.That why IA-64 support 82bit precision so long float can be support

I dont like french test
Anonymous
a b à CPUs
October 20, 2003 10:09:31 PM

>tanium 2 doesn't "support" legacy code because there *is
>no* IA-64 legacy code

That was exactly my point.

> Although Alpha and Sparc were *never* 32-bit,

Hu ? Well, here is a quote from a random PDF I googled:"SPARC chips began as a 32?bit processor family,
named simply SPARC Version 7 and Version 8, but by the late 1980s it was clear that Sun would
eventually need a 64?bit microprocessors"

You are right on the Alpha though, I thought it also supported 32 bit VAX code natively, but I was wrong on that one.

>So please, stop equating IA-32 with "32-bit".

What do you mean.. "equating". When I say x86 is 32 bit, I refer to register size and address size, not FP like Juin, not integer size, not colour depths or memory bus width. By that same metric, x86-64 is 64 bit, as are all the other architectures mentioned. What are you trying to tell me ?

= The views stated herein are my personal views, and not necessarily the views of my wife. =
Anonymous
a b à CPUs
October 20, 2003 10:26:00 PM

>64 bit CPU:D ata precision of 64 bit can fit in GPR

Hu ? is that your definition of a 64 bit cpu ?? Floats are calculated in the FPU, hence stored in FPR's not GPR's. I really, really don't see your point

= The views stated herein are my personal views, and not necessarily the views of my wife. =
October 20, 2003 11:03:41 PM

The original purpose of this thread was to consider the thermal characteristics of multi core cpus, modern cpus generate enough heat on their own, it will be interesting to see twice the heat output from the same size chip and how heatsink manufacturers deal with it. Is a dual cpu chip really the most efficient way of doing things? I think not.

Join the TomsHardware IRC channel <A HREF="http://skulls.sytes.net/tom/ " target="_new">http://skulls.sytes.net/tom/ </A>
Anonymous
a b à CPUs
October 20, 2003 11:28:48 PM

> it will be interesting to see twice the heat output from
> the same size chip

dual core != twice power consumption
A lot of things are shared in a dual core design, especially for the K8; cache, memory controller, HT links. I wouldnt dare speculate how much a dual core opteron would consume, but it will definately not be 2x as the single core.

= The views stated herein are my personal views, and not necessarily the views of my wife. =
October 21, 2003 1:02:36 AM

is about data precision of 1 gpr as normaly the industry use GPR as a standart a 64 bit cpu should support 64 precision in a single fetch and single GPR

I dont like french test
October 21, 2003 1:39:36 AM

Quote:
Thats a nice post, but its completely beside the point. surely, FP bit precision has nothing to do with a cpu being 32 or 64 bit. The 486 could do double precision floating point (64 bit, 80 bit internally). What on earth are you trying to prove ? That the 486 (or even 386+387) is a 64 bit cpu ? Or the P4 and Athlon XP 128 bit cpu's (SSE) ?

Wasn't my point, I was simply correcting your incorrect statements on FP.

Quote:
Remember the point: I said just about every 64 bit cpu can handle legacy 32 bit code, be it Opteron, SPARC, Power, etc.. Itanium is just the only ISA that has not been extended from 32 to 64 bits, its been created from the ground up from nowhere as a 64 platform, hence there is no legacy 32 bit code. FP precision has about as much to do with this, as the 32 bit colour depth of its videocard or the 24 bit sound output.

And like I said, Sparc and Alpha were never extended from a "32-bit" ISA to its current state. I don't think MIPS was either.

Update: on a latter note, it seems Sparc was extended. However, Alpha and MIPS were not.

"We are Microsoft, resistance is futile." - Bill Gates, 2015.<P ID="edit"><FONT SIZE=-1><EM>Edited by imgod2u on 10/20/03 06:44 PM.</EM></FONT></P>
Anonymous
a b à CPUs
October 21, 2003 10:29:01 AM

>Update: on a latter note, it seems Sparc was extended.
>However, Alpha and MIPS were not.

So was MIPS. <A HREF="http://www.umc.com/english/news/20020603.asp" target="_new"> In addition, the MIPS®32- and 64-bit architectures are fully compatible. This enables customers with 32-bit MIPS-based™ products to seamlessly transition to these new 64-bit cores and preserve all of their software investment.</A>

= The views stated herein are my personal views, and not necessarily the views of my wife. =
October 21, 2003 3:19:27 PM

also been extended to 16 bit later for new market

I dont like french test
!