Mac OS X Built For CISC, Not RISC 82
WCityMike writes "One of the programmers at Unsanity, maker of haxies, recently posted a rather shocking relevation on the company's weblog. He says that Mac OS X's Mach-O runtime ABI (Application Binary Interface) comes from a NeXTStep design for 68K processorts, and is not designed for the PowerPC architechture. Had they used the latter, things would have been approximately 10-12 percent faster. And supposedly, they can't fix it now without breaking all existing applications." The developer mentions there are workarounds in the newest GCC, but only for newly compiled programs.
the return of "fat" binaries? (Score:4, Funny)
With OS X, I had hoped we would again have a situation where just using the Mac required that extra step of compatibility checking, setting us apart from the drooling masses of Gates-worshippers. Sadly, with the Classic compatibility layer, it did not come to pass. Hopefully this revelation will set things aright.
Re:Future (Score:5, Funny)
Re:Future (Score:1)
Nah, couldn't be. Steve Jobs still thinks that Moore is a Moore-On, and that Andy Grove guy is just plain stupid. He'd never allow Apple to move to the Pentium
Re:Future (Score:3, Funny)
Now we know why it was so slow, right? (Score:4, Funny)
what's it going to be like w/ the 970? (Score:5, Interesting)
Like the Itanium, with its poor backwards compat performance? Or will it be speedy?
Some tweaking req'd (Score:5, Insightful)
With the speed of current and future processors the delivery of a stable OS is preferable to a 3 year late, and tweaked OS that runs the same things just a little faster.
Re:Some tweaking req'd (Score:3, Funny)
Exactly. When Copeland comes out it's gonna be smokin'.
Re:Some tweaking req'd (Score:2)
Re:Some tweaking req'd (Score:1)
Re:what's it going to be like w/ the 970? (Score:3, Informative)
Re:what's it going to be like w/ the 970? (Score:5, Informative)
i have a funny feeling that (Score:4, Insightful)
Re:i have a funny feeling that (Score:5, Insightful)
I would agree with you, but this is a legacy decision that would have saved them crucial months early in the OSX creation process...so I can just as easily see them making the choice then, to get a shipping system out the door, THEN discovering that OSX's biggest problem is that it isn't fast enough, and now trying to retrofit a solution. That matches all the information I've gleaned from mac sites in the past.
It sucks, but if they hadn't gotten X out the door when they did Apple would have been dead in the water--it was already horrendously late for those who started waiting for Copland.
Re:i have a funny feeling that (Score:1, Insightful)
But yes, this sounds like a 'hi, we're from NextStep, we're going to save you' attitude. The detail got lost in the fury and the excitement. That's what it sounds like at any rate. Sure they thought about it; but by now they know they didn't think about it 'right'.
Re:i have a funny feeling that (Score:1)
1) Apple wants to ensure that should Motorola ever tank on them, they have the ability to port OS X to a wider range of processors, and/or
2) Apple has specific possible platforms for OS X in mind in the future. x86 immediately comes to mind. Granted, this is a rumor that has run its course a million times over, but don't jump to conclusions. This may not mean an OS X port to x86. Looking at OS X and its multiple APIs (Carbon, Cocoa, Classic, "native Java"...) perhaps Apple may be plotting to roll out some sort of cross-platform API that would enable Mac OS X apps to run on, say, Windows. Support for such an API close to the kernel, as Apple would be capable of producing, would make such an API much faster on the Mac than, say, applications based on certain browser cum cross-platform COM system [mozilla.org].
Just some speculation here.
Re:i have a funny feeling that (Score:1)
In Case Unsanity Gets /.ed (Score:2, Informative)
Here is the text:
Unsanity.org
October 21, 2002
Mach-O ABI
Here I go again, ranting about Mac OS X bowels. This time I want to talk about particular implementation details of Mach-O runtime ABI (Application Binary Interface). Before you get too confused, there are two different things under the 'Mach-O' name:
* Mach-O ABI, which defines how every application in the system executes and calls functions (stack conventions, register usage, and more);
* Mach-O File Format, which defines a way for compiled executables to store different parts of them in the same file (compiled code, data, strings, etc).
The latter is not what I want to talk about today; the first is what puzzles me most. I admit I am just a "small programmer" with no relationship with the powers-that-be at Apple at all (this means, no insider contacts who can explain the reasoning behind the particular important design decisions to me), so my impressions, judgements and guesses expressed in this article may be slightly or totally off the mark. I, however, as many other developers who have dug deep into the implementation of such things, can see obvious drawbacks and oddities about Mach-O ABI, and this is what I am going to talk about.
Mach-O originates from NeXTstep, an operating system created at NeXT for its NeXTstation machines, and later expanded to x86 hardware. NeXTstations were originally based on Motorola 68k CPUs, just like old Macintoshes. Mac OS (classic), on the other hand, used an ABI for PowerPC which followed the ABI principles defined in a document by IBM/Moto for PPC processors. So as you all may already know, m68k and x86 are CISC architectures; PowerPC used in all new Macs is RISC.
To make a long story short, Mac OS X uses an ABI designed for CISC processors, mostly ignoring RISC design principles.
What do I mean by that? Mach-O ABI we see now used in Mac OS X is more or less a direct port of NeXT's Mach-O designed for m68k - it relies on PC (program counter) register to perform various manipulations with data (for the geeks: PC-relative addressing). There's nothing wrong with that, as its an effective and common practice, except for one little thing: there is no PC register in RISC processors (programmatically accessible). That is not a show-stopper though - Mach-O for PowerPC just takes one of 32 general purpose registers and turns it into a program counter-style register, to base all offset calculations off it. That works well, as you can see, as all of Mac OS X applications (except for the ones compiled with Carbon/CFM) use the Mach-O ABI.
That approach works well, except for one small thing: global/static data access adds about 7 cycle overhead per function, and about triple of that for cross-context calls (that is for the G4 class processor) compared to the old, Mac OS Classic ABI (excuse me for the geek talk). Mac OS Classic CFM ABI, in comparison, needed almost 0 cycles for static data access and about 5 for cross-context calls. To rephrase - applications in Mac OS X could be faster, if the Mach-O ABI followed the principles set for the PowerPC chip, and not the ones created over a decade ago for CISC ones.
This brings us the question, "how much faster would the applications be if the ABI was done right?". The answer is, according to some tests done by my friends at #macdev IRC channel, the speed gain would be 10-30%, depending on each particular application (how often does it calls functions). Realistically, the speed gain would be around 10 to 12 per cent (how do I get these numbers, below).
So why did Apple used an outdated ABI for a modern operating system? Frankly, I don't know the reason. About the best one I have heard - it saved Apple a few months in the Mac OS X development time so they didn't have to do massive updates to its NeXT-derived tool chain.
There are signs of change though -- the recent update to GCC, the compiler shipped with OSX, allows it to perform so-called -mdynamic-no-pic optimization, which hard-codes the data addresses in the code, so the result is roughly equivalent to the CFM ABI used in Mac OS Classic -- so the GCC itself, compiled with that optimization, is 10% faster. Applications, to take advantage of that, need to be recompiled, so it doesn't affect 80% of the titles already shipped for Mac OS X. Then again, the optimization above only works for executables and not shared libraries.
Either way, there is no way to change the ABI now, as it would break all of the existing applications - which is obviously not what Apple (or us) would want.
And after all, who cares about a 10% speed loss? You can always get a faster Mac, right?
Further reading:
Mach-O Runtime Architecture [developer.apple.com]
CFM-Based Runtime Architecture [developer.apple.com]
Thanks to #macdev regulars and an anonymous Apple engineer for helping me with this article.
Update 10/21: fixed a few phrases in the text to make it more clear; I've also been told OPENstep runs on RISC processors (non-PowerPC) - however, I have not investigated how the Mach-O ABI works there - quite possible it obeys the PowerPC guidelines, although I am pretty sure it does the same as on PowerPC.
Posted by slava at October 21, 2002 03:40 AM
Re:In Case Unsanity Gets /.ed (Score:2, Interesting)
I mean where does Apple go from here? Do they create a 3rd spec so they have to upkeep two non-native formats? Will they have to create three sets of libraries or shims?
Not very forward-thinking Apple.
I have known this for months (Score:5, Insightful)
Just kidding.... Anyway it may or may not be easy/hard to fix... the problem is now that its out there changing the ABI [the C ABI !!! the way functions get called and parameters get passed] is going to break everything. Maybe they can fix it but not at a significant cost to 3rd party software... I could be wrong and not have thought this out well enough though.
Re:I have known this for months (Score:1, Funny)
Sorry Leimy. didn't realize you'd known about this and therefore it shouldn't have been posted. Slashdot editors, in the future please check with this guy before posting any stories.
Re:I have known this for months (Score:3, Interesting)
Perhaps because I look into things and try to tinker and understand them as well as do silly things like assembly language programming I picked up on this sooner than others. This isn't news to a lot of people I hang with...
Sorry if I came off sounding arrogant
Re:I have known this for months (Score:2, Insightful)
This can be said about ANYTHING and EVERYTHING that gets posted to Slashdot. Why don't we just close down the site, call it a day, and stop wasting our time? Google, after all is all we need, right.
Yeah...any-way. Consider that the stories themselves are only half of what makes Slashdot an interesting place. I come for the DISCUSSION more than the stories.
>This isn't news to a lot of people I hang with...
I hate to break it to you, but the people who read Slashdot are a lot more diverse than just the people you happen to hang with. I come here for the occasional interesting science article (and the DISCUSSION that follows). I don't know shit about CS, although I'm interested in computers, and particularly Macs. This is the first I've heard of this issue (I'm sure loads of other Slashbots can say the same. I may not ever have heard about this issue if it wasn't for this Slashdot story. Please accept my formal apology.
>Sorry if I came off sounding arrogant
You did. You're forgiven. Don't let it happen again.
-ac
Yay! FUD! (Score:5, Insightful)
There is no reason that an operating system can't support multiple ABIs. That means that New applications wouldn't work on older versions of the OS, but it certainly doesn't mean that they can't fix the "problem" without breaking current applications.
Re:Yay! FUD! (Score:2, Informative)
Supporting an extra ABI isn't difficult at the execution level provided you have a separate set of libraries or shims like they do for PEF binaries now. That's also how you can run 32 and 64bit apps on the same system.
But what now? Another set of shims?
The whole situation is ridiculous. They should use PEF/CFM natively.
Only if Mac == Motorola (Score:3, Insightful)
Re:Wonder if they tried to keep it a secret? (Score:5, Insightful)
Seeing as the systems incorporates Darwin which is open source I don't really think they could keep this a secret. Anyone can download Darwin and see the implementation of the ABI. Also they have been using GCC for some time and the implementation of the ABI would also be exposed there.
At the fundamental levels of OS X, below the GUI, there is very little that Apple can dissemble about. It is OSS. Anyone can download it and read the code.
MarkX
Re:Wonder if they tried to keep it a secret? (Score:1)
Yeah, an open sourced "secret" (Score:4, Insightful)
Re:Wonder if they tried to keep it a secret? (Score:2, Informative)
No. The ABI is documented with the developer tools - without it you'd have to try and reverse engineer it from existing binaries to write assembly code.
Re:Wonder if they tried to keep it a secret? (Score:2)
a likely manner in which this will be corrected... (Score:5, Interesting)
However, it's not quite as easy as rolling it into that architecture, as they wil probably rely of the 32-bit PPC compatibility mode of the 970 to bring along a lot of the existing baggage, ruling out a wholesale conversion to another API. Which means they will either implement a foundation to migrate toward the new API, or invoke yet another API (probably 64-bit 970 only) that uses the appropriate model. Either way, it will be some years (if ever, as we can still code 68X apps using an API from decades ago that run under emulation on OS X) before we see an efficient API in widespread use.
In any event, they will certainly retain a CISC-oriented API in the OS X stable of architectures, if only to be able to continue to wave the specter of an open source OS X on X86 in front of Microsoft, as sort of a "mutual assured destruction" weapon to prevent Microsoft from wiping them out, and possibly as a negotiating tool in keeping Microsoft coding for the Mac.
But -- since Apple is pretty well (apparently) hamstrung on making great strides in hardware performance over the next year or so, maybe they will push the software changes as the next best way to get needed speed. It wouldn't be the first time Apple capriciously honked off developers by changing all the rules and rendering years of development obsolete.
And the whole thing may be moot, as it appears that one can get equivalent performance improvement by compiling with gcc3.
Re:a likely manner in which this will be corrected (Score:3, Informative)
Possibly fixed with a 64-bit OS X? (Score:5, Interesting)
It seems that Apple could easily correct this when they update OS X for a 64-bit chip (namely the PowerPC 970). Applications will need to be recompiled to be 64-bit anyway, so why not update the ABI in the process? It would certainly be incentive for developers to update their apps...
Imagine:
Apple:"Update your apps to 64-bit and see a 10% performance gain."
(Of course most apps really won't need to be 64-bit, but this would be incentive for developers to update them and users to buy new machines.)As for Carbon, it states in the article that only Mach-o binaries use the CISC-style ABI, Carbon is not affected and uses a PowerPC-style ABI. This could be a way to "prove" his theory that you could get a 10-12% performance increase. Build two test apps, one in Cocoa and one in Carbon and then compare them to see if there really is a 10-12% speed difference.
Re:Possibly fixed with a 64-bit OS X? (Score:1, Informative)
I'm confused (Score:2)
Re:I'm confused (Score:5, Informative)
1. Branch relative addressing mode - the immediate displacement operand is sign exteneded and added to the current instruction address to produce the branch target address. So, PC relative addressing. There is no need for a programmatically accessible program counter because this is all done by the branch execution unit. Single 32-bit instruction.
2. Branch conditional to relative addressing mode - same as branch relative addressing, except that the branch is only executed if the proper condition codes are set. Single 32-bit instruction.
3. Branch to absolute addressing - the operand address is sign extended and used as the branch target. As the name implies, this is absolute addressing. Only problem is, the operand address is only 23 bits wide in a 32-bit implementation, and with the zero pad, it gives only 25 bits of absolute address (word alignment required). So, if you absolute address anything, you can only absolute address 25 bits worth of the address space.
4. Branch conditional to absolute - same as regular absolute addressing, except that you have to encode condition codes, so the operand address is nowo only 13 bits if I read the diagrams correctly, meaning that you can only absolutely address 15 bits of address space with the zero pad.
5. Branch conditional to link register - if you clobber the link register, you can branch to a 32-bit address. Of course, you have to clobble the link register, so I would think this would be most helpful in returning from a function call, not going to it, since the link register holds the return address. And if you use it forward instead of returning, you have to load the link register.
6. Branch conditional to count register - same as link register branching as above.
All of that said, the reason that the Mac OS ABI uses PC relative addressing is because the only way to fully address a 32-bit address space is to do PC relative addressing. According to this book, there is no two instruction width branch, eg a branch instruction which encodes an entire 32-bit absolute address in two 32-bit words (one word for branch encoding and condition codes, one word for the whole 32-bit address).
This leads me to believe that there is no way to do all absolute addressing on PowerPC unless you implement new instructions (which will take more time to get to the processor, and to decode) or limit yourself to 15 or 25 bits of the address space.
So, the short version is that that there is no way for the Mac OS ABI to do absolute addressing.
Re:I'm confused (Score:1, Insightful)
Re:I'm confused (Score:4, Interesting)
Point taken. Section 4.2.3.1 of the same book is "Integer load and store address generation".
1. Register indirect with immediate index addressing for integer loads and stores - In this case, you get a 16-bit index in the instruction added to the value in a general purpose register, which is used to compute the effective address.
2. Register indirect with index addressing for integer loads and stores - this is the same as above, except that two registers are used and there is no encoded index.
3. Register indirect addressing integer loads and stores - use just one general purpose register as an address for a load or store.
So, the point is that in every case, some form of relative addressing is used. In order to make relocatable code, ie code that can be linked happily with other binary objects, you have to have some sort of reference address, and PC-relative addressing is the only way to do this.
Even though there is no PC-relative addressing mode, the only way to guarentee that the relative addresses used in different object files won't clash is to do PC-relative. The fact that this is not easy on the PowerPC doesn't make it any less necessary.
Re:I'm confused (Score:5, Informative)
This is wrong. The PowerPC ABI, as defined by IBM, uses r2 as a TOC (Table of Contents) pointer. The PC is never needed or used as all data space references are made relative to the TOC, not the PC. Apart from being faster, this has several other advantages, not the least of which is that one copy of code can have multiple data contexts without involving VM.
int foo;
int bar(void) { return foo; }
with macho:
_bar:
mflr r0,lr
bl *+4
mflr r2
mtlr r0
addis r3,r2,ha16(foo)
lwz r3,lo16(foo)(r3)
blr
with IBM conventions:
lwz r3,foo(rTOC)
blr
Re:I'm confused (Score:2)
Re:I'm confused (Score:5, Interesting)
One problem with TOC is that is you are limited to 16K external addresses. Offset "foo" in the TOC example is 16 bits, and the low two are zero. With 64-bit addressing I suppose that drops to 8K externals.
Another characteristic calling a separately compiled function requires that you load a different TOC. The PC-relative scheme requires that you load one value: the PC; the TOC scheme requires that you load two new values: the new PC and the new TOC.
On the plus side, TOC makes shared libraries easier to manage because external addresses are bound to a non-shared data area.
Re:I'm confused (Score:2)
Re:I'm confused (Score:2)
But the TOC entries are addresses, which are 4 or 8 bytes long. Unless you manage to find addresses which can overlap due to common bit patterns, you have to divide the 64K maximum TOC size (the offset of an lwz instriction is 16 bits long) by 4 or 8.
As for alignment, section 6.4.6.1 here [ibm.com] indicates that one response to unaligned integers is an alignment exception. So you can load unaligned, and the PowerPC may fix things up in hardware, but if it doesn't your O/S is expected to simulate the instruction.Re:I'm confused (Score:2)
"processorts?" (Score:3, Funny)
Why, exactly, do they expect people to pay money for this again?
Re:"processorts?" (Score:2, Funny)
can't be bothered to put a spellchecker into their story posting system.
Get yourself a machine to run OSX on and every app written in cocoa can spell check every text entry field. (including my web browser)
-ZSome ways to get away from PIC code (Score:5, Informative)
2. If you are going to use an extern variable in a tight loop, don't use a local variable and assign it after the loop.
3. Pass the option -mdyanmic-no-pic to gcc if the source is in the final program because it does not work in a boundle or a dynamic library (or framework).
The AIX ABI/PEF ABI uses a register called the TOC for PIC code but it is stored with the function reference so you lose one register if the Darwin ABI goes over to the PEF ABI. You get one more register to play around with if you do not use extern or static variables.
Re:Some ways to get away from PIC code (Score:2)
Of Babies and Bath Water. (Score:5, Insightful)
First look at the most crucial benefits of the runtime environment. Mach supports an efficient and flexible framework for multiple memory objects. Objc leverages this by supporting the efficient mapping and unmapping of new bundles.
You may think of a bundle as a set of related objects in a language like Java, but don't take that analogy too far. The concepts of delegation, and protocols, usually mean that different bundles of code have clean interfaces that do not require recompilation when one or the other changes. Sometimes even knowledge of each other's type is irrelevant.
In any case, the best design for objc applications is a collection of separate UI definitions or nib files, and one or more libraries of code which are searched and loaded as needed at runtime.
Statically linked code, is more efficient for some tasks, but in the context of good objc design does not fit very well. Text which is statically linked is more fragile, it must be recompiled more often. It can also take more time to initialize and load; using late binding and lazy loading, only the sections to text and definitions of objects actually called will be mapped in memory.
Position independent code is absolutely needed for this kind of flexibility at runtime. The gcc compiler grew up on CISC, on 32 bit or 16 architectures. Position independent code, had to be relative to something, and the most commonly useful location was always "You are here", the program counter.
I'm not sure whether a less frequently changed relative address such as a start of bundle address makes more sense for gcc on ppc. In any event, however, I would certainly not be willing to categorize Apple's reliance on position independent code as a bug. By default, use pic.
Still stuck with 68K emulation? (Score:3, Interesting)
Some of the educational software that a lot of schools use is still built with MS-DOS 5 and Apple System 7.5 in mind. Until you can get some of these developers to move to something a little more modern, you will still have a lot of excess baggage to carry in your OS. Perhaps that is why Apple is moving to systems that won't boot MacOS 9 in January 2003.
Re:Still stuck with 68K emulation? (Score:3, Informative)
Re:Still stuck with 68K emulation? (Score:2, Interesting)
Huh? (Score:1)
Re:Still stuck with 68K emulation? (Score:1)
so yep i am fine with this. if they break compatability with my flavourite photoshop i will be pissed.
Ugh, go back to using PEF/CFM!! (Score:2, Informative)
There are many reasons for this. Not only are there tools already available to handle PEF/CFM, you wouldn't need the whole PEF interpreter w/shim libraries to run PEF Carbon apps!
Big deal. (Score:5, Insightful)
Seriously, the x86 Linux ABI is probably worse off...different (worse) byte alignment from Windows, the abovementioned everything-goes-on-the-stack....
Not really all that suprising (Score:1)
Re:Not really all that suprising Unix grew up on x (Score:2)
portability (Score:5, Interesting)
It seems that they can emulate a pc-register in a risc architecture, but could they (easily) do it the other way around? Perhaps this is the real reason why they kept the abi the way it is: so they could easily port os x to whatever platform they like...
GCC 3 (Score:4, Interesting)
why don't they use PowerOpen (Score:2)