A Marklar Question

[Vlade]

I think marklar has alot of potential, but I have herd that software will need to be recompiled to x86 code, therefore useless until developers update their programs. Now what if the next version of Project Builder and Code Warrior compiled 2 sets of code, one for the PPC, and one for the x86. We could wait about a year after the new compilers were developed, so when its time to switch to x86 (if it is ever time to switch), MOST programs will be ready.

I know there are a lot of potential problems with this, but I'm sure they could be fixed pretty easily.

 

[Vlade]

Marklar has another Marklar, what came first, Marklar's Marklar or the Marklar on Marklar?

If you haven't seen that south park episode ignore this message.

 

[FattyMembrane]

as long as none of the code is written in assembly, pretty much all cocoa apps could be ported to x86 with a recompile, no editing necessary. the more apple converges the carbon and cocoa frameworks, the easier it will be to port carbon apps. the thing is, why wouldn't apple look for another 64 bit chip if the 970 does not measure up? it seems like a 64 bit x86 would be pushing its luck at best, but maybe i'm wrong.

 

[gbojim]

Not that easy

You can already compile binaries to different architectures with Code Warrior. That is not the problem. Getting your code to compile is only the beginning.

The biggest issue is tuning and debugging. Been there. Done that. It is not fun.

Think about someone like Adobe where the Mac development team knows how to tweak for PPC but not Intel or AMD. So they have a big learning curve. They have to decide whether to release a slow product early - everybody says the app sucks, or they take their time and nobody wants to buy a new Mac because apps aren't available - everybody says the Mac sucks. Add to that the fact that they just completed a major conversion from OS 9 to OS X and my bet is Adobe drops Mac support.

It just is not a winning business strategy.

 

[Catfish_Man]

Including 2 versions of the code in each application bundle (which is easy to do in OSX, a relic of cross platform NeXTStep) would make the file size a good deal larger. Also, all Altivec code would have to be rewritten to use MMX/SSE/SSE2/3dNOW!/3dNOW Pro/etc... (none of which are as good as Altivec, except for double precision SSE2), as well as all assembly code and several of the developer tools.

 

[topicolo]

it could work though. The transition from 68k to PPC was exactly as you guys described it. Programs came with two binary versions and were fairly large, but not twice as large (data files don't have to be recompiled, just the code) and the operating system itself also contained an emulator that emulated a 68k on PPC machines so that old 68k apps could run seamlessly on the new chip.

The transition worked out fine (you're using a PPC aren't you?) and so should the Marklar transition if Apple so chooses.

 

[Catfish_Man]

Originally posted by topicolo
it could work though. The transition from 68k to PPC was exactly as you guys described it. Programs came with two binary versions and were fairly large, but not twice as large (data files don't have to be recompiled, just the code) and the operating system itself also contained an emulator that emulated a 68k on PPC machines so that old 68k apps could run seamlessly on the new chip.

The transition worked out fine (you're using a PPC aren't you?) and so should the Marklar transition if Apple so chooses.

The hard part is emulating PPC on x86. To date, no one has been able to do it at any acceptable speed. IIRC, some features for 68k emulation were put in PowerPC to aid the transition. If Apple could pull a reasonably fast PPC emulator for x86 off, then yeah, it might work (although I still have a hard time seeing why Apple would want to switch to x86. Intel is trying to replace it with IA-64, and AMD is trying to replace it with x86-64, probably transitioning to something else later on).

 

[Vlade]

When you guys say "emulator" are you talking about the same emulating as Virtual PC does? If so it would be SO SLOW. I mean changing the machine code to x86.

 

[Eniregnat]

Do you mean:
When you guys say "Marklar" are you talking about the same emulating as Marklar does? If so Marklar would be SO SLOW. I mean changing the Marklar to Marklar.

Sorry, Marklar couldn't help myself.- I mean help marklar.

I took their gist to be that on the latter posts.

I once met the guy that programmed the FPC, floating point calculator, for the early Mac's. In conversation, he said that he thought that most Mac code could be recompiled for other systems with only about 10-20% of the code needing change. That was then, on older OSs. I would think that memory addressing and how system resources are accessed would be the biggest stumbling blocks.

Big money for the gal or guy that develops a cross system translator that deals with all the specific buggy stuff as well.

I don't see Adobe dropping Mac support, but I do see their software sweets slowly being combined into larger single programs. Illustrator and PhotoShop would be a natural bundle, think of the code sharing. I know that they are two programs that work together, but it is possible to see them as one, then again, Adobe already recycles a lot of code, so why combine.

For those that have compiled code for more than one OS, where do the bugs usually pop up? Are they of similar issue(s)? Can you predict where the problems will occur in the code?

 

[gbojim]

Originally posted by Eniregnat
For those that have compiled code for more than one OS, where do the bugs usually pop up? Are they of similar issue(s)? Can you predict where the problems will occur in the code?

Usually the problems exist due to minor inconsistencies in the OS libraries between platforms. Most people will say that its Apple's (in this case) responsibility to make sure the libraries are exactly the same. However, there are some things PPC can do that x86, AMD, whatever can't. So you have to work around it, and Apple has to make sure they optimize for maximum performance. In addition, the compilers have to take advantage of those things.

A good example, although not quite the same, is the Carbon APIs in OS X. Apple cleaned some things up. Unfortunately, it broke some code for some folks.

The bigger problem is the optimization. That will be the main issue because the app developers have to get used to the library functions to determine the best way to code the app. It just takes a lot of time, which of course companies have to pay for.

If you would like a quick example and you know anything about programming in Visual Basic, create a small app that cubes a number in a loop that executes 10,000,000 times.

Try it this way and time it: x = 10 ^ 3

Then try it this way and time it: x = 10 * 10 * 10

You will find that the second method executes in about 30% of the time taken by the first example. It is not a practical program, but it will give you an idea of how inefficient the math library is.

 

[Eniregnat]

I understand.
Thanks(^3) for the elucidation.

 

[biscool]

But why would apple switch to x86 now? At the end of it's life? x86 is on the way out, ppc 970 is apple's glorious 64bit future....