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.
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.
"Finally, the Fishkill operation is so hip that the server room runs exclusively on Linux."
I didn't think it was possible to use the words "Fishkill" and "hip" in the same sentence with a straight face.
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?
Is its revolutionary three level cache architecture, utilising a 3-way 7 set-transitive cache structure, which gives performance equivalent to a 2-level traditional x86 style cache for more content addressable memory. Each processor has a direct triple-beat burstless fly-by cache gate interface capable of fourteen sequential memory write cycles, including read/write-back and speculative write-thru on both the instruction and data caches. Instruction post-fetch, get-post, roll-forward and cipher3 registers further enhance instruction cache design, and integrated bus snooping guarantees cache coherency on all power PC devices with software intervention. Special cache control and instructions were necessary to control this revolutionary design, such as 'sync', which flushes the cache, and the ever-popular 'exeio' memory fence-case instruction, named after the line in the popular nursery rhyme.
Or, you could always settle for an RS/6000.
RS/6000
Or, a Power-based IBM workstation,
Workstation
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.
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
So, you're reading in an array of integers, which are now 64 bit vs 32 bit and no code change is needed?
Programs NEED to know the size of the data they're working with. Simply pulling data from an address without caring for it's size is a recipee for disaster!
"That's so plausible, I can't believe it!" - Leela