IBM Processor Yields

[gekko513]

Specifically, under ASCII, characters are stored as an 8 bit number. Therefore in a 32 bit system you can store 4 ASCII characters in each memory value (2 in 16 and 8 in 64). I can't remember which way is which but one out of Intel / Motorola with the x86 and the 68xxx chose to store "Nice" as "Nice" and the other as "eciN". The reason for choosing the latter method is that it makes some string handling easier for a CPU. Emulators have to handle this difference when running on different architectures.

Well this is a nice explanation but not really accurate. When computer systems went beyond 8 bit, they all still kept backwards compatibility to 8 bit computation and storage. Memory is therefore still adressed with a number that points to 8 bits.

"Nice" is always stored as
Address - Value
0x0000 - N
0x0001 - i
0x0002 - c
0x0003 - e
But actually the direction of storage of strings are decided by the software and not by the processor.

The difference between little and big endian is the way 16, 32 or more bit values are stored. A 32 bit value is stored as four 8 bit values. In big-endian system, the numbers are stored with the most significant 8 bits at the lowest adress. Little-endian is the other way around. So the number 520 (256x2 + 8) is stored like this
Address - Big-endian - Little-endian
0x0000 - 0 - 8
0x0001 - 0 - 2
0x0002 - 2 - 0
0x0003 - 8 - 0

Intel processors are little-endian. And this article claims that the PowerPC system is bi-endian and can understand both.

 

[shamino]

The main reason AMD is making headway on Intel is it doesn't claim delivery before it can support such claims.

So, to you, it doesn't matter that their chips have equal power at half the price?

 

[shamino]

Im afraid it MAY not be that simple. Not only do PowerPC's have different general archetectures, they have opposite endians. PowerPC is big endian and X86 is little endian. When I say i X86 i include those AMD chips with the emulation layer. In order for them to properly emulate they would need to have the same endian.

This is actually one of the easiest problems to get around. You just tweak your load/store instructions to swap byte-orders when moving data between registers and memory, and leave just about everything else alone.

The byte-order (and bit-order, for that matter) inside the CPU doesn't have to have any relationship to the representation in main memory.

Also note that the PPC architecture (and most PPC chips) can work either way. The 970 (G5) is a notable exception (the lack of this feature is probably the reason that Virtual PC 6 isn't compatible with it.)

A much more difficult problem is emulating features that don't have analogues on the other architecture. Not knowing much about PPC or modern x87 assembly language, I can't name any specific features, but I would guess that the biggies would be the vector-math units (AltiVec on PPC, SSE on x86).

Also, the instruction pre-fetch/branch-predict/pipeline model would have to be emulated exactly. While making it different wouldn't break applications, it would hurt performance - code optimized for one model would not be optimized for the other.

 

[shamino]

Can you explain the little/big endian difference in laymen's terms?

Real simple. Memory is (normally) addressed in terms of bytes (8-bit integers, capable of representing numbers between 0 and 255.)

Most data, however, is too big for this. Integers in applications are most commonly 16 and 32 bits wide (2 and 4 bytes), with 64-bit (8-byte) becoming more common. Floating point numbers are typically 4- and 8-bytes wide.

When stored in memory, these numbers are typically stored in a contiguous range of bytes. But they can be stored in different orders. The most common two orders are big- and little-endian.

Big-endian is when you store the most-significant byte (the one storigng the highest-place digits) in the lowest memory address, with the least-significant byte (the one storing the lowest-place digits) in the highest memory address, and any other bytes ordered in descending order of significance.

Little-endian is when you store the least-significant byte in the lowest memory address, with the most-significant byte in the highest memory address, and any other bytes ordered in ascending order of significance.

There have been other schemes used in the past, but these two are the only ones you're likely to find in use, unless you have a collection of classic mainframes to play with.

Intel chips generally use a little-endian scheme. Other chips (from Motorola, IBM, SUN, etc.) typically use big-endian. Which is better is a matter of religious argument these days. The big deal is that data meant for one has the be converted (by swapping the byte-order of all multi-byte numbers) before it can be used on a processor that uses the other.

Normally, this is only an issue when reading data files from a disc or packets from a network. If you're emulating a processor with the opposite order, this is obviously something that the emulator must deal with as well.

 

[Dippo]

Historically, at least over the last two years or so, Intel chips have overclocked a LOT better than AMDs....

Before anyone actually thinks that what you say is true, you might want to provide something that supports your "theory".

AMDs overclock vastly better than Intels due to the ability to change both FSB and multiplier. My processor currently overclocks about 35%.

Anyways, what does that have to do with IBM's yield problems??

I think that IBM is just having the same problems that all of the chip makers are having. Getting the 90nm process just right is proving to be quite difficult. I hate to see the problems they are going to have with 65nm!

 

[shamino]

... ibm would not have even begun the G5 fabbing if they would have been happy with 3% market share in the beginning, ...

I assume you're aware of the fact that IBM chips are used in more than just Macintoshes.

PPC chips (and the POWER series they are based on) are used in a wide variety of IBM equipment, from mainframes, to server clusters, to workstations. Theyre also used in embedded devices (like routers and line-cards for telco equipment) from a wide variety of vendors. And then, of course, IBM makes more chips than just the PPC/POWER series of processors.

Intel's chips are also used in a wide variety of products besides PCs. And they also make other kinds of chips (remember the i860/960? How about the ARM/StrongARM?)

You can't take Mac-vs-PC market share numbers and jump to the conclusion that those numbers are the same as PPC-vs-x86 processor market share numbers.

 

[zelman]

I need to remind everyone, that even though making processor chips out of silicon is NOT rocket science, it is still a pretty difficult process to do. 😉

wasn't the space program around prior to silicon-based processors?

 

[HiRez]

"200mm" and "300mm" refer to the diameter of the wafer that the chips are produced on. "130 nm" and "90 nm" refer to the process size.

Except that the article says "nm". Confused me too.

 

[mdriftmeyer]

Whose chips specifically and how does AMD being able to meet their claims compare to IBM being unable to meet their claims?

We're not discussing chip performance on platforms. We're discussing a political issue to market technology that either they projected would be ready and now is biting them in the ass by not being ready, or IBM's own manufacturing branch projected too soon they could ramp up to meet the roadmap both Apple and IBM committed to publically.

Leaving conspiracy theories to the paranoid the option that IBM is now playing favorites I'll not even touch.

IBM is large enough and old enough that to make such claims to companies including Apple is just plain unwise.

So, to you, it doesn't matter that their chips have equal power at half the price?

 

[Henriok]

I assume you're aware of the fact that IBM chips are used in more than just Macintoshes.

The PowerPC-processor that by far have sold the most through the years must be the Gekko which powers the Nintendo GameCube. In the same time span, Nintendo have sold more GameCubres than Apple have made Macintoshes, and the GC uses only one type of PPC and Apple have used several models from different manufacturers.

In the future IBM will be making Cell processors for Sony, Xbox 2-processors for Micrsoft and GameCube 2 -processors for Nintento. Apple will be quite a small contractor when compared to all of the others. And, one can hope that IBM themselves stop procrastinating and starts a serious PPC/Linux assault on the Wintel market.

 

[cb911]

okay, that really had me confused. i thought, what the heck do i want to know about 200-300nm problems for? i thought that IBM was working on 90nm?

well, the article does say 200-300mm, but here at Mac Rumors it's reported as 200-300nm, that's quite a big descrepency in size. 😉

well, i don't really want to hear about the problems, i just want results!! 😀

 

[oingoboingo]

Actually, this isn't as crazy as it seems.

IIRC, AMD's K7 (Athlon) and K8 (Athrlon-64) architectures are actually a proprietary RISC architecture with an x86 emulation layer over the top. It may well be possible for them to make these with a PPC emulation layer instead.

It would probably be easier just to re-compile the software to run on the existing x86 ISA, rather than try and design a whole new chip with a PPC emulation layer on top of the Athlon core. Remember NEXTSTEP was running on x86, and only ported to PPC after Apple acquired NeXT. The first releases of Rhapsody also ran on both x86 and PPC.

I'm not saying Apple is going to do that, but I just think a software port would be easier than a hardware/CPU redesign...remember Linux runs on just about every major hardware architecture ever developed (x86, PPC, SPARC, Alpha, MIPS, PA-RISC, m68k and S/390 to name a few), Sun maintains concurrent versions of Solaris on SPARC and x86, IBM has AIX for POWER and IA64, and even Microsoft used to sell and support Windows NT 4 on x86, Alpha, MIPS and PPC, and until recently, Microsoft's Windows CE/Pocket PC OS ran on CPUs from both ARM and Hitachi.

If you take a look around the industry, single-platform operating systems are actually the exception, rather than the rule.

 

[JFreak]

I'm not saying Apple is going to do that, but I just think a software port would be easier than a hardware/CPU redesign.

easier for who?

apple is know in making things easy for the end user, and because of that, apple will not - unless forced to - release osx for some other cpu platform [than the ppc] because that would either force all mac software developers release different versions of the software or another possibility is that other cpu osx systems simply become second class mac citizens [due to lack of software support from many companies].

THAT, my friend, is the reason for the possibility of hardware ppc emulation. it is easier for the end user.

 

[oingoboingo]

easier for who?

apple is know in making things easy for the end user, and because of that, apple will not - unless forced to - release osx for some other cpu platform [than the ppc] because that would either force all mac software developers release different versions of the software or another possibility is that other cpu osx systems simply become second class mac citizens [due to lack of software support from many companies].

THAT, my friend, is the reason for the possibility of hardware ppc emulation. it is easier for the end user.

Again, let me start by saying that I don't think Apple will move OS X to x86. But hypothetically, weren't NEXTSTEP and Rhapsody capable of working with 'fat binaries', in the same way that earlier versions of Classic Mac OS supported fat binaries, with both Motorola 68000 and PowerPC code in the same package? There wouldn't need to be separate distributions for different architectures...just one CD or DVD which contains executables compatible with both. As for developers, if Apple was going a hybrid PPC/x86 route, they'd probably make cross-platform libraries available to developers, and producing an x86 version of existing PPC code would be down to a recompile.

So I still think it would be easier for Apple (and ultimately the end users, who would be oblivious to which binary type they were running) to go down a software route, rather than trying to develop a proprietary, one-off hardware implementation of a hybrid PPC/x86 chip. As for developers, well, they can go **** themselves. Witness the Classic/Copland/Rhapsody/NEXTSTEP debacle.

I promised myself I wasn't going to post in the news/rumours related forums any more, because these hypothetical arguments about the pros and cons of a hypothetical G5 iMac/G5 PowerBook/G5 iPod/Mac OS X on x86/Mac OS X on pocket calculator are all such a pointless waste of time. I'll see if I can restrain myself next time 🙂 Enjoy the show.

 

[dontmatter]

Other than the laws of physics. The reports I've read state that the heat the chips produce is melting the CPU before the heat energy even escapes the molecular level. Not an easy problem to counteract if you ask me.

OK....then how do AMD and intel do it?

 

[Telomar]

OK....then how do AMD and intel do it?

Neither of them have. Intel has completely changed their roadmap to get around the difficulties and AMD shifted their introduction of 90 nm parts by 12 months. Nobody has brought the 90 nm processes online without serious difficulties.

 

[dieselg4]

Just a prototype, or will it be an actual product by WWDC? (Will you be able to buy it)
😉

I think he was being facetious

 

[dernhelm]

Im afraid it MAY not be that simple. Not only do PowerPC's have different general archetectures, they have opposite endians.

From my understanding the best you could do with one of those amd chips would be to make an ALMOST pcc with a different endian. We would end up in the same place with annother VirtualPC type app.

If I am mistaken please ocorrect me, this is just how I have come to understand the differences in chip types.

MIPS architectures (since the R2000) can switch endianness at boot time. It really isn't that difficult of a problem to deal with. But endianness is only one small hurdle when talking about one processor emulating other architectures, I'm guessing it would be cheaper and easier to build a single box with two different CPUs in it - one from IBM and one from AMD/Intel. Seems like Apple did this a while ago...