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

12346»

Comments

  • Reply 101 of 101
    nhtnht Posts: 4,522member

    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.


Sign In or Register to comment.