Slashdot Mirror
Nearly 25 Years Ago, IBM Helped Save Macintosh
dcblogs (1096431) writes "Apple and IBM, which just announced partnership to bring iOS and cloud services to enterprises, have helped each other before. IBM played a key role in turning the Macintosh into a successful hardware platform at a point when it — and the company itself — were struggling. Nearly 25 years ago, IBM was a part of an alliance that gave Apple access to PowerPC chips for Macintosh systems that were competitive, if not better performing in some benchmarks, than the processors Intel was producing at the time for Windows PCs. In 1991, Apple was looking for a RISC-based processor to replace the Motorola 68K it had been using in its Macintosh line. "The PCs of the era were definitely outperforming the Macintoshes that were based on the 68K," he said. "Apple was definitely behind the power, performance curve," said Nathan Brookwood, principal analyst at Insight 64. The PowerPC processor that emerged from that earlier pairing changed that. PowerPC processors were used in Macintoshes for more than a decade, until 2006, when Apple switched to Intel chips.
Apple was definitely behind the power, performance curve," said Nathan Brookwood, principal analyst at Insight 64. The PowerPC processor that emerged from that earlier pairing changed that
PowerPC was pushed by the AIM alliance: Apple, IBM, Motorola. The latter two developed and produced chips. Apple had some input. The goal was an ISA that made it easy to emulate both m68k and i386.
I am TheRaven on Soylent News
Errr, yeah, but they could have just used Intel chips like everyone else. Ultimately it would have given better performance, saved themselves a lot of pain in switch over, and put themselves ahead of the curve selling to people who wanted to dual boot. So did IBM save them or cripple them?
how would we ever get along without it? http://www.youtube.com/results?search_query=ibm+hitler
I was working very closely with Apple at the time, and unless everyone was being lied to, "IBM saved Macintosh" is a pretty serious mischaracterization. More like three companies working together to create a platform useful to all the contributors. Did IBM put more into it than the other AIM members? Probably. But they didn't do it out of the goodness of their hearts.
Right, so this is the infamous mac os 7 era right? Powermacs? Where motorola code was emulated to work on PPC? Apple being led by non-jobs? When Macs didnt just needed a restart every 24 hours (like windows did) but would outright ruin there system install every other week?
That was the most shitty Apple period ever.
as far as Apple could throw it. Why? Because
Intel RUELZ!
P.S. At the current rate, IBM will be flying a red flag out front in not too many more years.
if not better performing in some benchmarks
...some of which could perhaps be better described as"benchmarketing"
Those of us who think they know everything annoy those of us who do.
A much more elegant architecture than x86. Still have to give Intel credit their manufacturing prowess gave them the edge.
It is not from the benevolence of the butcher, the brewer, or the baker that we expect our dinner, but from their regard to their own interest.
A much more elegant architecture than x86.
Elegance without performance is ultimately pointless. And the 68k platform seemed to be neglected by Motorola. I don't know if the problem was economic, technical or some other issue but Motorola was clearly falling behind the competition for whatever reason. The x86 architecture is ugly (to put it kindly) but it's generally good enough, fast enough, cheap enough and it benefits heavily from network effects. Plus Intel is without question the industry leader in manufacturing efficiency (including die size) so they have a real cost advantage that is hard to overcome for the types of chips they make.
And Standard Oil saved more whales (kerosene is more convenient than whale oil) than Greenpeace ever will.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
I'd suggest it was ARM more than IBM that saved Apple
using up bandwidth downloading Apple updates
Because no other OS gets shloads of updates, ever. Certainly not Windows, nor Linux.
Fuck off, douchebag.
Resting on their laurels. Same as MIPS, SPARC, and the other dead architectures of the day.
While Intel was pushing ahead with R&D on their own process technologies, most of the other big players either had a fraction of the money being placed into process technology or were relying on a third party to provide their process technology needs.
It was only in the last 5-10 years that we say 3rd party foundries start ramping up process technologies to a level just behind Intel, whereas in the past they were anywhere from 3-5 process steppings behind. This was among other things the reason for the sudden improvements in video card tech back around '03 to '05, and the basically flatlining of low to mid range performance since '08 or so (Certain midrange hardware from the '09-10 period is still performance, but not energy competitive with current gen low-mid parts, while the majority of high end improvements have come with a dramatic leap up in energy consumption. While they're faster and more energy efficient than the older cards, the majority of that savings is due to reduced duplication of passives that would've been required for the equivalent performance out of multiple cards, rather than any notable energy efficiency in the gpu itself.)
That said: The popularity of microsoft between '95 and '00 and the incompetence of Apple (and Motorola/IBM), Sun, and SGI during the same period is really what lead to Intel's domination in the later years. If Sun/SGI had marketed 'PC' level hardware with their own OS stacks during that period a whole generation would've grown up ready to migrate to their 'big iron' in the business sector, and if Apple had created a 'color' Mac Classic priced system to cater to the low end (something that they sorely lacked during that period, along with peripherals for their 'proprietary' (Nu)bus) they could've kept a large enough percentage of the market to have more directly competed with Wintel up until now.
Envy is a cruel mistress.
It sure seems like the M68k architecture could have been pushed forward more. Yeah, it was CISC, not RISC, but it was a very clean CISC. Modern x86 chips are really RISC machines internally, they just have a bunch of translation from the CISC instruction set to the 'real' ISA inside. If nothing else, that approach could have worked for M68k, right? Probably better, since the basic M68k ISA isn't so crufty and ugly like x86.
PHEM - party like it's 1997-2003!
G5s ran too hot for notebooks. IBM's manufacturing capacity for Power/PPC cores outside its own servers and workstations was eaten up by Microsoft for its XBox line. Apple was waiting too much on inventory. They switched to Intel not because their chips were more powerful, but because their chips were more available and could be used more flexibly.
So far most of the comments I am reading have to do with either an elaborate of the article, or an incorrect reinvention if history. Amazing!
I remember the good olds days of theMotorola 68000 on Atari 520 ST and of the 68030 on the Atari Falcon 030. Would it be possible, today, with moderne technologies, to create a 68060 at 4 GHZ and a cool computer and operating system like a M68K Linux machine, not too costly ? The 68000 was so easy and so cool to program ! .
I've read, though don't remember the reference, that originally IBM wanted to use the 6809 CPU.
IBM: Hi, is this motorolla?
Moto: Yes
IBM: Hi, this is IBM, we'd like to use the 6809 in our next project.
Moto: Great! Our unit pricing is $N in quantities of 1000.
IBM: Great! Can you set aside capacity for 100,000?
Moto: Units? Next year?
IBM: No. Pallets of 1000, per month.
Moto: (gulp) You want a million chips a month?
IBM: Well, probably not the first couple months, but yes.
Moto: Sorry, we just don't have the capacity to make those in that volume, and wouldn't be able to for at least a year.
IBM: Okay. Thanks anyhow.
Intel: Grove speaking
IBM: I'd like to use the 8088 for my next project
I'd still rather have a good blaster at my side
More music, fewer hits
There were 3 initiatives that Apple and IBM agreed to. Two failed right away. The third, use of the PowerPC chip, lasted a while - until it failed too and Apple wound up on Intel like everyone else. And all it cost them was a couple extra re-writes of their OS. So it's a bit of a stretch to say that IBM "saved" Apple. I would think probably the purchase of Next, rehiring of Jobs and iPod are what really turned things around.
The original PC, in 1981 ran on the 8088 - an 8/16 bit hybrid chip. By the time the Mac was released in 1989, the 486 was the chip of choice for the IBM PC and, more importantly, the clones.
Apple had a history and relationship with Motorola with the 6502 used in its Apple I and II lineup. When the Mac was released, the 68000 was a superior chip to the 386. And, there was the Apple vs PC war going on which helped solidify the choice - Apple was distancing itself from PCs anyway possible.
The 68K was a superior architecture to the x86 from a programming perspective. It's handling of memory was superior as well and was a dream to code in comparison to x86. But, frankly, it was easier to squeeze more performance out of the 486 and Pentium chips. Throw in a x87 co-processor, and my original PC seemed to outperform my original 68K based Mac when it came to number crunching despite the PC running at 4mhz vs the 16mhz 68 (yes, mhz). Even when I wrote assembly code (and, I was pretty good back then), the x86 code was still faster than comparable 68K code. Apple released subsequent versions of the Mac with the 68010/68020/68030 chips. But, so much was being done in software vs hardware on the Mac, especially, graphics, that the Mac seemed slow in comparison. The open architecture of the PC allowed 3rd party graphics cards and add-ons.
The Mac, with it's closed architecture, did not permit real 3rd party boards (unless you wanted to open the Mac and do a piggy-back board) until the Mac II and NuBus. NuBus never caught on - mainly, because Apple market share and developer constraints made it a real PITA to create NuBus cards. NuBus was pretty cool, though and was true plug'n play even before PC's got that ability.
At this same time, there was the debate over superiority of CISC vs RISC chips. Intel was CISC. Motorola stopped improving the 68K and focused on RISC. Apple went with RISC and, together with IBM and Motorola, developed the RISC PowerPC chip. It was, likely, easier, to port the 68K firmware and software to the PPC vs an x86 and it avoided the nightmare of admitting that IBM got it right when the went with i
Dwindling market share for the Mac (they still didn't permit clones to use their OS), heat (PowerPC was HOT and not suitable for laptops), and cost (x86 was cheaper than PowerPC, period and being produced by multiple vendors - nobody else made the Motorola designs), and Motorola doing much to improve the heat, power consumption and performance vs x86 took Apple down the x86 path.
Is apple using PowerPC chips today? no.
All IBM did was derail the Motorola 88000 chip which was an evolutionary dead end anyways, but what it really did was kill the 68080 and beyond. The 68060 was more akin to the Pentium in design as the 68040 was to the Intel 80486. IBM stepped in and killed off Motorola chip fabrication, killing a bunch of 68000 based vendors including Commodore, Atari, NeXT and so on.
The fact that ARM has killed PowerPC in embedded space just speaks volumes to what a malaligned bone headed deal this was.
All IBM did was get other parties to help with fabbing newer POWER processors for the RS/6000 and to embed in new mainframes.
Apple uses Intel and ARM processors.
Apple was definitely behind the power, performance curve," said Nathan Brookwood, principal analyst at Insight 64. The PowerPC processor that emerged from that earlier pairing changed that
PowerPC was pushed by the AIM alliance: Apple, IBM, Motorola. The latter two developed and produced chips. Apple had some input. The goal was an ISA that made it easy to emulate both m68k and i386.
No. The goal was twice the performance at half the price of the x86.
Now Intel's CISC based x86 was certainly more difficult to work with in terms of improving performance but Intel was not exactly lacking in resources, human or financial. Even if it took 10x to improves CISC compared to RISC, Intel had the 10x. Intel pulled off friggin miracles with x86 performance, not one expected them to reach the clock rates they did.
It turned out that in general PowerPC had a 20% performance advantage over an x86 at the same clock rate, getting twice as fast was only achieved in very specialized circumstances. However Intel was able to achieve higher clock rates than PowerPC and maintain a general performance lead.
... the kernels (as Microsoft hired David Cutler to bring the VMS kernel with him to create Windows NT ...
Wrong on two counts. Cutler had worked on VMS but he did not bring it with him. NT was written from scratch. Also, he was not brought on board to rewrite Windows, he was brought on board to rewrite OS/2. While IBM worked on 32-bit x86-specific OS/2 2, Microsoft would in parallel work on the CPU architecture portable OS/2 3, aka "NT OS/2". Microsoft and IBM "broke up" and NT OS/2 was renamed Windows NT.
Too bad the PowerPC machines *couldn't run the damn games* or the requisite MS Office suites for students and business people to use them.
They ran Warcraft, Starcraft, Diablo and World of Warcraft.
"Knowledge of how the hardware operates", "Things like CPU instruction set options, memory alignment, etc.", are the business of compilers and their creators.
Perhaps, but they fail at it. Game developers often **have to** make up for the deficiencies of compilers.
Compilers optimize code much much better than humans do.
Perhaps the average programmer, but those specializing in assembly language routinely beat the compilers. Assembly is merely less common today because of (1) cost and (2) CPUs are so overpowered for nearly all tasks we can live with less efficient compiler generated code.
The original "MHz myth" came out of Apple fanboys back in the PPC days. The PPC was supposed to be super amazeballs, beat up those nasty PCs, all that stuff. Well turned out when you got a new PPC Mac, it was slow, since everything was 68k code being emulated. So they latched on to the benchmarketing, the few PPC benchmarks that ran well, and that the MHz of PPC would get much faster. They said that PPC has a positive second derivative (growth of growth) of MHz, x86 had a negative 2nd derivative and so on.
Then of course x86 went and scaled waaay higher, so all of a sudden they started talking about the "MHz myth" and how MHZ didn't matter, PPC was better (again at a select few benchmarks) etc, etc, etc.
You are assuming a game that was designed to be cross platform. In reality many of the games ported to PowerPC Macs were designed and written only for x86 Windows by their development team and porting to the Mac was done by a different team when the game is near completion or has already shipped.
True. I was astonished when I invested a decent chunk of change and bumped my 100MHz 486 from 16MB to 64MB of RAM. Multitasking actually became practical, especially running Mozilla alongside something else. Of course, the 68K Macs of the day weren't that much better at supporting 'a browser and something else'. The cooperative multitasking of the Mac OS helped reduce overhead, but it still took RAM.
PHEM - party like it's 1997-2003!
The bad coffee machine is out of order.
Wait, there are updates for Windows?
Uh-oh.
You are welcome on my lawn.
I bet Google DOES use some moderate amount of assembly. I once worked for an audio-recognition company and we did indeed use about 100 lines of x64 assembly to perform the inner loop, which was some complex audio signal processing routine. Similar to an FFT.
This was easily 10x faster than the C version, which we had for reference purposes, even when using the Intel compiker with all optimizations turned on.
So, just because you never saw a Tapir in your life, does not mean they can't exist because their dick is longer than you can imagine.
Wait, there are updates for Windows?
Uh-oh.
That's why I just use Windows XP. I haven't been bugged for updates in a while.
I'd certainly be possible to get a modern 68060 to run at 4GHz if it ran with the memory that was used for those systems back then. To run it that fast, you'd need all of the RAM to be on the die, and it'd need to be the static, cache-style, blazing fast RAM. A 68060 isn't really a 68060 anymore if you'd add three levels of cache to it.
A successful API design takes a mixture of software design and pedagogy.
Motorola couldn't manufacture enough of the 68K CPUs, so Apple set up an alliance with IBM and Motorola (AIM). The first generation of the PowerPC was fast and easily manufactured.
Motorola sold Apple on AltiVec, the 128bit vector unit, and it was added to the PowerPC.
Once again, problems with the design and just sheer Motorola incompetence caused CPU production to fall behind. IBM, seeing the writing on the wall, bailed.
Apple, finally tired of Motorola's crap, ported everything to Intel, and left without looking back. Too bad it took them 20 years to realize this.
Motorola became synonymous with crap hardware and crap cellphones that would break. However, Motorola was great at the con game. They suckered Google into buying them, and then Google unloaded the Motorola unit at an $8 billion loss to Lenovo, probably for parts.
But whatever you feel about Apple, do not blame IBM. Motorola was the one holding back Apple.
Same age. Started programming the Apple II as a teen. Was getting paid for it by my 2nd year of college.
Whlie PCs such as Dell were selling on the "were faster" price/performance bandwagon, the Mac was never sold on that. Yea, when a new generation of Mac hardware has come out, you get the 2x faster type stuff, but never we clock 10% better type stuff. Or when they switched to Intel, it was an event.
Which one of the posters in that link are we supposed to assume is you? I didn't see any APK's.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Perpenso used STRAIGHT assembly code. I used inline assembly via the asm directive (since 1996 here in Delphi) - the link shows the results of that vs. compiler optimization unrolling loops even during optimizations!
The bottom-line of that link? What I said - That using asm in loops ends up often DOUBLING speed, & I am as I said, NOT some "asm" wizard!
However (again as I said), I know a few 'key' routines such as loops, which that research used, that DO work for better performance via the use of inline assembler language (which I used from 1996-2009 quite often in Win32 + Delphi 2.0 - 7.1) - Delphi XE, XE2 for SOME reason, can't do it afaik, HOWEVER: Delphi XE3 has reintroduced it (thank goodness, it works is why - I must license it one day soon in fact)
Anyhow/anywaysL
That link proves it for both Perpenso & myself, & with MORE than just our "anecdotal evidence" (though that's good enough from guys like he & myself (both 1/2 a century old & coding since our teens)).
APK
P.S.=> Even though compilers "unroll" loops during optimization, that link SHOWS & PROVES what perpenso & I both stated - use of assembly, properly & judiciously, works for BEST performance (though NOTHING beats a better algorithm/engine that's more efficient though)... apk
See subject-line & for the 2nd time - I didn't post there. The research backs up perpenso & me using assembly for performance purposes!
(E.G. -> He straight assembly, me using inline assembly via the asm directive in Object-Pascal/Delphi)
Yes - &, as that research shows? It works (like gangbusters)!
Especially when used judiciously with a GOOD solid algorithm/engine too.
Plus - Like I said: I'm no Assembler wizard, but I know where it DOES yield large benefits in key places - looping is one of them, one I used a LOT in Win32 + Delphi 2.0 - 7.1 circa 1996-2009, for speed gains (big ones) as that research proved (proving my words, and perpensos).
APK
P.S.=> Again, so it sinks in - I didn't POST on that research page, but I was doing & using inline assembler a DECADE OR MORE before that proof in research, because it works (backing perpenso, & also my seconding his motion)... apk
1) It was in 1991. As the current year is 2014, that happened 23 years ago, not 25.
2) Apple and Macintosh weren't in trouble at 1991, in fact they were doing good - they were the most sold brand in the world of computers! So IBM saved nothing.
3) IBMs contribution is no longer of value by now. RISC technology failed to fulfil its promises, was reduced to the niche of game consoles, and then lost even that niche. RISC disappointed the great expectations that people had - including myself. PowerPC-powered Macintosh were sold from 1994 to 2005. That's 11.5 years, half of the last 23 years - and then Macintosh started doing better. It does so much better by now, PowerPC era seems a dark era by comparison.
-
Enough?
-Ignacio Agulló
Like you, it'd take ages (Steve Gibson does a good job though) to make a corvette for Windows apps (car analogy yes but they work to make points) that goes 300mph, when you can code in an High Level Language & get one that goes 250mph with good algorithms + Compiler switches level optimizations in a FRACTION of the development time basically though (MINUS a toolkit using straight assembly ONLY as Mr. Gibson DOES nicely provide for Windows development no less), especially for larger apps & room for breakdown goes up with lines AND logic too.
APK
P.S.=> Like I said - No Assembler wizard here, but I *do* know some "key areas" which make HLL code go faster, & LOOPS is one such area I use, or have used, via the inline asm directive in Borland Delphi in 32-bit (couldn't in my 64-bit stuff in Delphi XE2, but it's been reintroduced in XE3-XE5++ & above now - I'll have to buy it because of that, since yes, IT DOES WORK per that research article's proofs in addition to perpenso's claims & my OWN successes using it sparingly ONLY in key areas like loops for nearly DOUBLE performance boosts)... apk