AppleInsider › Forums › Mac Hardware › Future Apple Hardware › Complex chip shift from Samsung expected to take Apple 12-18 months
New Posts  All Forums:Forum Nav:

Complex chip shift from Samsung expected to take Apple 12-18 months - Page 3

post #81 of 100
12/6/12 at 6:40am
Quote:
Originally Posted by melgross View Post


The offer, assuming it was true, that was rejected, was that Apple take over ALL of TSMC's production. Qualcomm supposedly made the same offer, which was also rejected.
TSMC is going to build a new chip plant in upstate NY. There are rumblings that this is for Apple's production. True? Maybe. But Apple does give billions each year to manufacturers for this very thing. I would expect that Apple would do the same thing here.

 

Actually it's also rumored that Apple has bought into GF production.  These are all rumors until a press release happens.

 

There are good reasons for both Apple and Qualcomm to go the IDM route and good reasons to stay fabless, perhaps with 10-15% equity stake in a couple of the pure-play foundries.

Reply
Reply
post #82 of 100
12/6/12 at 6:58am
Quote:
Originally Posted by melgross View Post

I like to remind people that AMD got lucky with Intel's Netburst. Intel thought they could succeed with their superior fab tech alone, but they couldn't. When the industry got hit with leakage, and other problems at the 90nm level, Intel was hit the worst because of their advanced CPU speeds. AMD, with their always poorer fabs, went wide in order to compete (IBM had done about the same with the PPC, though their fabs were much better than AMD's). So for dumb luck, AMD had the lead for about two years.

 

If you suck even dumb luck won't help you.  Taking advantage of luck requires the capability to do so and the agility to press home the advantage.

 

 

Quote:
GF isn't doing all that well, which is why the country that bought it, forgot their name right now, is trying to get investors. It's going to cost GF megabucks to keep relevant, and they don't want to spend them.

 

GF is losing billions because their Abu Dhabi owners have stated that they intend to take on Intel at the 14nm process.  So losing 3-4B in the last few years is part of the plan and rumor has it that the owner is willing to go as high as $20B losses IF the plan shows profitability by 2015 but yeah, finding additional investors to share risk is always a good thing.

 

They are now the #2 pure play fab.  If they sucked as badly as you keep insisting that wouldn't happen.

 

 

Quote:
I'm sorry, but I just don't agree with you on the last bit. It's nice to be doing 28nm, but next year, that will be behind. Apple needs to move to 22 by then. Having a roadmap is useless. Everyone has a roadmap. It's traveling down that road that's the problem.

 

28nm is behind THIS year if you're going to compare yourself against Intel 22nm process capabilities.  UMC has stated they have a working 20nm planar process today that nobody is interested in using.  This might be lies but TSMC was annoyed that they bought into building 20nm planar capacity and then everyone wanted to go 3D.

 

Given that UMC has essentially joined the IBM fab family the odds are they can make it to 14nm.  Probably Intel will be the only one producing 14nm chips in 2014 but GF, UMC, TSMC will be pushing hard to get there by late 2014 or early 2015.

 

 

Quote:
There's also no guarantee that Apple will have enough capacity by themselves, or that their new plants will work well, or on time, no matter who they buy. And then they have to contend with more staff, etc. Buying capacity from other players is much better. And when you have a very large account, you can have that company expand more easily, as Apple does now with their manufacturers.

I don't understand why you insist that Apple has to do this. Dell, HP and others don't need to make their own chips. Their successes and failures have nothing to to with it either. Apple's success as a chip company is in their designs, not in the manufacture, and that will remain so.

 

I don't INSIST they do this.  I state that has more than sufficient technical capability to pursue becoming an IDM if they wish vs being fabless.  It's not as impossible as you seem to think.

 

The ONLY compelling reason that I can think of for Apple to stay fabless as they are is because Intel's 14nm mobile line up looks very compelling.  No reason to go IDM and then jump ship to Intel in the 2014-2016 timeframe.  However, if they stay the ARM course then I see a lot of advantages to being an IDM over fabless.  

 

The middle road is to buy 10% equity in UMC, 10% equity of GF (if Abu Dhabi is willing to sell), etc and have part ownership in one or more pure-play foundries with guaranteed amounts of production from their advanced fabs.  This probably gives them the most agility but depends on the foundry management to not suck.

Reply
Reply
post #83 of 100
12/6/12 at 7:15am
Quote:
Originally Posted by sr2012 View Post


But do you see that it is ~unlikely~ that Intel would fab ARM for Apple while also doing its x86 for mobile development? I see it as ~unlikely~, though I see it also as ~Intel's best choice~ :: cover all bases.
The main risk, outside of political decisions, is that ARM could say Intel ripped off ARM in doing x86 for mobile because Intel fabbing and customising ARM could have "fed" Intel's x86 endeavours. Of course, Intel could easily take care of this, hopefully ethically, in the first place.
What do you think?

 

No, Intel still holds an ARM architectural license.  They're covered.

 

The only reason that Intel would have to fab ARM chips is if Apple demanded that for a 2014 iPad design win.  That strikes me as somewhat unlikely given it would take some time for Intel to get any ARM production going.  Plus, an Apple A8 based on the 22nm Silvermont CPUs probably isn't that much better than the 28nm ARM Cortex-A15 based A7s they'd replace.

 

If you're going to go Atom for the iPad the iPhone needs to follow shortly after.  14nm is probably the right point for the whole iOS product like to go Intel IF it does.  I think it will but that's still 2-3 years away.  

 

MAYBE 22nm Silvermont iPad A8X for the iPads in 2014 followed by 14nm Airmont iPhone A9s in 2015.  I also wonder if Apple and Intel can agree on branding of the CPUs.

Reply
Reply
post #84 of 100
12/6/12 at 9:20am
But could Apple switch to Intel in 2 years? As in this would be a massive turnaround for iOS.
Reply
Reply
post #85 of 100
12/6/12 at 6:19pm
Quote:
Originally Posted by sr2012 View Post

But do you see that it is ~unlikely~ that Intel would fab ARM for Apple while also doing its x86 for mobile development? I see it as ~unlikely~, though I see it also as ~Intel's best choice~ :: cover all bases.
The main risk, outside of political decisions, is that ARM could say Intel ripped off ARM in doing x86 for mobile because Intel fabbing and customising ARM could have "fed" Intel's x86 endeavours. Of course, Intel could easily take care of this, hopefully ethically, in the first place.
What do you think?

If the analyst who said that his sources said that Apple is in talks with Intel to produce "A" chips for them has actual information, then no, I wouldn't think it unlikely. Intel needs to realistically consider whether doing this for Apple will hurt its chances or not. But the total number of chips for Apple could sway its thinking.
Reply
Reply
post #86 of 100
12/6/12 at 6:22pm
Quote:
Originally Posted by nht View Post

Actually it's also rumored that Apple has bought into GF production.  These are all rumors until a press release happens.

There are good reasons for both Apple and Qualcomm to go the IDM route and good reasons to stay fabless, perhaps with 10-15% equity stake in a couple of the pure-play foundries.

I haven't seen that one.
Reply
Reply
post #87 of 100
12/6/12 at 6:32pm
Quote:
Originally Posted by nht View Post

If you suck even dumb luck won't help you.  Taking advantage of luck requires the capability to do so and the agility to press home the advantage.

That lack of capability is why after two years of seeing Intel founder, as soon as Intel changed their course, AMD was back to being second rate.

Quote:
GF is losing billions because their Abu Dhabi owners have stated that they intend to take on Intel at the 14nm process.  So losing 3-4B in the last few years is part of the plan and rumor has it that the owner is willing to go as high as $20B losses IF the plan shows profitability by 2015 but yeah, finding additional investors to share risk is always a good thing.

They are now the #2 pure play fab.  If they sucked as badly as you keep insisting that wouldn't happen.

It's because of those expenses they they want to sell off the majority of their stake. They didn't understand how much this business costs.

Quote:
28nm is behind THIS year if you're going to compare yourself against Intel 22nm process capabilities.  UMC has stated they have a working 20nm planar process today that nobody is interested in using.  This might be lies but TSMC was annoyed that they bought into building 20nm planar capacity and then everyone wanted to go 3D.

Given that UMC has essentially joined the IBM fab family the odds are they can make it to 14nm.  Probably Intel will be the only one producing 14nm chips in 2014 but GF, UMC, TSMC will be pushing hard to get there by late 2014 or early 2015.

In mobile, 28nm is the leading edge process. What mobile SoC is on anything smaller?


I don't INSIST they do this.  I state that has more than sufficient technical capability to pursue becoming an IDM if they wish vs being fabless.  It's not as impossible as you seem to think.

The ONLY compelling reason that I can think of for Apple to stay fabless as they are is because Intel's 14nm mobile line up looks very compelling.  No reason to go IDM and then jump ship to Intel in the 2014-2016 timeframe.  However, if they stay the ARM course then I see a lot of advantages to being an IDM over fabless.  

The middle road is to buy 10% equity in UMC, 10% equity of GF (if Abu Dhabi is willing to sell), etc and have part ownership in one or more pure-play foundries with guaranteed amounts of production from their advanced fabs.  This probably gives them the most agility but depends on the foundry management to not suck.
[/quote]
Reply
Reply
post #88 of 100
12/6/12 at 11:36pm
@melgross some very good points. Interesting times. The switch to Intel by Apple could pay off big time, but the level of risk involved for Intel and Apple is quite high. Global Foundries I think is not in play here because I don't think they have the wherewithal to take on such a challenge. Also, without Steve Jobs I wonder who might corral the forces of Intel and Apple to pull off x86 mobile for iOS devices in 2014-2018.

Still, I've been extremely impressed, even falling in love with, shall we say, Android 4.x.

If Intel brings some A (pun unintended) game to the table I see it benefitting Android more so than Apple unless Tim Cook makes a big, big push to make iOS and OSX on Intel x86 for mobile really shine.

I'm just conjecturing but 2013-2018 theoretically Apple should transition to x86 for mobile if Intel can deliver the goods. This is because then MacBook Air and other Macs can go to "x86 on mobile" and even "converged" devices ... eg. a fully-touch-enabled MacBook Air that runs OSX and iOS apps. So standardising on Intel and Intel's fabs would give Apple a solid 5 years of kickass stuff. Again, without Steve Jobs, I'm not sure if the current Apple has such, cahones, shall we say.

Come to think of it, what people are not seeing is that if Apple went x86 for mobile, the unification and convergence of iOS and OSX could lead to some stunning, stunning products out of Apple, with the solid reliability of Intel's fabs. This is as I mentioned, a high risk, high payoff endgame of the decade. Nonetheless, I've outlined above and previously why this is probably not going to happen.
Edited by sr2012 - 12/6/12 at 11:42pm
Reply
Reply
post #89 of 100
12/11/12 at 12:15pm
Quote:
Originally Posted by sr2012 View Post

@melgross some very good points. Interesting times. The switch to Intel by Apple could pay off big time, but the level of risk involved for Intel and Apple is quite high. Global Foundries I think is not in play here because I don't think they have the wherewithal to take on such a challenge. Also, without Steve Jobs I wonder who might corral the forces of Intel and Apple to pull off x86 mobile for iOS devices in 2014-2018.
Still, I've been extremely impressed, even falling in love with, shall we say, Android 4.x.
If Intel brings some A (pun unintended) game to the table I see it benefitting Android more so than Apple unless Tim Cook makes a big, big push to make iOS and OSX on Intel x86 for mobile really shine.
I'm just conjecturing but 2013-2018 theoretically Apple should transition to x86 for mobile if Intel can deliver the goods. This is because then MacBook Air and other Macs can go to "x86 on mobile" and even "converged" devices ... eg. a fully-touch-enabled MacBook Air that runs OSX and iOS apps. So standardising on Intel and Intel's fabs would give Apple a solid 5 years of kickass stuff. Again, without Steve Jobs, I'm not sure if the current Apple has such, cahones, shall we say.
Come to think of it, what people are not seeing is that if Apple went x86 for mobile, the unification and convergence of iOS and OSX could lead to some stunning, stunning products out of Apple, with the solid reliability of Intel's fabs. This is as I mentioned, a high risk, high payoff endgame of the decade. Nonetheless, I've outlined above and previously why this is probably not going to happen.

Well, I'm not impressed by Android. Even the Nexus lines are having problems with getting updates. The Nexus 7 got screwed by the latest update. It's a clunky, creaky system which is becoming more difficult to keep up to date as time goes on.

With Intel, I don't think they would have an interest in rabbi g for anyone other than Apple. I don't know if they would even want to do it for them. But app,e would, at least, be willing to pay for a large part of the fab. Only other chip makers have been willing to do that. I don't know if I would want to see iPads on x86. I don't see a major advantage in that. iOS is designed around the capabilities of ARM. Moving to x86 would require another wrenching move for developers. Right now, apps for the phone and tablet can be developed easily together, to be a universal app, working properly on both. We would be giving that up. People who say that it's just a re-compile don't know what they are talking about.

While I understand what Microsoft is trying to do with the Pro, I also understand why. Apple doesn't have that need.
Reply
Reply
post #90 of 100
12/11/12 at 9:08pm
Quote:
Originally Posted by melgross View Post

Right now, apps for the phone and tablet can be developed easily together, to be a universal app, working properly on both. We would be giving that up. People who say that it's just a re-compile don't know what they are talking about.

 

Hmm...I've said that a few times.  But I guess you know what you are talking about regarding software better than a dev.  

 

Apps that stick to the core SDK it would literally be that simple.  For apps that use NEON code (either via arm intrinsics or assembly) or other ARM assembly code then it would require work to target both ARM and X86.  Relatively few apps do this.  Note that if you are doing things like this you ALREADY have to make sure you understand the differences between the ARMv6 (well not so much anymore), ARMv7, ARMv7s, etc targets, write the appropriate code blocks (via #ifdefs) so it can magically* get compiled into a fat binary by Xcode.  If you're doing this anyway then adding a block for X86 execution is par for the course for the kind of app you are writing and binaries would get a little fatter but it would still magically happen (even more magically for most devs since they'd have to do practically nothing).

 

In any case, every time you run on the simulator you target X86 so when you do stuff like this typically you also have a vanilla (aka slower) C/ObjC version of the algorithm to test with within the simulator.

 

But obviously I don't know what I'm talking about and there doesn't already exist an x86 target built into XCode with x86 versions of the iOS frameworks and 90% of apps aren't already run at one time or another on the x86 platform because devs never ever use the simulator.  /s

 

Actually that's semi true in as much as testing on real hardware is always better but still I would guess 90% of apps in the app store would run cleanly in the simulator (and therefore on X86).  

 

I would also guess a good number of devs did use the simulator to try their apps out the 640x1136 rez before the iPhone 5 announcement via the resolution hack that was circulating around the dev community.

 

--

 

* sometimes the magic ends in a tragic link error "Undefined symbols for architecture armv7" when you are trying to update an old app using a 3rd party library to current standards, but I digress...

Reply
Reply
post #91 of 100
12/11/12 at 10:02pm
Quote:
Originally Posted by melgross View Post

Well, I'm not impressed by Android. Even the Nexus lines are having problems with getting updates.

Nexus 7 and 10 have no issues with getting 4.0, 4.1 and 4.2 ~ while some grumblings occur in forums, my Nexus 7 has been almost as flawless as an iPad.

Plus rooting Nexus 7 is easy and one unleashes the full power of Android.

Android < 4.0 yes is a disaster. Android > 4.0 = Watch out 2013.
Reply
Reply
post #92 of 100
12/12/12 at 5:36pm
Quote:
Originally Posted by nht View Post

Hmm...I've said that a few times.  But I guess you know what you are talking about regarding software better than a dev.  

Apps that stick to the core SDK it would literally be that simple.  For apps that use NEON code (either via arm intrinsics or assembly) or other ARM assembly code then it would require work to target both ARM and X86.  Relatively few apps do this.  Note that if you are doing things like this you ALREADY have to make sure you understand the differences between the ARMv6 (well not so much anymore), ARMv7, ARMv7s, etc targets, write the appropriate code blocks (via #ifdefs) so it can magically* get compiled into a fat binary by Xcode.  If you're doing this anyway then adding a block for X86 execution is par for the course for the kind of app you are writing and binaries would get a little fatter but it would still magically happen (even more magically for most devs since they'd have to do practically nothing).

In any case, every time you run on the simulator you target X86 so when you do stuff like this typically you also have a vanilla (aka slower) C/ObjC version of the algorithm to test with within the simulator.

But obviously I don't know what I'm talking about and there doesn't already exist an x86 target built into XCode with x86 versions of the iOS frameworks and 90% of apps aren't already run at one time or another on the x86 platform because devs never ever use the simulator.  /s

Actually that's semi true in as much as testing on real hardware is always better but still I would guess 90% of apps in the app store would run cleanly in the simulator (and therefore on X86).  

I would also guess a good number of devs did use the simulator to try their apps out the 640x1136 rez before the iPhone 5 announcement via the resolution hack that was circulating around the dev community.

--

* sometimes the magic ends in a tragic link error "Undefined symbols for architecture armv7" when you are trying to update an old app using a 3rd party library to current standards, but I digress...

I love it when I read that, and I love it when a developer comes up on stage and says: "It took just a weekend to get it working, that's so cool!" And then takes another six months to get the product out. Yes, everything works so easily. All the details port over so smoothly. And this happens most of the time! Amazing!!!

I used to write software for the VAX and other machines, so I know something about it. The larger the program gets, the more that needs to be fixed. It's easier to go from ARM to x86 because of the differences in the power of the chips. But goi g the other way, for a big, complex program may not be as easy.

As far as the iPhone and iPad go, they are basically the same except for resolution. A lot simpler than making that app work across platforms, which was all I was pointing out.
Reply
Reply
post #93 of 100
12/12/12 at 5:38pm
Quote:
Originally Posted by sr2012 View Post

Nexus 7 and 10 have no issues with getting 4.0, 4.1 and 4.2 ~ while some grumblings occur in forums, my Nexus 7 has been almost as flawless as an iPad.
Plus rooting Nexus 7 is easy and one unleashes the full power of Android.
Android < 4.0 yes is a disaster. Android > 4.0 = Watch out 2013.

This doesn't even come close to the number of links I've got about problems with various Nexus devices and updates.

http://www.zdnet.com/android-too-complex-for-its-own-good-7000008535/
Reply
Reply
post #94 of 100
12/12/12 at 9:12pm
  • hmm
  • Keylogger
Quote:
Originally Posted by melgross View Post


This doesn't even come close to the number of links I've got about problems with various Nexus devices and updates.
http://www.zdnet.com/android-too-complex-for-its-own-good-7000008535/


My impression was that carrier bloatware was a major imposition to updates. Is that incorrect?

Reply
Reply
post #95 of 100
12/13/12 at 7:43am
Quote:
Originally Posted by melgross View Post

I used to write software for the VAX and other machines, so I know something about it.

 

I write software today, so I know a little more about it. 

 

Your experience from 30+ years ago means you know very little about modern software development and any arrogant assertions regarding what can and cannot be done and who knows what they are talking about is meritless.

 

Coding for an X86 based iPad and an ARM iPhone for apps that stick to the core SDK will be not be much different than handling the differences between the iPad 3 and the iPhone 3G back when the 3G was still somewhat relevant to app devs (i.e. supporting both iOS 5 and iOS 4 devices at at the same time).  By the time it X86 is a real mobile contender (2014+) the baseline ARM will be 20nm 64 bit processors.  The performance differential will be large but not nearly as large as today and performance per watt probably very close.


Edited by nht - 12/13/12 at 8:06am
Reply
Reply
post #96 of 100
12/13/12 at 2:03pm
Quote:
Originally Posted by hmm View Post


My impression was that carrier bloatware was a major imposition to updates. Is that incorrect?

A major problem is the ski s the various manufacturers put into their products. This causes all sorts of problems. Samsung even had the audacity earlier this year to proclaim that 2.35 with their skin was a better experience than moving to 4.0.

But even Nexus devices are having problems with updates. Some get them right away, and some don't. Some have problems with the updates, and some don't.

The thing about Google, is they they don't care, even slightly about user problems. They're just interested in having as many devices out there as possible so that their Ad based services are used by as many people as possible. So lots of problems ensue. Carriers are a problem, yes, but no more so than the manufacturers.

But it's not entirely their fault. Manufacturers are in competition with each other. Some people seem to think that it's Android against iOS, but that's not really true. It's manufacturer against manufacturer. So they try to differentiate their Android products from each other. The main way is to change the way they look and work. So they do that. The fact that it causes problems is something they don't care about as long as they believe it gives them some advantage against a competitor. Right now, Samsung is doing the best of them, by far. But much of that success seems to have come from their copying of Apple's look and feel. A Samsung UI looks amazingly like Apple's; much more so than plain Android. That's their "Sense" skin.

Google, in a determine to get a lot of these things out there told carriers and manufacturers; "Here it is, do anything you want with it." Which is why it's such a mess.
Reply
Reply
post #97 of 100
12/13/12 at 2:14pm
Quote:
Originally Posted by nht View Post

I write software today, so I know a little more about it. 

Your experience from 30+ years ago means you know very little about modern software development and any arrogant assertions regarding what can and cannot be done and who knows what they are talking about is meritless.

Coding for an X86 based iPad and an ARM iPhone for apps that stick to the core SDK will be not be much different than handling the differences between the iPad 3 and the iPhone 3G back when the 3G was still somewhat relevant to app devs (i.e. supporting both iOS 5 and iOS 4 devices at at the same time).  By the time it X86 is a real mobile contender (2014+) the baseline ARM will be 20nm 64 bit processors.  The performance differential will be large but not nearly as large as today and performance per watt probably very close.

Uh, not 30 years ago, it was a bit more recent than that. I've also done other work. But , yes, it's been almost 15 years since I've done anything professional in software development. Still, you present thing as being easier than they often are. Redoing an app may be easy, on the basic level, but if its anywhere near being big, and complex, they are usually a lot of things that need fixing.

That performance differential is important, no matter what you say. And the differences in architecture between the chip lines will mean that not everything will be easily handled by your software, and will need to be done by hand.

Even if I never worked with software, I would know that not everything works as smoothly as you assert, in every instance. But then, you probably can't understand why x86 software from Windows worked so poorly using an emulator during the years when the PPC was the more powerful chip. And, yes, this isn't emulation. But there are major differences between the families that the above illustrates, and is why it's not always a straightforward process.

If you just admitted that there are bumps in the road sometimes, this would have been over earlier.
Reply
Reply
post #98 of 100
12/13/12 at 5:10pm
Quote:
Originally Posted by melgross View Post

Uh, not 30 years ago, it was a bit more recent than that. I've also done other work. But , yes, it's been almost 15 years since I've done anything professional in software development.

1997? LOL.
Quote:
Still, you present thing as being easier than they often are. Redoing an app may be easy, on the basic level, but if its anywhere near being big, and complex, they are usually a lot of things that need fixing.

Complexity comes in many forms. A small simple program that uses NEON extensions will require effort. A large, complex program that only uses the SDK is insulated from the issues you describe.

Can there be issues? Yes.
Could they be serious? Yes.
Will that be common? Unlikely given I've already told you that devs compile iOS apps against x86 every day.
Quote:
That performance differential is important, no matter what you say. And the differences in architecture between the chip lines will mean that not everything will be easily handled by your software, and will need to be done by hand.

Most apps are written in ObjC against Apple SDKs and are completely unaware of architecture differences between ARM and X86 because XCode does all the heavy lifting.

Again most apps run on X86 TODAY. A fact you steadfastly ignore in your presumed expertise.
Quote:
Even if I never worked with software, I would know that not everything works as smoothly as you assert, in every instance. But then, you probably can't understand why x86 software from Windows worked so poorly using an emulator during the years when the PPC was the more powerful chip. And, yes, this isn't emulation. But there are major differences between the families that the above illustrates, and is why it's not always a straightforward process.

Except that 15 years ago I was responsible for porting C code from the Motorolla 88000 to sparc and part of that effort required writing a 1750A emulator to run on sparc.

So I am quite aware of the differences between emulation and porting.

The reason why window programs was slow on PPC was exactly because of emulation. Windows ported to the Alpha was very performant and my recollection is that it ran well natively on PPC but I personally never saw that. The apps (science data processing...complex but not in a software architecture way) ported to alpha was very fast and although I was never part the development of those apps I didn't hear much screaming and cursing from that team that had to support both x86 and alpha.

Not to mention that the PPC was not that much faster than the equivalent intel chip and not even faster in all respects.
Quote:
If you just admitted that there are bumps in the road sometimes, this would have been over earlier.

If you didn't arrogantly proclaim that folks who state that something that actually happens every day (iOS apps running on x86) isn't a big problem as "not knowing what they are talking about" you wouldn't be made to look the fool.
Reply
Reply
post #99 of 100
12/14/12 at 8:27am
Quote:
Originally Posted by nht View Post

1997? LOL.
Complexity comes in many forms. A small simple program that uses NEON extensions will require effort. A large, complex program that only uses the SDK is insulated from the issues you describe.
Can there be issues? Yes.
Could they be serious? Yes.
Will that be common? Unlikely given I've already told you that devs compile iOS apps against x86 every day.
Most apps are written in ObjC against Apple SDKs and are completely unaware of architecture differences between ARM and X86 because XCode does all the heavy lifting.
Again most apps run on X86 TODAY. A fact you steadfastly ignore in your presumed expertise.
Except that 15 years ago I was responsible for porting C code from the Motorolla 88000 to sparc and part of that effort required writing a 1750A emulator to run on sparc.
So I am quite aware of the differences between emulation and porting.
The reason why window programs was slow on PPC was exactly because of emulation. Windows ported to the Alpha was very performant and my recollection is that it ran well natively on PPC but I personally never saw that. The apps (science data processing...complex but not in a software architecture way) ported to alpha was very fast and although I was never part the development of those apps I didn't hear much screaming and cursing from that team that had to support both x86 and alpha.
Not to mention that the PPC was not that much faster than the equivalent intel chip and not even faster in all respects.

If you didn't arrogantly proclaim that folks who state that something that actually happens every day (iOS apps running on x86) isn't a big problem as "not knowing what they are talking about" you wouldn't be made to look the fool.

I don't look the fool here, because I'm not. We're not even as far apart as you think. The difference is that you seem to think that nothing is ever a problem, which is categorically untrue. And just because I haven't programmed professionally for some time doesn't mean that I'm not aware of what's happening these days. I just don't have that pair of rose colored glasses you seem to wear all the time.
Reply
Reply
post #100 of 100
12/14/12 at 12:18pm
Quote:
Originally Posted by melgross View Post

I don't look the fool here, because I'm not. We're not even as far apart as you think. The difference is that you seem to think that nothing is ever a problem, which is categorically untrue. And just because I haven't programmed professionally for some time doesn't mean that I'm not aware of what's happening these days. I just don't have that pair of rose colored glasses you seem to wear all the time.

 

You look the fool not because of your position but because you not just present your position but actively try to discredit people with different opinions.  It wasn't sufficient for you to simply state "I think that supporting X86 and ARM will be difficult" but you had to state "people who say otherwise don't know what they are talking about".  

 

The fool part comes when you attempt to do justify this attack you expose your own ignorance.  For example, when you doubled down on the personal attacks with "But then, you probably can't understand why x86 software from Windows worked so poorly using an emulator during the years when the PPC was the more powerful chip." you got no less than 3 things wrong:  

 

  • you have no idea what anyone on the net can or cannot understand or if in fact they actually know more than you...making assumptions on this point simply makes you an ass
  • Windows worked so slowly PRECISELY because of the emulation layer...which you would have known if you yourself truly understood what was going on
  • PPC was not that much more powerful...unless you bought into the RDF.  On SOME things the PPC was faster.  On others, not so much and in no case was the performance difference sufficient to overcome the cost of dynamic recompilation of x86 code into ppc code (as used in virtual pc) and the emulation layers.  Windows apps that were natively compiled for PPC worked well. 

 

I have never stated that nothing is ever a problem therefore the fact that your strawman is untrue is meaningless.  Again, my position is for applications that are written against the core iOS SDKs and follows Apples guidelines that supporting x86 iOS will be a non-issue.  You do the same things you need to do anyway for your code to work well with the latest iOS. Once done then for many, if not the majority of these programs you add the X86 target and XCode generates the appropriate fat binary for you.  The facts support this position:

 

  • iOS code currently run natively on x86 because the XCode simulator environment isn't an emulator.  The code is compiled for an x86 instruction set.  What you say is difficult is done TODAY.
  • Apple successfully supported this kind of development during the Intel transition where Mac developers that coded against Cocoa and OSX 10.4.x Core APIs found that supporting both Intel and PPC wasn't a significant issue.  Some had problems but many found it to simply work as advertised by Apple.
  • Apple is very anal about rejecting apps using undocumented features because most breakage occurs when developers do this.  Since these apps get rejected you've eliminated the most common cases where the abstraction layers fail.

 

Game apps, NEON apps, apps that have ARM assembly code...these all would need work to support X86 and these typically don't run in the simulator at all.  Even here, many devs use game environments (like unity) that greatly ease cross platform development and it's just part of the process. 

 

TL;DR; Don't attack other people and they won't bother to point out where you're talking out of your ass.

Reply
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Future Apple Hardware
AppleInsider › Forums › Mac Hardware › Future Apple Hardware › Complex chip shift from Samsung expected to take Apple 12-18 months