I'm not sure that Sun is the best comparison here, as they did both the ISA and the microarchitecture on their chips. If the claims in this article are to be believed, Apple is doing their own uarch, but keeping the armv7 ISA (and gluing some other ARM building blocks together).
When Sun's architecture started to fall behind, there weren't really second sources for compatible chips. Combine that with a greater reliance on ISA optimized assembly than today, and you can see why their customers started to leave.
If Apple did roll their own ARM this time around, they almost certainly built prototypes of the iPhone 5 with a "standard" ARM9 design for contingency reasons. Getting the software to work on either hardware should have only been a matter of setting some optimization flags and swapping out a few header files. Easily worth the risk, in my opinion, as they can always revert back to a uarch designed by ARM if their own designs start to lack performance or become too expensive in the future.
I agree it certainly isn't a 'clean' comparison, but at the time Sun didn't have the option of licensing the 68K architecture from Motorola and extending it in their own silicon. I still remember a talk with both Bill Joy and Andy Bechtolsteim where Bill was over the top enthusiastic about finally having the ability to change the CPU to work better with the software rather than having the software work around what the CPU thought was best. I don't doubt for a minute that he at least would have been just as enthusiastic if the 68K could be augmented in a Sun specified way. There is a huge efficiency in customizing the CPU to do what you want.
This I found interesting:
"If Apple did roll their own ARM this time around, they almost certainly built prototypes of the iPhone 5 with a 'standard' ARM9 design for contingency reasons."
How likely do you suppose it is that they did exactly that and called it the '4S' ? Having worked in places doing new CPUs (Intel in the '80's, Sun in the '90s) you always make a product based on the old stuff in the event the new stuff doesn't hit the schedule. The Sun-3/60 was exactly that machine, it was the 'in case the SparcStation 1 slips' machine.
It seems very unlikely that the A5 used in the 4s was a fallback plan.
First of all, they were already getting a huge speed bump by going from single core A8 to dual-core A9. So existing iPhone users would have been happy. There was also no foreseeable external competitive pressure at the time, everyone knew that there weren't going to be any S4 phones for 6-9 months, and that Tegra 3 would be a joke.
They were also still on a 45nm process, and the A5 with dual-core A9s was already huge (120 mm^2). They would not have wanted to increase that at all, even if they had a working design of their own. What would have been the options? Seems like it would have been either reducing GPU resources, or dropping a core. Hard to see either of those being worth it.
Finally, one could argue that they main plan was their own core@32nm, and the A9@45nm was the fallback if there were process troubles. But these days there seems to be a strong preference to alternate new designs with new process nodes, rather than doing both at the same time. And in fact this conservative option is exactly the one Apple picked next spring: the iPad refreshes were a mix of 32nm parts (simple shrink) and 45 ones (higher clock, more GPU). If Apple weren't willing to risk going to 32nm even for a design iteration as conservative as A5 -> A5x (and the process was clearly working for them with the A5 shrink), the idea that they would have tried for a radical new design + new node 6 months earlier doesn't seem credible.
Comparatively weak single-threaded performance, weak GPU performance, constrained memory interface, high power consumption when not running only the companion core.
Tegra 3 isn't terrible, but just like previous Tegra chips it was so hyped up before launch and again turned out to be among the weaker ARM chips of its generation. Exynos, Snapdragon S4, Apple A5 (and now A6) and OMAP 4 beat Tegra 3 on everything except synthetic multi-threaded benchmarks (because it has 4 cores, obviously).
I don't know about the GPU, my impression was that it was competitive (the single-channel memory interface probably doesn't help), but otherwise that's spot on. It really seemed to be a design whose main goal was to have the most cores for marketing purposes.
And of course they launched on a process that was just about to become obsolete, and haven't been able to do a shrink. Not sure why, though. Complications with the companion core? Just NVidia's general inability to get 28nm to work?
(Commercially it didn't help that they were unable to get access to a competitive LTE modem. That meant there was no shot at the US phone market. But that's not particularly a failing of NVidia, everyone but Qualcomm has that problem.)
Man, I would think that Chuck M. would know, but this time, apparently not. The Sun 3/80 shipped simultaneous with the SS1, the 3/60 pre-dated the SS1 by several years.
The degree of compatibility seems to be a major variable, so this puts the comparison into doubt.
> I still remember a talk with both Bill Joy and Andy Bechtolsteim where Bill was over the top enthusiastic about finally having the ability to change the CPU to work better with the software rather than having the software work around what the CPU thought was best.
They should have been able to make Java VM implementers' lives a lot easier on Sun platforms. I guess the question was also, did they necessarily want to?
That is true but in the early years Sun was not a 'good' licensor since they seems to compete with anyone who tried to build one. Fujitsu was a success story and arguably made better high end SPARC chips than Sun did. ARM Holdings on the other hand doesn't make any hardware at all so they are completely motivated to have their licensees be successful.
When Sun's architecture started to fall behind, there weren't really second sources for compatible chips. Combine that with a greater reliance on ISA optimized assembly than today, and you can see why their customers started to leave.
If Apple did roll their own ARM this time around, they almost certainly built prototypes of the iPhone 5 with a "standard" ARM9 design for contingency reasons. Getting the software to work on either hardware should have only been a matter of setting some optimization flags and swapping out a few header files. Easily worth the risk, in my opinion, as they can always revert back to a uarch designed by ARM if their own designs start to lack performance or become too expensive in the future.