Slashdot Mirror
A History of PowerPC
A reader writes: "There's a article about chipmaking at IBM up at DeveloperWorks. While IBM-centric, it talks a lot about the PowerPC, but really dwells on the common ancestory of IBM 801" Interesting article, especially for people interested in chips and chip design.
IBM Also announced a ton of new PPC information and tech today at an event in new york. Opening up the ISA to third parties including Sony.
I hope you die painfully and alone.
They also have a very good article about the PowerPC's three instruction levels and how to use implementation-specific deviations, while code stays compatible. This introduction to the PowerPC application-level programming model will give you an overview of the instruction set, important registers, and other details necessary for developing reliable, high performing PowerPC applications and maintaining code compatibility among processors.
PPC is big endian, which is normal.
X86 is little endian, which is chunked-up and backwards.
Example:
View the stored number 0x12345678.
Big endian: 12 34 56 78
Little endian: 78 56 34 12
Clear as mud?
Motorola has a nice overview graphic - you can also checkout a more generalized article at The Star Online.
P.S. Does anyone know why Windows has never been adapted to run under PPC?
Errm, actually, it WAS. See for instance
http://home1.gte.net/res008nh/nt/ppc/default.htm
It's actually closer to Intel's Vanderpool technology that allows you to partition the cpu through firmware.
Example: Windows is running on slice 1, BSD on slice 2, and Linux on slice 3.
BSD gets a kernel panic and crashes, the slice is restarted without affecting the remaining running OS's. It's, for the lack of a better term, Hyperthreading for the whole computer.
I hope you die painfully and alone.
Or, you could always settle for an RS/6000.
RS/6000
Or, a Power-based IBM workstation,
Workstation
When I was working on the embedded IBM PowerPCs (400 series), we used Verilog primarily...though there were a few VHDL hold-outs.
Thinking of starting a business in Minnesota? Me too! mnsmall.biz
Big-endian appeals to people because they learned to do their base-10 arithmetic in big-endian fashion. The most significant digit is the first one encountered. It's habit.
// at address 1000, say // fetch from 1000 to get 00001234 // fetch from 1000 + 2 to get 1234
// at address 1000, say // fetch from 1000 // fetch from 1000
Little-endian has some nice hardware properties, because it isn't necessary to change the address due to the size of the operand.
Big Endian:
uint32 src = 0x00001234;
uint32 dst1 = src;
uint16 dst2 = src;
Little Endian:
uint32 src = 0x00001234;
uint32 dst1 = src;
uint16 dst2 = src;
The processor doesn't have to modify register values and funk around with shifting the data bus to perform different read and write sizes with a little-endian design. Expanding the data to 64 bits has no effect on existing code, whereas the big-endian case will have to change all the pointer values.
To me, this seems less "chunked up" than big endian storage, where you have to jump back and forth to pick out pieces.
In any event, it seems unnecessary to use prejudicial language like "normal" and "chunked up". It's just another way of writing digits in an integer. Any competent programmer should be able to deal with both representations with equal facility.
Being unable to deal with little-endian representation is like being unable to read hexadecimal and insisting all numbers be in base-10 only. (Dotted-decimal IP numbers, anyone?)
Big-endian has one big practical advantage other than casual programmer convenience. Many major network protocols (TCP/IP, Ethernet) define the network byte order as big-endian.
Yes
What Intel did was include RISC architecture in around the x86 instruction set to create the pentium pro, pentium II, III, etc. Otherwise they would have been killed.
Infact IBM was correct. Cisc was dying. THe pentium1 could not compete agaisnt the powerpc unless it had a very high clock speed. All chips today are either pure risc or a hybrid cisc/risc like todays Althons/Pentium's. The exception is the nasty Itanium which is not doing too well
http://saveie6.com/
Yeah. It's a good thing that the processors in the POWER line has unbelievable branch prediction logic. So, for example, the branch prediction rate for the POWER 4 is in the mid to high 90 percentile for most workloads (as high as 98%, IIRC) In fact, quite a large number of transitors are dedicated to this very topic, which allows the processor to do a pretty good job of achieving something close to it's theoretical IPC.
Although, it should be noted that the pipeline depth for the POWER4 is just 15 stages (as opposed to the P4 which has, IIRC, 28 stages), so while a branch misprediction is quite bad, it's not as bad as some architectures. My understanding is that, in order to achieve that 200 IPC number, the POWER4 is just a very wide superscalar architecture, so it simply reorders and executes a lot of instructions at once. Plus, that number may in fact be 200 micro-ops per second, as opposed to real "instructions" (although, that's just speculation on my part... it's been quite a while since I read up on the POWER4), as the POWER4 has what they term a "cracking" stage, similar to most Intel processors, where the opcodes are broken down into smaller micro-ops for execution.
When my buddy first told me about this exciting new RISC idea one of the design goals was each instruction was to take a single instruction cycle to execute. Isn't this completely contrary to a deep pipeline?
.
No, in fact pipelining is central to the entire concept of RISC.
In traditional CISC there was no pipelining and operations could take anywhere from 2-n cycles to complete -- at the very least you would have to fetch the instruction (1 cycle) and decode the instruction (1 cycle; no, you can't decode it at the same time you fetch it -- you must wait 1 cycle for the address lines to settle, otherwise you cannot be sure of what you're actually reading). If it's a NOOP, there's no operation, but otherwise it takes 1+ cycles to actually execute -- not all operators ran in the same amount of time. If it needs data then you'd need to decode the address (1 cycle) and fetch (1 cycle -- if you're lucky). Given that some operators took multiple operands you can rinse and repeat the decode/fetch several times. Oh, and don't forget about the decode/store for the result. So, add all that up and you could expect an average instruction to run in no less than 7-9 cycles (fetch, decode, fetch, decode, execute, decode, store). And that's all presuming that you have a memory architecture that can actually produce instructions or data in a single clock cycle.
In RISC you pipeline all of that stuff and reduce the complexity of the instructions so that (optimally) you are executing 1 instruction/cycle as long as the pipelines are full. You have separate modules doing the decodes, fetches, stores, etc. (and in deep-pipeline architectures, like the P4, these steps are broken up even more). This lets you pump the hell out of the clockrate since there's less for each stage of the pipeline to actually do.
Modern CPUs have multiple everything -- multiple decoders, fetchers, execution units, etc. so it's actually possible to execute >1 cycle/cycle. Of course, the danger to the pipelining is that if you branch (like when a loop runs out or an if-then-else case) then all those instructions you've been decoding go out the window and you have to start all over from wherever the program is now executing (this is called a pipeline stall and is very costly; once you consider the memory delays it can cost hundreds of cycles). Branch prediction is used to try and mitigate this risk -- generally by executing both branches at the same time and only keeping the one that turns out to be valid.
Was I wrong to laugh when I heard hardware manufacturers claim, "sure, we make a CISC, but it has RISC-like elements
Yes, because neither one exists anymore. CISC absorbed useful bits from RISC (like cache and pipelining) and RISC realized there was more to life than ADD/MUL/SHIFT/ROTATE (oversimplification of course). The PowerPC is allegedly a RISC chip, but go check on how many operators it actually has. And note that not all of them execute in one cycle. x86 is allegedly CISC, but, well... read on.
how wide are the Pentium 4 and Athlon microcode?
The x86 ISA has varying width. It's one of the many black marks against it. Of course, in reality, the word "microcode" isn't really applicable to most CPUs nowadays -- at least not for commonly used instructions. And to further muddy the picture both AMD and Intel don't actually execute x86 ISA. Instead there's a translation layer that converts x86 into a much more RISC-y internal ISA that's conducive to running at more than a few megahertz. AFAIK, the internal language is highly guarded by both companies.
If I am not mistaken the Transmeta was a very wide instruction word. And if I am not mistaken, doesn't that make it the opposite of a RISC?
Transmeta and Intel's Itanium use VLIW (very large instruction word) computing, which is supposed to make the hardware capable of executing multiple dependant or independant operations in one cycle. It does so by putting the onus on the compiler
One more big advantage of the big-endian byte order is that 64-bit big-endian CPUs can do string comparisons 8 bytes at a time. This is a big advantage where the length of the strings is known (Java strings, Pascal strings, burrows-wheeler transform for data compression) and still an advantage for null-terminated strings.
I'm not aware of any such performance advantages for the little-endian byte order.
The main advantage of little-endian byte order is ease of modifying code written in assembly or raw opcodes if you later decide to change your design and go with larger or smaller data fields. The main uses for assembly programming are very low-level kernel programming (generally the most stable part of the kernel code base) and performace enhancement of small snippets of code that have been well tested and profiled and are unlikely to change a lot.
I agree that an decent programmer should be able to deal with either endianess, but the advantages of the little-endian byte order seem to be becoming less and less relevant.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.