Apple Secretly Maintaining x86 Port Of Mac OS X 736
Earlybird writes "According to this eWeek article, Apple has ported the whole of Mac OS X to the x86 architecture and is maintaining it in parallel with the PowerPC builds. Dubbed Marklar, the project is perceived as a fall-back plan, and, quoth the article, 'has apparently gained strategic relevance in recent months, as Apple's relationship with Motorola has grown strained and Apple looks to alternative chip makers.'" Believe what you will ...
OS X is already available for Intel. (Score:2, Informative)
Marklar! LOL! (Score:1, Informative)
They got chased up by missionaries that wanted to convert the entire planet to Christianity and the Marklars ended up kicking the missionaries off the planet and allowing all of the Ethopians to move to Marlar to live since they couldn't survive in Ethopia.
So in relation -- Marklar... a strange foreign land. Kind of suiting for OSX on X86, eh?
Re:Believable (Score:5, Informative)
Anyways, it totally makes sense for apple to go with a desktop version of the POWER4 core. The PPC specification is such that any program written that targets the UISA (think it stands for something like user instruction set architecture -- ie, non-privelidged instructions) will move right over to any other PPC core w/o a recompile. And the PPC64 spec is such that all instructions are still 32bit; it's just the data / registers that're 64bit. So binary compatibility is a no-brainer.
Couple in the fact that power4 has multiple cores on a die... and, damn. I'll buy my first Apple machine if they actually do this.
Already done that (Score:5, Informative)
It was really a transitional OS which gap between NextSTEP and OSX. It contains both elements of both OSes. Anybody recognize the chess program at the bottom of the page?
Re:Stick with PPC (Score:1, Informative)
This is news? (Score:1, Informative)
The year is now 2002. NeXTSTEP has morphed into Cocoa on PPC. It's the same dang libraries basically. Given that it's already pretty robust, why WOULDN'T Apple not maintain this technology just in case? Are they idiots? I think not.
As to Classic apps, Apple had 680x0 apps running in emulation on Intel a *decade* ago. Big deal! PPC classic apps are nastier because the PPC doesn't nicely map to Intel; but if Apple needs to jump ship they can just toss out Classic entirely and not look back.
The critical issue is whether or not Carbon apps can run on multiple binaries. Apple would have to figure out ways to handle the endianness issues, and then a recompile would probably be all that is necessary. Then again, Mac developers shouldn't be coding in Carbon anyway. It's a legacy library. And that's true no matter how much Apple squeals otherwise when Microsoft and Adobe jump on them. One day, Carbon will go away. And good riddance too.
Sum up: a pure Cocoa MacOS X would be a snap to get running on multiple architectures.
Re:don't get all excited (Score:2, Informative)
I wouldn't be so sure. XPostFacto is still going strong with no threat of legal action from Apple whatsoever, and I gather there are numerous happy users of OS X, running it on their old 7300/7500/7600/8500/8600/9500/9600 series PowerMacs via XPostFacto. Then again, the XPostFacto people (person?) can probably get away with it since they're not directly modifying Apple's code, just distributing an extension (or kernel module, if you prefer) using known APIs. Presumably XPostFacto's theoretical x86 analogue would do the same.
Then again, the situation's not exactly the same -- at least in the case of people running OS X on upgraded legacy Macs, they've already paid Apple's hardware tax.
Re:Actually, this idea isn't new... (Score:3, Informative)
The project you're talking about is Star Trek. It happened at the same time as Taligent and Pink. Any idea where all of those things are now? Find me a Dylan programmer and we can ask him together. Or we could send him an RTF e-mail with Cyberdog. Running in Copland.
Re:OS X is already available for Intel. (Score:4, Informative)
Even Apple has admitted to this before. (Score:4, Informative)
Re:Stick with PPC (Score:2, Informative)
Cocoa apps, on the other hand, are ready to go.
it's the whole yellow box v. blue box thing.
Re:Ported all of Mac OS X to x86? (Score:2, Informative)
One thing that I haven't seen commented on is that the Finder is a Carbon application -- Jobs specifically claimed this as an example of "eating one's own dog food." This means that unless they've rewritten the Finder in Cocoa, or ported Carbon to this alleged x86 build of OS X, the story is as groundless as all other similar stories.
The article strongly implies that Carbon has not been ported to "Marklar," as in the following:
But if there's a Cocoa version of the Finder, why haven't we seen it? (Be aware that I'm not a Jaguar user, and don't know if the Finder is Cocoa in the most recent release.) However, given these points:
any claim of a fully-featured x86 OS X is bogus.
Re:Business as usual (Score:2, Informative)
And then, once Windows is running nicely on your x86-based Mac, developers won't need to write Mac software anymore. And then, well, then Apple's in the same business as the rest of the PC makers, and probably dies.
Oops.
And that's the problem with Mac on x86, even in the case where you still have to buy Apple's hardware. You're going to expect that it run your Windows software (it's got an x86 CPU in it!). As soon as that happens, developers start telling their Mac customers, just use the Windows version on your Mac. Little by little, Mac OS goes away and Apple with it.
Think different, think LinuxPPC (Score:2, Informative)
Why am I telling it? I think Mac OS (including Mac OS X) users should use the same formula as was driving users from PC to Mac - "Think different, think Apple!", but now with a small change: "Think different, think Linux/PPC". Mac/PPC world should not be and is not limited by the dictated choice of the sector monopolist (Apple). And Linux is doing the same great job is it's doing on the PC sector - it's giving the choice for people. The choice of OS.
Seriosly, think about it. What kind of choice Mac gives to people? To spend another $1K for more expensive hardware and then to stick with Mac OS after discovering lots of Mac OS (even OS X) problems? With Linux/PPC people can buy Mac/PPC and use same skills as they have with Linux/x86.
I think that Apple, instead of porting of Mac OS X into PC/x86, should officially support (and contribute!) Linux/PPC. Eventually Apple should either port Aqua to Linux/X11 or to give up Mac OS at all.
Just look at the author's name (Score:3, Informative)
According to sources, the Cupertino, Calif., Mac maker has been working steadily on maintaining current, PC-compatible builds of its Unix-based OS.
This doesn't shed any light. Unless they come with a more reliable thing than 'sources' I think it's a miss.
Re:No. (Score:2, Informative)
I like your use of "necessarily." I'll need to work that into my daily usage ;-) But I respectfully suggest you're neglecting history.
CISC comes from an age of assembly-language. It got so extreme some had polynomial evaluation as an instruction.
RISC comes from an age of compilers. It is a refinement of CISC, based on observing which instructions actually get used and how.
Please note that I don't mean that compilers didn't exist before RISC, it's just that in the late 70s when x86 was designed, a hell of a lot of stuff was done with assembly. Also, Jimmy Carter was President and the Bee Gees were selling millions of albums a year.
I'm sure you know all this, thus your clever "necessarily." But I'll continue for the benefit of any youngsters ;-)
CISC can have dozens of addressing modes. "Load indexed scaled adjusted and postincrement the index" and every imaginable permutation. Your CPU would suffer as it slogged through all the decoding.
It turns out that to get speed, people just did all the indexing and scaling and whatnot explicitly. The CISC processor was being fed a stream of simple instructions which it didn't have to chew on.
So folks started making chips that ditched all the complex stuff, and we got RISC, which have less than a handful of addressing modes. Effective address calculation was done explicitly, just like all the smart kids were driving their CISC chips anyway.
Turns out that sometimes it's good to have a little complexity. For instance, if it doesn't hurt anything to have a complex multiply+add instruction instead of a multiply followed by an add, and you sell into markets that can use such a tweak, why not?
Motorola's AltiVec is a further example of "enhanced RISC."
Thus was born "Performance Optimization With Enhanced RISC," or POWER. Apple needed a RISC chip, enacted a shotgun menage-a-trois with IBM and Moto, and we got PowerPC.
A POWER architecture is two stages of refinement past CISC. Add to this the fact that x86 is pretty much the worst CISC architecture ever -- 68000 was so superior -- PowerPC is a much better, more refined chip than any x86.
If only Moto didn't suck at building PowerPC! What is wrong with their fabs? There's something seriously bad going on there, such a shame since Moto has proven design genius with 68000 and AltiVec.
In more fairness to the Dark Side, x86 vendors no longer directly execute the crufty x86 ISA. They translate the instruction stream to something that gets executed by a much better architecture than x86, "micro-ops" for a "core." In these cores, they've been able to incorporate a lot of RISC-like improvements, scalar-ness and whatnot.
Re:Ported all of Mac OS X to x86? (Score:1, Informative)
John, Senior Apple engineer.
This isn't just OS X they've done this for... (Score:1, Informative)
Why did I think that? Simple... because Apple has ported *EVERY* (major) OS to x86... the fact that it got out that Apple made OS X for x86 doesn't mean anything.
I read over most of the posts... and I didn't catch one that said Apple's done this for more OS's than just OS X.
Let it be known, this doesn't mean they will use x86 processors... just that word is out that it's been done.
I'll probably me marked off as a troll if at all, but I know this is a fact... I've beta tested Apple's OS's before... if you know what I mean.
marklar defined (Score:2, Informative)
Example: On Marklar, everyone and every thing is referred to as marklar. We come in marklar. Take us to your marklar.
Re:Nope. (Score:4, Informative)
The biggest reason is that maintaining an Intel version ensures that everything they write stays reasonably portable. It they can stay compatible with PPC and Intel in the code, than supporting any other chip that comes along can't be much more difficult.
Internal builds used to always be built fat...they would just be stripped to PPC-only when it came time to press to a CD for external use. I don't know if it's still the case, but I don't see why they would stop the practice.
Also, maintaining compatibility keeps future migration options open to them.
Most of OS X is highly portable already. The kernel is Mach, which was fundamentally designed with portability in mind. Above that is the BSD layer which is regularly synched with the OpenBSD source tree, which is x86 code -- so it's portable. CoreFoundation is part of Darwin, so it already compiles on x86. Cocoa is very high level and used to run on x86 back in the OpenStep days...no big issues there. I see no reason why Cocoa couln't easily go to Darwin as well. Apple had to basically build the Carbon library from scratch after the developer community refused to migrate en-masse to Cocoa. I don't believe Apple would be short-sighted enough to not write it in a portable fashion. Really, Classic is the only part of OS X that would cause a problem with an x86 port. If push comes to shove, Apple could just draw a line in the sand and say that Classic isn't supported...developers have had enough time to move their stuff forward.
Of course, just because the port is possible doesn't mean that Apple will ever make it a product. Support for such a thing would be a nightmare given the huge number of hardware options in the x86 world. Apple is barely capable of keeping up with drivers for there exremely limited set of hardware options.
Re:Stick with PPC (Score:2, Informative)
The 68k was big endian, and the PowerPC on the Mac runs in big endian mode. x86 is little endian. Big endian is when the byte order for a number goes most significant to least significant byte. Little endian is the opposite.
Examples:
1 (0x00000001)
Big endian: 0x00 0x00 0x00 0x01
Little endian:0x01 0x00 0x00 0x00
4096 (0x00001000)
Big endian: 0x00 0x00 0x10 0x00
Little endian:0x00 0x10 0x00 0x00
305419896 (0x12345678)
Big endian: 0x12 0x34 0x56 0x78
Little endian: 0x78 0x56 0x34 0x12
Likewise... if one has a 4 byte integer in memory, and assumes it is within 0-255 (or -128-127), little endian processor, treating that pointer to the integer as a pointer to a single byte, will work properly. Big endian machines requires offseting the pointer. This is, of course, bad coding, but it happens nonetheless.
Suddenly all binary data files need translation to work... any code that makes assumptions about byte order doesn't work (such as optimized code for handling byte streams of data in chunks).
A major part of my job is doing conversions of software from Windows to Mac (games specifically), and handling for endian conversions in file read/write and network transmission, and fixing code that is specific to little endian byte order, is a not an insignificant part of the work.
This means that now a lot of code has to be changed/fixed/whatnot, but also a new testing cycle. And if you think getting a lot of developers to just recompile is a pain (and it would be)...
- Chris Jacobson