Motorola G5 - 2Ghz 64bit
Nerdkiller writes "
An article appeared on ZDnet with some information on the G5 chip expected in 2 years. It will be competing with the Intel Merced which is expected out around the same time. A full 64 bit 2 Ghz processor. The Intel Merced will be able to support 64 bit processing, however it must be run under emulation for 32bit code. The G5 requires no change in current code with exception to some low level OS stuff.
"
References, please? I've seen nothing to indicate that any PowerPC chip that actually made it out the door had x86 instruction support; all I've heard were claims that a 615 chip was being developed that would run x86 code, and, if I remember correctly, claims that Exponential's 704 would have x86 support.
The PowerPC architecture is derived from IBM's POWER architecture (yeah, the same POWER architecture to which you referred with "IBM Power"), which first showed up in the RS/6000's, with assorted changes, e.g. single-precision floating-point and multiply and divide instructions that don't go through an MQ register. Please explain how a POWER derivative is "a RISCified mixture of m68k and x86, just a little cleaned up".
No. Check out the PowerPC Programming Environments Manuals section of this page, and the (PDF) documents it links to. The instructions are 32 bits; the addresses and data they manipulate can be 64-bit in 64-bit PowerPC processors.
And as others stated in replies to your post, that's not the case; the instructions are 32-bit in the 64-bit PowerPC architecture.
You can address more memory without 64-bit instructions; you might just have to do more work to synthesize addresses, and if the address is just a pointer you've been handed, or a pointer in a data structure, you don't have to synthesize the address.
I'd include in the PowerPC family any chip that implements the PowerPC instruction set architecture, and this press release says:
(although it's not entirely clear how the instruction set "provides the ability for thousands of POWER3 microprocessors to be combined into a single, unified computing unit"). The RIOS chipset in the first RS/6000's implemented the POWER architecture, which had a few things PowerPC doesn't and didn't have somethings PowerPC does (but there is a common subset of the instruction set), as did the RSC (which I'm told stood for "RIOS Single-Chip", and which I've heard was modified to make the 601), and the POWER2 chipset implemented the POWER2 architecture (added a few things to POWER, but also lacked some stuff PowerPC had); I guess POWER3 finally picks up all of PowerPC.
However, it, like the RS64 in some other RS/6000 models, and the models used in the AS/400's (one of which is the RS64 III, as per this paper, presumably with "tags-active" mode turned on in the AS/400's and off in the RS/6000's), are proprietary to IBM, unlike the 4xx, 6xx, and 7xx chips, which IBM Microelectronics sells.
Or 1 year for a 64 bit Merced
Or buy a 64 bit alpha today
Decisions Decisions...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Not if, say, a 32-bit arithmetic instruction uses an entire ALU, as I think is the case on most 64-bit machines; I don't know if there are any that'd split a 64-bit ALU up into two 32-bit ALUs and run two 32-bit instructions through them (especially given that registers generally aren't split that way, either).
The SIMD "multimedia" instructions that most general-purpose instruction set architectures have picked up may process multiple less-than-full-word-size units in one ALU and in one instruction, but that's one instruction, not two.
What chips that implement the 64-bit version of the PowerPC instruction set does Apple use? (Chips that implement the 32-bit version of the instruction set, but that have a 64-bit bus interface, don't count as "64-bit chips" here.)
No, it's 32-bit - it implements the 32-bit version of the PowerPC, without the AltiVec instructions, and according to this page at Motorola's Web site it has only a 64-bit bus interface for data.
Perhaps you're thinking of the 7400, which has the AltiVec instructions, but it also has only a 64-bit data bus, and only implements the 32-bit version of the core PowerPC architecture (note that the page for the 7400 links to the 32-bit version of the "Programming Environments Manual"), even if it also implements the AltiVec instructions that work on 128-bit registers.
Um, I don't want to be the one complaining about new cool (hot?) processors, but to start hyping something we'll see in two years sounds a little bit extreme. I mean, that's almost the way Wintel do business, right?
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Every two years the speed of software halves.
So all this stuff makes not a damn bit of difference.
Now look - you've gone and made me grumpy.
Now if we could just get some additional, good, free, open-source operating systems ported to run on this chip, it would be even better.
LinuxPPC is there, and good; I've been very impressed by what it can do. But wouldn't we all like to see FreeBSD, or other Linux distributions ported to run (and run well) on PPC chips? And even better, now on the G5. I can just see the performance of a full 64-bit native OS running on that chip... *drool*
But then again, we have plenty of time before they come out to do the work!
---
Tim Wilde
Gimme 42 daemons!
Why was this posted under the Apple heading? Slashdot needs a seperate topic for PowerPC related articles.
Posted by Nr9:
Cuz its no emulation.
software or hardware
no decoding.
it is the same instruction set
64 bit PowerPC is designed with binary compatibility with 32 bit powerpc.
intel 686 CPUs run them natively cuz thats the only ISA they can run.
My guess would be that a 32 bit version would be cheaper and useful for the embedded OSs mentioned in the article. They would need to be tweaked to work on the 64 bit chips anyway. PowerPC's biggest market is in embedded devices, after all.
There seems to be some misunderstanding on the PowerPC archetecture.
The PowerPC architecture is a instruction set definition written by Apple/IBM. It specifies a set of 32bit and 64bit instructions that PowerPC implementations must follow. 32bit implementations do not need to implement the 64bit instructions. (they are specified as optional in the specifications)
Under PowerPC, 32bit and 64bit code can be executed at the same time (no mode switching like x86).
All current PowerPC chips are only 32bit implemenations. It appears that the G5 will be the first 64bit PowerPC implementation.
It makes no sense ditching the 32 bit instructions because supporting them is
1) Not very expensive in the PowerPC archiecture (unlike Merced)
2) You can write faster programs by mixing the faster 32 bit instructions with the slower 64 bit instructions when needed.
3) Allows people to run existing and 64bit software transparently. (imagine 64bit modules on a 32bit database server)
Yes, AMD K6 has a RISC core underneath, and instructions are translated to what AMD calls the "R-ops", if my memory serves me right. AMD K6 has its roots in the NexGen Nx686, which was the successor to Nx586, the first x86 clone on the market which could compete with Pentium's performance.(it was a nice processor, but it flopped for several other reasons) The reason I'm telling this is that Nx586 had an assembler of its own, and theoretically could be programmed using its own RISC assembly language, bypassing the full x86 compatibility layer altogether.
Anything derived from the P6 core (Celeron, Pentium Pro, Pentium II/III) behaves pretty much the same way-x86 instructions are converted to RISC-like shorter ops, and executed by the core. I believe Intel calls these "micro-ops" rather than "R-ops" like AMD does-hence avoiding the "R-word" they don't like to use much...
Zigbee Central: A Zigbee weblog
The difference between an ``embedded processor'' and a ``general purpose processor'' is as much marketing as anything else
At one point, the StrongARM was being strongly promoted as a Network Computer (aka ``X-Terminal'') device. Note the announcement of 1997 of the Digital Network Appliance Design.
And note that it is the processor used in the Rebel/Sidewinder that Corel Computers used to hawk.
The point of all of this is that the CPU is clearly not so ``embedded'' that it would be inherently useless in a ``desktop'' role.
It ought to have been possible to build motherboards integrating a CPU, video chipset, and Ethernet that could retail for less than $150, and this could have brought us $300 computers a year or so ago, and provided slick little boxes to velcro to the sides of 17" monitors.
If I could have bought a StrongARM motherboard for $100, I probably would have built a machine by now.
But no motherboard leads to no systems. Note that exactly the same reasoning may be used with MIPS...
If you're not part of the solution, you're part of the precipitate.
They talk about Apple working on 266MHz SDRAM implementations, probably for future G4s and in anticipation of G5s.
Someone else mentioned that Alpha gets it's 200MHz/250MHz bus by multiplexing a 75MHz 256bit wide bus. I can imagine 8 64bit memory buses running at 100MHz, which is can be worked with as a single 800MHz 64bit bus. But that's a darned high wire count. More likely you'd get 8 32bit buses at 100MHz or even at 133MHz.
Excuse me if I don't make much sense, I'm speculating here =)
-AS
-AS
*Pikachu*
So DEC Alphas and AMDs use a 200MHz FSB, or whatever they call it, and Intel/VIA/etc will be using 133MHz FSB as well.
I'm not sure how the RAM and bus speed correlates, but Apple seems to be actively researching 266MHz RAM, most likely in anticipation of G5s. It has also been documented that PC133 outperforms RAMBUS, so PC266 may be what you're looking for.
Look at http://www.macosrumors.com/8-99.html under the 8/16 update.
-AS
-AS
*Pikachu*
604e should be enough for everybody.
---
Have a Sloppy day!
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I'd actually believe that Motorola has no problem selling it's PPC and 68k CPUs in embedded systems, and it was only recently with the advent of $600 systems that the popularity of architectures and CPUs becomes an issue.
I mean Motorola sells a 68k CPU with every Palm and Visor out there. If they have an embedded processor in a cell phone, I'd think they would be selling more cell phones than PCs. Yes, PPC CPUs in computers would be more popular, but it wasn't necessarily the most profitable or intelligent thing to do; it would require that Motorola(or someone else) support AGP chipsets, PCI chipsets, memory chipsets, etc, for a single system to make a profit.
If you haven't noticed, Apple does this all by themselves. If you search IBM's website for PowerPC, you'll also see that they had PowerPC systems for sale since 1996 or something, but at $6,000 costs.
I can't imagine anyone just picking up the PowerPC platform until LinuxPPC stabilizes and matures, because I don't think anyone can compete with Apple on a design standpoint and no one can compete with Intel on a price standpoint.
Apple may be our only hope here =(
-AS
-AS
*Pikachu*
I forgot the url to the roadmap:m ap.pdf
http://www.mot.com/SPS/PowerPC/overview/newroad
No, not really. Despite the recent dabblings with the Alpha, the focus of the FreeBSD group has always been on getting it to work well on Intel hardware. Look to the other BSDs for PowerPC support:
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Although the x83 family is not a very efficient design because of the enormous amount of resources occupied by backward compatibility, it just isn't bad enough to allow competition to overcome intel's main advantages: compatibility and price/performance ratio (and perhaps FUD-proofness).
Throughout the past decade and a half, many competitors have made products that were superior to intel's in every way but compatibility and price/performance ratio. None of them ever crawled out of their niche market.
Now this Motorola announcement not only promises to beat intel at both counts, but also to do this by an incredibly wide range
When something sounds too good to be true...
Maybe the G5 will finally make the MacOS run as fast as linux and some windows machines. Macintoshes have always had great chips, but the software's overhead has been killing the speed and making most people think that Macs are slow and a joke. May the G5 prove the power that Apple can wield.
Dan
If you look at the various architectures on which Linux runs, there are three varieties, in general:
There are a boatload of IA-32-based Linux systems.
There are a fair number of such systems.
PPC is hard to assess; it is easy to buy a PPC Mac from Apple, but fairly difficult to buy just a motherboard.
If PPC motherboards were readily available, PPC would be vastly more popular...
If you're not part of the solution, you're part of the precipitate.
I'm not sure how fast a 2 GHz CPU will seem unless we start seeing some really fast RAM and BUSes. Right now the fastest bus I've seen is 133 MHz, and the fastest large scale RAM on the horizon is still RAMBUS. Neither of these will allow a 2 GHz processor to run anywhere near it's full potential. Even with lots of cache you would only approach some upper bound that wouldn't be anywhere as high as 2GHz.
There needs to be some other advances, other then jacking up the CPU speed, before processors like this become useful. Maybe it'll be a new RAM or BUS design (RF anyone?), or a new way of dealing with code internal to the CPU to make memory more effecient then using it for cache. Which ever it's time to start looking at them.
The G4, with the AltiVec additions, makes a fantastic DSP development platform. In case you didn't realize, Altivec supposedly completes a multiply-accumulate every clock cycle minumum (It can actually do 4 per clock cycle because of the SIMD architecture). Doing a single-cycle MAC is almost the definition of a DSP. But to really take good advantage of the DSP aspect, you need an honest-to-goodness RTOS.
Now last I looked, TI's 'C6x architecture was headed that way with speed and scalability, but no one is ever going to write or port a general purpose OS (ie, Linux, Windoze, MacOS, Be) for/to that chip.
The G4, however, already runs at least MacOS and Linux. Unfortunately, neither of these are real-time systems. (Has RTLinux been ported to PPC? A great project, if not!) And it's too bad that the situation with Be prevents them from taking advantage of this great chip.
Anyway, I guess my point is just that having a hosted (versus embedded) DSP development system would be just the coolest, and that the G4 makes this possible for wont of a RTOS.
I have not seen anything yet that state explicitly that the G5 will have AltiVec on it. God, I hope so, though.
(drool-mode off)
As long as people don't whine and bitch about not being able to upgrade their already-too-fast-for-their-own-good G4 machines to G5s, that is.
:-]
Hey, anybody want to sell me their "useless" "non-upgradable" blue and white G3? Since the machine is obviously so out-of-date and nonexpandable, I'll give you $500 for it.
Now, as for the G5, provided it supports the same kind of multiprocessor architecture as the G4, I can only guess at what this could mean for applications like Photoshop, Final Cut Pro, After Effects, and Quake. "Omigod!" would be my guess, though.
I use Macs for work, Linux for education, and Windows for cardplaying.
I am more interested in faster system overall then cpu. Except for computation, 2Gig CPU is useless if there is only a 200Mhz bus. I hope that the bus specifications are atleast 1GigHz by then, with faster memory. If they become affordable and graphics and internet connections are fast enough then maybe we'll finally move to video conferencing to the average user.
Only 'flamers' flame!
I'm not sure that running 32bit code natively would be advantagious for the IA-64. I think that it is time to say goodnight to x86. It is tied up in so much cruft that it is choking the potential of newer software.
In support of this argument I invoke the memory of the PPro, which sucked when running both 16 and 32 bit code. (Okay, obviously not at the exact same time, in fact switching back an forth is what caused the slow-down.)
Wouldn't you rather run Linux on a box optimized for 64bit operation?
-P