Apple-ARM Deal Bonkers

The idea of Apple buying ARM is bonkers.

ARM’s great value to Apple, and to the world, is that it proliferates a microprocessor architecture around the globe which means that Apple’s products can work with everyone else’s products and everyone else’s products can work with everybody else’s products.

If Apple bought ARM everyone else would stop using ARM because no one wants to see a repeat of the Intel situation in which one manufacturing company owned a dominant architecture which became sole-sourced.

If ARM were threatened by takeover Apple might take a blocking stake, but ARM has become too valuable as a trusted supplier of a global architecture ever to be owned by a systems house or a semiconductor company which might set out to eliminate or compete with ARM’s licensees.

The ARM model suits the world and the world won’t see it broken.


Comments

9 comments

  1. I think you’re right, forthurst, some devious City jerk sells the yarn to a gullible Telegraph journo and the story gets printed.

  2. Was it ever serious? More like Wall Street banksters ramping a stock: go long before the rumour; go short after. a simple transfer of wealth from tracker funds owned by little people to those of little value to the human race.

  3. Here Here, Mike.

  4. Well SEPAM with the reduction of dimensions process faltering, I assume that architectural improvements – and software improvements – are gong to be seen as to tbe the main focus for competitive differentiation.

  5. The great thing about ARM is that it only survives through fairness and being an enabler to lots of other companies – part of the value is that it DOES provide the same to competitors as well. Each of those customers has options as to what to take from ARM, what to add themselves, while, to a certain level, maintaining enough compatibility with their competitors that costs are saved. Part of this provides a levelling effect where each customer’s results really do relate to the quality of their engineering and the differentiation they can provide.

    However I do wonder if ARM lose out somewhat by not having a standard BIOS. It seems like (and I’m not an expert here) that each implementation of a design based around a different ARM processor needs a lot of customisation which could, perhaps be covered in a BIOS. One advantage of PCs (where I mean Intel architecture PCs with BIOS) is that the OS support once the product is released becomes largely independent of the manufacturer (of the product) because the BIOS (and amount of code in Windows/Linux to support different devices) hides any differences. It seems whenever you get an ARM board it needs a lot of support from the manufacturer for any OS change (such as a Linux version upgrade). I suspect ARM Linux machines might proliferate much quicker if a more universal version of the OSs could run across a range of boards – it might even help with Google’s Android fragmentation. I guess we can live with this where the support requirement is for millions of one device (typically a phone) and being told that upgrades will only be provided for 2 years. It’s more of a problem with less popular devices however. To improve on this and take better advantage of ARM standardisation and perhaps for ARM to compete with Intel in a desktop environment (if it wants to) then something of this approach might be needed.

    As very much a supporter of ARM it was exciting to see Microsoft release Windows RT a few years ago – with hindsight however it might have been better Microsoft to completely drop ARM and use Intel across their range of devices (phones to desktops) and provide the thing I’ve always seen as Windows’ strong point – compatibility across devices. At the moment there’s a level of compatibility across Windows, Windows RT, Windows Phone – but it could, and should, be better.

    I think Microsoft dropped the ball somewhat there and ARM unfortunately didn’t pick it up to the extent they might have done.

    • SecretEuroPatentAgentMan

      My understanding from following LWN.net is that the different ARM systems are sufficiently different that even fitting Linux to these is complicated. If this is correctly understood it means that there would have to be many BIOS variants. And in any case Linux makes very little use of BIOS other than for booting.

  6. SecretEuroPatentAgentMan

    Once upon a time there was a rush of new CPU innovations and architectures (as we see in the discussion on The Micro Which Expired). Now things seem more static. ARM was introduced in 1985 which is 30 years ago. Intel is of course even older. We truly live in the age of tech dinosaurs ruling the Earth.

    So what happened? Did someone think that everything that could be invented had been invented?

    It seems to me that a disproportionate amount of effort is put into manufacturing and reduction of dimensions and far too little in architectural improvements.

    • There’s been a huge amount of architectural improvements but why would those affect the instruction set. Now the world (apart from space and automotive) has settled on two instruction sets let’s just keep it that way.

      • SecretEuroPatentAgentMan

        Well, there are many levels of abstractions going on here.
        At the top there is the high level programming language most programmers use (few do assembly these days and x86 assembly is torture). The compiler then creates x86 or ARM code. Of course back in the day that was what the CPU used but these days there is yet another layer of translation into more or less recompiled microOPS. And that last translation takes a lot of transistors and work which translates into cost and heat. These days x86 code is so inefficient there is prefix before prefix before more prefix codes before you get to the meat of the action. Meanwhile in the name of backward compatibility huge code spaces are reserved for instructions you are not meant to use like BOUNDS. Also the prefix orgy means code is not that expressive and RAM consumption also goes up and also there is the cost of pushing all that code into the numerous caches and then into the decoder.

        The whole thing just stinks.

        And since most programmers by far only use high level languages they couldn’t care less what the system is running on. People I know in the embedded business now find it hard to find programmers that don’t compulsively load in 20 MB libraries to solve the most trivial problems when some boolean logic is what it takes.

Leave a Reply

Your email address will not be published. Required fields are marked *

*