Slashdot Mirror
Mac OS X Built For CISC, Not RISC
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.
that apple knows what their doing, and probably had a very good reason or doing what they did. I mean its not like they havent had the past four years to change it or anything, but whatever.
I want 2D games back.
Uhm... This is news? I am not shocked at all. In order to get the product out sooner rather than later they stuck with the old ABI that was used for Motorola 68k[probably wrong but I have had no coffee yet]. Anyway some people say that the performance loss as a result of this "corner cutting" may be up to 7 cycles per function call which just means we should all write our code as inlines and macros :).
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.
And supposedly, they can't fix it now without breaking all existing applications.
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.
Who says they need to "fix" it? Perhaps Motorola may be losing a big customer in the future... I've heard from more than one source now that big changes may be coming in Mac hardware... Absolutely all rumors of course, but this fact fits in nicely with what I've already heard...
Please consider making an automatic monthly recurring donation to the EFF
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
The tweaking is at the Kernel/OS level so applications can run without modification (in theory). My guess is some apps will need patches while others will be okay. A perfect example of this is apps that run under 10.0 and 10.1 but not 10.2.
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.
The code is open source and the gcc 3 code is open source. It doesn't appear to me they are hiding anything.
Its not about branching. Its about data references using PC relative addressing. The PowerPC has no PC relative data addressing modes.
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.
This is mindblowingly unimportant. Can *anyone* think of *any* company that has a perfect ABI? No, because processors evolve, and the ABI has to stay the same. When I write an x86 program on my Linux box, it pushes *all* the arguments onto the stack. Is that the best way to do things? No. Is it done anyway? Yup. Does anyone go into a tizzy about it? No.
Seriously, the x86 Linux ABI is probably worse off...different (worse) byte alignment from Windows, the abovementioned everything-goes-on-the-stack....
May we never see th