Slashdot Mirror
IBM to Release 64-Bit, 1.8GHz Processor in 2003
Professor_Quail writes "A Forbes article supposed to be released tomorrow gives some details about the new PowerPC processor that IBM and Apple have been working together on; the chip is slated to be introduced at the end of next year. The introduction of this chip should put to rest any speculation that Apple is moving to an Intel platform."
Many people doing CAD, circuit simulation, or editing large images need more than 4 gigs of ram now. 4 gigs is all you can get with 32 bits. On intel, using evil segments, you can use 36 bit. Win2k Enterprise does this...
Also, do not forget about Moore's Law. CPU's keep getting faster. Problem is hard disks are not. So more RAM for caching will be the solution.
Checking pricewatch I see that 2 gig pc100 dimms are less than $500 each.
The law is a weapon of the government, not a protection for the likes of you. Surely you understand that.
Hrm, intel/AMD will be at what then, 4ghz? :P
:P
64 bit is nice, but I doubt the chip will be more powerful then an x86 chip at twice speed.
Keep in mind that 64 bit chips do not simply work at twice the speed that 32 bit chips do, unless they are working on 64 bit integer numbers (in which case, they will actually work faster then 2x the speed of a 32 bit chip). Unlike the move from 16 bit to 32 bit, where 16 bit integers (either -32k to 32k or 0 64k values) were to small for lots of work, especially work with memory addresses on machines with >64k of ram
Nowadays, most CPUs (including x86) have 64bit floating point coprocessors to handle most mathematical code, so 64bit CPUs won't give you much of an improvement there either.
on machines with >4gb of ram, it will be a big improvement, but with advances in virtual memory it won't be as much of an advance, since programs can work in their own 4gig memory space on systems with more then 4 gigs of ram, and the virtual memory hardware can use more then 32 bits for mapping addresses.
Anyone, one only has to look at the difference between a Nintendo 64 (64 bit CPU) and a PC (32bit CPU) to see that CPU speed (and graphics accelerators!) has a much greater impact on performance then the bit width of the CPU.
autopr0n is like, down and stuff.
This is just confirmation of threads folks on appleinsider.com and other mac websites have been following for quite some time.
Based on all the rumor and innuendo that is swirling around for the last 3 months, it is highly likely that this is indeed the chip Apple will be migrating to, and that it will be out at some point in 2003...probably the fall, though opinions on that vary.
At the Microprocessor Forum on the 15th (Tuesday) IBM will be giving a long talk on the nature of this chip, and that's the talk Mac enthusiasts have been waiting for to see what's what with the particulars...so stay tund for that to receive more information than the Forbes article had.
There are NO 64bit consumer processors currently available. I'm typing this on a dual Athlon MP 2200+, and it is most definately 32bit. The Itanium is 64bit, and the Claw/Sledgehammer processors will be, but neither is currently available for consumer use.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Preliminary ratings for a 2-core AMD Opteron are 8100+. That would indicate a chip running at about 2.5 GHz. And it will run all x86 code, including SSE2. No Altivec, but I'm willing to bet it'll still blow the G5 away.
XServe
NetInfo connection failed for server 127.0.0.1/local
I've seen several. Try here for starters.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
36 != 64, but just because CPUs with Intel's PAE can address 64GB of RAM (2^36 = 64GB) does not make them 36-bit processors. They can only actually address 4GB at any one time, which is why any single process can use no more than 4GB of RAM (actually, 3.5GB with Linux and 3GB with Windows)
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
Where can you get a PC comparable to the iMac for $650? Or comparable to the iBook for $600? The price difference is not as much as you think, and can easily be made up for by ease of maintenance, lack of viruses and spyware, and better security.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
This is true, but show me a motherboard for less than $500 with more than 4 DIMM slots. Probably going to need another memory controller, or a bridge chip (with some latency).
Even the 1 giggers are much cheaper, but 4 of them does not present an addressing issue.
Of course the 2 giggers are probably double sided, and you probably can not run three of them anyway..
The law is a weapon of the government, not a protection for the likes of you. Surely you understand that.
It's quite simple, really. It's all about getting easy access to memory. We're getting awfully close to physical limits of 32-bit addressing of RAM (4 Gb, though x86 gets around this slightly with segments in server chips). It's not uncommon for a graphic designer (and soon, maybe Joe America with home movies and video editing software) to drop 2GB into a desktop/workstation machine. We'll be hitting that memory limit awfully soon, and with 4GB of ram under a grand, 64-bit addressing starts to look necessary.
At least, not necessarily.
Just because these new chips will be 64-bit does not mean they will be fast. 64-bit processors require more cache and main memory (because all of the memory pointers are 64-bits rather than 32) and cannot necessarily do most common computations faster.
Say you are doing a multiply operation. Very common. The numbers are, say, 500,000 and 42. Both of those numbers are occupying a full 64-bit register, even though they could be stored in 32-bit registers easily. The multiply operation still takes the same amound of time to complete, because the register size doesn't matter unless the numbers cannot fit.
Now, software doing math with numbers greater than ~4.3 billion (what will fit in a 32-bit register) will be able to perform those calculations more quickly, but rarely are such large numbers used. Certain operations, such as encryption and advanced mathematics, will be able to calculate up to 4 times faster, but again, this will not matter much for most applications (though perhaps folding@home and SETI@home will see a speed up).
Additionally, the increased code size caused by the larger memory pointers (about 5%) can actually slow code, because the cache hit rate will drop by that same 5%.
The Opteron processor's early benchmarks (which show that it simply kicks ass) are misleading because the Opteron has other tweaks to improve speed: Twice as many registers, an integrated low-latency memory controller, probably a better branch prediction unit, and a few other minor tweaks. The speed increase is not caused by the larger registers.
That said, IBM makes some very nice processors, and if they incorporate many of their ideas into this new CPU, Apple will hopefully be very competitive. (though those 1.8GHz better have a great IPC to compete with the Clawhammer and 3+GHz P4!)
64-bits is very nice in that Apples can now address >4GB RAM per process, but few people are finding the 4GB memory barrier to be all that restrictive, less professionals working on very high-end tasks such as gargantuan 3D models with staggeringly huge textures.
I'm all for Apple every since OSX was released, but let's not succumb to the 64-bit myth anymore than we should the MHz myth.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
Sorry but PPC is already 64b. The 1.8Ghz is the new part.
Uh... the Mac's powerpc chips are 32 bit, but you could run Linux on it. :-)
The melting point of steel is about 1500C.
The Athlon XP uses 12% more power than the P4, and hence produces 12% more heat. The problem with Athlons is that (unlike the P4) they don't include an integrated head spreader, so all heat is concentrated on a much smaller area. The Hammer / Opteron does have an IHS, and will probably dissipate between 60 and 80 Watts of heat. That is quite good for a 2.5 GHz, 64-bit chip (compare with 135 Watts for Intel's Itanium 2).
Of course Pentium 4s totally smoke G4s. A Pentium 4 2.53 is three times faster than a G4 867 according to specint2000/specfp2000. Amazingly, that three times performance difference is paired with a three times megahertz difference.
System specint2000/specfp2000
AMD Athlon XP 2100+ 1733
720/613
Intel Pentium III 1133
461/320
Intel Pentium 4 2533
882/861
Intel Itanium 800
314/645
Intel Itanium 2 1000
~700/~1350
IBM POWER4 1300
804/1202
Sun UltraSPARC III 1050
537/701
Apple G4 867
257/154
What were you saying about the megahertz myth? It doesn't apply to the slow G4?
-Kevin
The Linux Agenda VR3, to name just one example, is a PDA that uses a "64bit consumer processor", NEC's VR41xx. That's a MIPS64 CPU, although the firmware
runs it in 32bit mode. The same processor is used in many MIPS-based WindowsCE PDAs, like the Casio Cassiopeia. Other 64bit consumer processors are Toshiba's TX-49 (another MIPS64) and SuperH's new
SH-5, which has yet to ship.
here's the cheapest POWER4 system i can find - $12,495. everybody bitches about how much macs cost, but i doubt it's going to be more than $4000-4500 for one with the new PowerPC. do i even have to make a point?
Facts do not cease to exist because they are ignored. - Aldous Huxley
I think its time Apple start calling anything based on the power PC architecture twice its clock speed, and anyhting thats both powerPC and 64 bits at 4 times its clock speed. After all, the processor does twice as much as a 32 bit processor in a given clock.
No it does not. Do you think bits are some sort of speed measurement? Like, "bits per second"? 64-bit means the chip has 64-bit registers. Basically what that means is it can work with larger numbers and - more importantly - larger memory addresses. It will take exactly the same time as a 32-bit chip to do a specific operation (ex., add two bytes, jump to a new address in a program, etc.). The speed at which operations are done depends on the chip's design and clock speed.
So calling this new PowerPC that runs at "1.8GHz" a "7.4GHz PowerPC" is just as legitimate as Intel calling their pentiums 2.8GHz, etc. (Cause they don't really actually run at 2.8GHz. That's just one clock rate that exists at some point on the processor. Processor clocking is far more complicated than that.)
What? Of course they run at 2.8 GHz. That's the clock speed; they can't help but run at 2.8 GHz. Even if they have absolutely nothing to do, they still go through 2.8 billion cycles each second. There are clockless chips (that work at a variable speed), but the P4 is not one of them.
RMN
~~~
The first advantage is the ability to have a 64-bit address space for pointers. This allows for extensibility to address considerably more physical memory (over 16,000,000,000 GBytes). Of course, no system requires that much memory, but the added virtual space is very handy, and systems do currently buck into the 32-bit limit of 4GB. The additional virtual memory space is handy in kernel development where everything shares the same memory mapping. The spectrum of the 64-bit address space is large enough to give everyone plenty of room to play with. Makes code much simpler.
Having 64-bit pointers actually has a draw back in that the amount of memory required to store a pointer is now 8 bytes instead of 4. For some code this increases memory utilization considerably and equally increases memory bandwidth requirements. Because of this, most (except alpha) 64-bit cpus will allow you to use 32-bit addressing if you are using less than 4 MB of memory.
Memory is only one feature of 64-bit processing. 64-bit arithmetic is very useful, especially when processing lots of data. However, software must be written generally to take advantage of this feature. When working with large numbers which require more than 32-bits to express, 64-bit CPU's have a huge advantage over their 32-bit cousins. Cryptographic, compression, multi-media and parity generation applications bennifit greatly from 64-bit operations.
Someone you trust is one of us.
Did you know that a P4 takes 20 clock cycles to perform a multiply?
:) )
Did you know that you are an idiot? the p4 has a 20 stage pipeline, which means the process of excecuting instructions is seperated into 20 peices, and the hardware used to do each one of those pecies works on part of a diffrent instruction at the same time. So while a multiply might take 20 clock cycles to come out of the other side of the CPU, if all you have is a program with one multiply instruction followed by a hlt or something.
Most programs, of course, have more then one instruction. With a 20 stage pipline one instruction takes 20 cycles to run, but you can also perform 19 other instructions along with it... depending on how many excicution units you have along with it.
The p4 has two ALUs, each running at twice the clock speed of the rest of the CPU. (in contrast, the athlon has 4 regular speed ALUs). So in actualy, you'd be able to run 80 or so instructions in that 20 clock cycles.
Integer multiplies are actualy performed by the floating point system, IIRC, rather then by the ALU, so they won't be as fast as addition and subtraction.
The chip IBM is making is a mips based chip, and takes fewer cycles to perform all its instructions. It also has a _ton_ more registers, which means you can perform significant operations without going to or from memory.
IBM is not making a mips chip, moron. They are making a Power PC chip. the p4 has only 8 general purpose 32 bit registers, but in addition has 8 80 bit floating point registers, 8 64bit integer SIMD registers and 8 128 bit floating point/vector SMID registers.
MIPS only has 32 general purpose registers, and although they can be used however you want, several of them are 'reserved' for the stack, and things like that. Also the first register is always zero, and you can't store anything in it. So in actuality, MIPS chips have fewer registers then Intel chips. PPC chips on the other hand do actually have more registers then Intel chips though, with 32 general-purpose registers, 32 floating (64 bit?) point registers, and 32 128 bit vector SMID registers.
This doesn't really help your argument, though: Reading or writing a number to memory is about 100 times slower than an arithmatic instruction.
it's true that reading from memory takes a long time, and that's why modern CPUs don't do it very often. They use these things called "caches" you know? The vast, vast majority of memory access doesn't actually need to hit ram.
But to use those coprocessors, you have to go into modes like mmx. And bolted on extra instructions like mmx have restrictions on them, like not being to do mmx and floating point math at the same time.
No, I was talking about using floating point math for integers larger then 32 bits, rather then splitting 64 bit ints up into 32 bit chunks and adding them with carry (which takes more then two instructions). MMX doesn't allow 64bit int math, as far as I know, but rather allows you to sacrifice floating-point math for accelerated 8, 16, and 32 bit math. It's always interesting in that Mac fans seem to think that Intel chips suddenly lost the ability to do integer math and floating point math at the same time when they gained MMX.
Anyway, that's really beside the point due to the fact that, as you can see, MMX no longer uses the floating-point registers.
For the future, 64-bit is the way to go, and x86 is not. I think one of these IBM processors will be the ideal linux machine. (It'll be low power too, so I won't need a hairdrier-loud fan like I do with my athlon
since when are those separate things?
Might not hurt to learn a thing or two about how computers work before opening your mouth.
autopr0n is like, down and stuff.
Everything about IBM's Power4 processor is amazing. Amazing technology, amazing size (680 million transistors), amazing power requirements, amazing performance. And it's amazing that anything so complex can work at all. This beast has 5,200 pins on the package and consumes 500 watts (that's right, half a kilowatt) of power. Actually, Power4 is more than a processor, it's an entire neighborhood of processors. It's sold as a module comprising two processor cores per die, and four die per module, making eight 64-bit processors and 680 million transistors in one unit. Each individual die contains 174 millions transistors and measures a sun-blocking 400 mm2 in IBM's 0.18-micron 7-layer copper process.
:P
8 CPUs stuck together, 1.33 times faster then a p4. And with only 12.36 times as many transistors! (And just 10 times as many interface pins, and power use!)
If IBM's 'scalling down' is more then by more then 25%, it'll be slower then intel. If it's by less then 95%, it'll be more expensive
autopr0n is like, down and stuff.
Heh, some of IBM's work in PowerPC-related design already does this. The Power4 chip, which is used in the pSeries (RS/6000+) and iSeries (AS/400+) hosts 5 different architectures in the core, 2 of these are 32-bit (32-bit Power and PowerPC) and 3 of these are 64-bit (64-bit Power, PowerPC, and "Amazon"). If they put their mind to it (but I doubt they would), it wouldn't be hard.
--rdean
p.s.--"Amazon" was a codename for the chip architecture that was going to merge the AS/400 and RS/6000 lines in the early 90s. The project was scrapped, but the resulting instruction set was used in the AS/400 line during its migration from CISC to RISC architecture.
actually, CISC instructions generally require mote than ome clock cycle to complete, so although you may need more instructions on RISC, you will end up using a similar number of clock cycles. The advantage comes in the form of pipelining, which is next to impossible with CISC. A RISC pipeline, particularly one utilizing Tomasulo's algorithm to unroll loops and execute instructions out of order will be much much faster simply due to the fact that several instructions are in the pipeline at any given time. This is why even the once CISC x86 is actually RISC underneath. Every x86 instruction is translated to a stream of RISC instructions which are then executed by the core. The Itanium has finally gotten rid of this kludge, which is why it is ISA incompatible with x86. Sadly Intel has chosen to forgo the out of execution hardware and is relying on compilers to do that work. But who knows - theoretically they should achieve similar speed ups to Tomasulo based hardware.
Uhm you know, Linux is available for 64-bit processors, at least for the pSeries boxes (PPC - PowerPC proc). http://www.penguinppc.org/ && (http://www.linuxppc.org/ || http://www.linuxppc.com/). SuSE has a distro for this, I believe. Not so sure about RedHat - although I think their 7.1 release did have a port for PPC.
Sure there are. Sun Ultrasparc IIe's are consumer priced and fully 64-bit. You can pick up a full system for just around $1k. They're not the speediest things on the planet, but you just said 64-bit consumer level processor.
According to Apple the only performa 640 was one of those hybrid dos machines. The spec is still on the Apple site. This was the era of selling crippled chips without math coprocessors. The 486DX66 that came in the box was paired with a 68LC040, thus we have an x86 chip with math coprocessor compared with a 68k Motorola chip without one. Oh yess, a *very* fair comparison.
Since no major PC computing platform uses the 68k line anymore for their CPUs why should we care about this anyway?
a) peak 8 instructions/ cycle.
b) 10 times OO window.
c) 5 times as fast bus.
d) Large buffers for OO loads/stores!
e) Excellent branch predictors.
f) 3 L1 cache ports! [2 load 1 store].
I'd say 64bit is nice add on in apple sight for a great chip. Unfortunately describing these issues would puzzle average Joe so much that they wouln't understand.
But I think apple could reuse their old hype and multiply the values by great numbers!
BTW: Apps spend plenty off time in OS libraries so MAC may be faster, as apple has a LOT more intensive optimizing those than MS...
And we all know how important for performance is to optimize code.
Photoshop for instance is good example such app, under NT it spends 67% off time in OS provided libraries.
I think apple have optimized ALL functions called by photoshop HEAVILY...
Jouni Osmala
ps. Not a mac zealot. x86/linux @home.
If IBM offers that new chip based linux desktop cheap enough I may switch platform,
next fall.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
68K architecture may have 16 registers, but they are 16-bit, while x86 are 32-bit. On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used. In PPC assembly, use most or all 32 registers at the same time is quite common, because with a RISC instruction set, you *have* to do everything in registers.
The number of registers is *very* important, because each significantly used register that you can't map is one that will have to be fetched from cache or from main memory very often. That adds up to a very significant performance drop.
But in any case going from 16 to 32 registers doesn't add any complexity.
Of course it doesn't add complexity. Writing an emulator is in fact quite simple. I could write a PPC emulator in Perl and have it run anywhere Perl does. That doesn't mean it will be fast. In fact, it will probably be so slow that it would literally take a month just to boot up MacOS.
I guess the complexity lies in the instruction set and the MMU.
The PPC memory manager may be somewhat trickier to implement than the 68K memory manager but not that much, and in many ways the PPC instruction set should be easier to implement than the 68K one. It has much fewer addressing modes and only one way to load to and store from memory.
How about an Ultra 1 for $100 on ebay? :)
Someone needs to go and read Moore's law again! First of all, it applies to the industry as a whole not to each and every chip. Secondly, it says that the number of transistors on a chip will double every 18 months although this has been modified to say that data density will double every 18 months. Moore's law does not predict that the x86 will go twice as fast every 18 months, it says that the most dense processor made will contain double the number of transistors the most dense processor contained 18 months earlier or have double the data density of the previous fastest chip. If you think the x86 will be going at 5GHz by the end of 2003, you can't base that on Moore's law!
Besides, most of the experts are saying that a 2GHz GPUL (IBM's chip) is the equivalent of an 8GHz x86, so 5GHz will be a little lacking.
Bearing in mind that most Macs are used in graphics, video and 3D modelling work, it makes perfect sense to go to 64 bit. They may not be faster at doing a spell check in Word, but Macs using these chips will cream PC's in Photoshop bakeoffs! People who say 64 bit isn't necessarily faster than 32 bit are right, but for the tasks Macs do, 64 bit is just what the doctor ordered.
This "megahertz myth" crap was around when I had a 33 MHz 68040 Performa 640, and my 486/DX2 66 blew the shit out of it.
Therefore, with my minimum sample size of 2 machines, I can deduce that all processors can be compared with MHz alone. Further, all architectures perform exactly the same, MHz for MHz across the board for similar instructions and they all scale in a linear fashion regardless of the ratio of core speed to main memory speed or other similar limitations. There is also no such thing as this "bottleneck" crap. Bottlenecks r what yer get when your old Chev brakes down on tha intastate and bloks a lane.
PS, this is sarcasm.
NASA did a study to find the best cost/performance for their Fortran number crunching.
AltiVec is a beast. A 500MHz G4 using AltiVec ran 6.9 times faster than a P3 800 and 3.7 times faster than a 500MHz Alpha 21264. The G4 worked out to be 5.3 times cheaper per FLOP than the P3 and 8.4 times cheaper than the Alpha. Although there is no mention of Intels SIMD within this documents and the FORTRAN compilers at the time of the documents writing were very limited in their abilities to vectorize FORTRAN code to make better use of the AltiVec.
Here is a 1GHz G4 performing up to 10 times faster than a 2GHz P4 while querying a DNA database and 2 times faster at their fastest measured rates.
Saying that the MHz Myth is a Myth, based on a single experience is really idiotic. Anyone who has at least failed the first semester of a CS course would know that different architectures cannot be judged on MHz alone. Hell, even comparing different revisions of the same architecture family cannot be judged on MHz alone (a 33MHz 486DX is much faster than a 33MHz 386 for example, ignoring floating point of course). Wanna talk about CISC vs RISC vs CISC-wrapped-around-RISC?
Here are some G3's (as low as 333MHz) and a 450MHz G4 running faster than a P3 500MHz. There are plenty of graphs and numbers here which might put a fright into you Hrothgar.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Generating 64bit code from a compiler will often run slower than equivalent 32bit code. For example; all of the binaries in /usr/bin on Solaris9 are 32bit, both for backwards compatibility and for performance - there are nearly 600 files. There are separate sparcv7 (32bit) and sparcv9 (64bit) binaries for only very few commands. Of these, some are 64bit so that they understand the 64bit kernel structures (adb, mdb, truss, the 'p' commands (pmap, pcred, pstack etc.) and there's sort. sort is the only command compiled to 64bit for performance. It's the only command deemed likely to encounter a large enough dataset to benefit from being 64bit.
# init 5
Connection closed.
Oh...
68K architecture may have 16 registers, but they are 16-bit
68K registers have always been 32 bits wide.
On top of that, you can get away with only mapping 7 or 8 (D0, D1, D2, A0, A1, A5, A6, A7), because the rest aren't often used.
If the 68K family has 16 registers is for a reason: speed. Accessing memory is slow. Compilers take full advantadge of the registers to avoid accessing memory, so the argument that only a small set of the registers are often used does not hold. If you need further proof, just search for some m68k assembly generated by a C compiler.
The number of registers is *very* important, because each significantly used register that you can't map is one that will have to be fetched from cache or from main memory very often. That adds up to a very significant performance drop.
Remember that we are talking about the x86 architecture, so you have 8 semi-GPR. From those 8 registers you need two for stack management, so you just have 6 left. You'll need at least another register to use as a base to access to data, for example the status word stored in a struct with other important data. So you might just get 5 registers left to map to emulated registers. The point is that you'll end up effectively mapping 4 from 16 registers, so you'll be basically accessing memory all the time. This is no different from emulating a PPC.The PPC memory manager may be somewhat trickier to implement than the 68K memory manager but not that much, and in many ways the PPC instruction set should be easier to implement than the 68K one. It has much fewer addressing modes and only one way to load to and store from memory.
In theory a RISC architecture is much more simple to emulate than a CISC architecture, specially memory access, and I fully agree with you in that aspect. In the other hand the PPC is not an extremely RISC architecture as an Alpha could be. Just take a look at the different variants for each basic instruction. There are several opcodes for the move from register to register, each with subtle differences. And this situation repeats for every basic (purely RISC) instructuction. In fact the PPC is not that RISCy (REDUCED Instruction Set Chip).
The old Mac OS for the m68k architecture didn't make use of the MMU. Then, it doesn't make much sense to write suport for it. In the PPC case the situations is very different. Mac OS X uses the MMU. I think that the MMU must be the complex aspect of coding a PPC emulator which might slow down the emulation so much that it can render it useles for any practical purpose.
I originally replied to your post because I found it misleading. Again I'm replying to a post that's not just misleading but has big factual mistakes (e.g. 16 bit registers). I don't belive that that post deserves a +3, I think it deserves a -1 Misleading. Please, moderate posts properly.
missleadingThe gcc compiler is quite horrible on Itanium as the Itanium architecture does not map well onto the gcc internal abstractions. However, the Intel compiler has very good performance on Itanium. We found as much as 10 times better performance for the Intel compiler on our in-house benchmarks. This demonstrates at least that it is possible to produce good compilers for Itanium. God knows when gcc will be one of them, though.
No, the 68000 had 32bit wide registers a 32bit ALU, a 16bit data bus, and a 24 bit address space (25 bits if you count the supervisor pin). I have the databooks. I have owned computers using these. I have programed them (in C mostly, but the debugging was in assembly). The Palm's CPU32 is I think based on this, which means I even still use one :-)
The 68010 was I think the same. The CPU32 might be based on this, if so I have one.
The 68020 had 32 bit data buses and a 32 bit address space, but was otherwise the same. I've used these but not owned them.
The 030 and 040 are the same but have a built in MMU, and sometimes FPU. I have used and programmed the 040 a lot, but not owned them. I have data books for both somewhere.
The 060 was super scaler but otherwise much like the 040. Never used one. Didn't have a data book for it.
If you don't beleve me, call Moto and get a free data book. Enjoy.
Hmmm, I sort of disagree with this. Almost every 68000 instruction uses one or two registers, most can use far more (what with the complex non-RISC addressing modes). Almost every RISC instruction uses 3 registers (sometimes one register is used twice though). Registers are extremely important in both RISC and CISC code. Not so much on stack based machines though.
I think the real reason the 68k emulators are easier then PPC emulators is 68k CPUs are not very fast. If you ignore the almost-68K CPUs like the ColdFires I think the 68k family didn't go faster then 60Mhz. Also prior to the 68030 most instructions took more then one cycle to execute. So a 600Mhz Intel/AMD/PPC can afford to spend 10 cycles doing the work of one 68k cycle and you are still as fast as the original.
On the other hand PPCs are far far faster. I have I think a 50Mhz one in my set top box, emulating that on a 600Mhz Intel/AMD would only give you 5 or so cycles to get the work done. Worse yet the one I have in my old laptop is 500Mhz, the 600Mhz Intel/AMD gets barely more then a cycle! A brand new top o the line Intel might get 4 cycles to do the work in, but that really isn't much time!
At least not for anything that does the translation on the fly. For something that does the work ahead of time and caches it like the TranMeta Crouse, or (I think!) some 68K emulators, you can do much better, if there are loops at least.