I'm pretty sure they spun-off ClarisWorks
Didn't they? Suggested correction: "The Cupertino maker of HyperCard".
Apple is believed to be developing another ARM-based processor that will challenge Intel hardware in its Mac line. The Cupertino maker of ClarisWorks is reportedly working on a chip to handle operations when a future Mac machine goes into low power mode and the main Intel processor goes to sleep. A Bloomberg report cites …
Yes, you are mostly correct, good ser! Claris was a spinoff company for a very short while, then when it collapsed Apple brought the "Works" back in-house as AppleWorks. And it was used as a name for software on the Apple II.
See: https://en.wikipedia.org/wiki/AppleWorks
just a slight different slant from your post: as the wikipedia link you referenced says there were 3 versions, one created originally by apple 1984-1991 that ended up on the Apple II, another for the IIgs (1988-96), and the third (1991-2004) created by Apple subsidiary Claris and used on systems through 2007. If you ever used the latter version you would know what a great program it was. It was way ahead of its time even with a few defects. Seamless documents where you could move easily from words to paint to drawing to spreadsheet within the same document. It was awesome for its time. Not only that but it could read and write to most of the other word processor formats.
Perhaps, though I suspect that's an added bonus rather than a main aim for Apple.
Intel provide good performance when you need high-power but ARM is good at doing a little. Having a (nearly) always-awake or frequently-waking ARM chip do things when Intel is asleep may be useful to differentiate a Mac from all the other laptops out there.
Just to clarify the article a little (by quoting from the source material, the bold emphasis is mine):
The current ARM-based chip for Macs is independent from the computer’s other components, focusing on the Touch Bar’s functionality itself. The new version in development would go further by connecting to other parts of a Mac’s system, including storage and wireless components, in order to take on the additional responsibilities. Given that a low-power mode already exists, Apple may choose to not highlight the advancement, much like it has not marketed the significance of its current Mac chip, one of the people said.
- https://www.bloomberg.com/news/articles/2017-02-01/apple-developing-new-mac-chip-in-test-of-intel-independence
Initial big/little implementations basically hid the fact that there were 8 ARM cores running at the high (application) level, but later iterations let you use all cores at full tilt if you wanted, leaving the pairing of big/little cores (and transparent migration of processes between them) as more of a secondary option.
So that's how big/little seems to have panned out in practical terms in a purely ARM system.
The article suggests that somehow there can be transparent migration of workloads from high-draw Intel cores to low-draw ARM cores. This between systems that don't share an ABI or machine code or whatever. So how is that supposed to work? Some sort of qemu-like emulation of the workload? Even if it's only doing the translation once, I can't see how emulation is going to be power-efficient enough to warrant sticking in a new CPU.
I guess the other option is that there is no migration and that the hardware uses all native big/little ARM code. Sounds a bit like winmodems, and I don't mean that in a good way.
Currently if you build apps via Xcode you can either run them on the simulator or on an iOS device.
If you run it on the simulator it compiles down to intel machine code (you can see when it crashes), if however you run it on a device it compiles down to Arm machine code.
LLVM has allowed this for years and they can easily compile two versions so they don't need to emulate, the hard bit is to swap between them when the code is running. Could see this being done by breaking the code into closures/blocks and making the memory accessible by both versions, but they may have found a different way.
Currently they would easily be able to port all MacOS apps to Arm as it is just a compiler option.
That is the tricky bit, when the Intel shuts down and ARM takes over, you need to kick out all Intel machine code and replace it with ARM, and when the Intel takes over again, the ARM code needs to be shoved and the Intel code re-loaded.
You could, possibly, have both in memory at once, but you still need to stop, mid process, and copy all Intel register values out to memory, where possible, copy them into ARM equivalents. The stack needs to be built up on the ARM side. Any discrepancies between big-endian and little-endian need to be sorted.
Even if the ARM is doing Intel x64 code emulation, it still needs to set up its own registers and initialise its stack etc.
Easier would be to either use a big-little Intel processor, with Core i cores and Atom cores for low power, or a big-little ARM processor. I don't see any situation, where switching between processor architectures on the fly makes any sense.
At best, I can see the ARM taking over for a "connected stand-by" mode, having its own memory and "apps", which are there to process push messages etc. That said, my old Atom based Windows tablet could manage a couple of days of connected stand-by...
> The article suggests that somehow there can be transparent migration of workloads from high-draw Intel cores to low-draw ARM cores.
The article may well suggest this but I think that it is unlikely. If the ARM chip can successfully handle some processes such as maintaining a Bluetooth connection to a mouse, or checking for a paired phone coming into range while the machine is in low power mode then there is no reason why it shouldn't continue to do so when the machine is in high-power mode.
The biggest impact on Apple's developers is likely to be some further sub-division of low-level code (like Bluetooth handling) into separate, clearly defined high and low-power routines so that they can be compiled accordingly.
It's more likely that app writers will have to write a separate background process that is executed on the ARM processor. You can't migrate processes between two different CPUs running different architectures.
Apple should just go all in and build an ARM-powered MacBook Air (Or MacBook Lite, or any other name marketing likes) to slot under an x86 MacBook and MacBook Pro. Then they can see if it will sell. I think it will, at least to their core audience, people who don't know what type of CPU is in their computer.
no mention of the adoption of the Intel Baseband Chip in certain iPhone 7 models.
Without this they (IMHO) probably would have not filed suit against Quallcomm. They would need a second source of BB chips for their precious gold plated iDevices.(sic)
So, is this a case of apple taketh and apple gieveth
or is it someone who does not like particularly apple penning an article?
It would help to know the authors POV in this
I am playing with an A31 quad core soc (Banana Pi M2+) at the moment which is neither particularly fast or particularly "multi-core endowed" by Arm standards. It runs at roughly the same speed as CPUs in low end notebooks while producing about quarter of the heat output.
If you take something like one of the octacore 2GHz monsters out there - they are perfectly fine for a notebook. As apple is 100% in control of their software stack and it is know to run on Arm... Yeah... why not...
Judging the performance of a CPU by its clock speed is so 1990.
He isn't: you can run workload tests. The only area I see Intel consistently on top is in heavily single-threaded stuff. Given how easy it is to add specific hardware acceleration to ARM there's no reason why Apple couldn't do this with its own chips.
But, while this might make sense for the phone chips because of the volumes Apple sales, it's probably quite happy at the moment for Intel to take all the risks on hardware development, negotiate a nice price and keep a fat margin. But a shift to a full ARM stack at any point is probably possible for Apple. My guess is that they'll wait until we start seeing a lot of Android-on-ARM notebooks.
Apple is notorious for keeping absolutely silent about its development work, until it's good and ready to actually launch a new thing. Your typical high profile high tech firm throws lavish press events to showcase their plans for future products and its tech-in-development - at least, those aspects which management want the world to know about. Apple doesn't and won't comment on leaks about its plans, which is faintly unusual in the high tech business.
None of them actually open up their R&D labs to full public scrutiny and they all use non disclosure agreements to a greater or lesser extent to keep things secret when they want to.
Not being a hardware genius, and seeing how Intel have been making a lot of dosh on multi-core CPU's of late, I'd have thought that it would make some sort of sense for Apple to have multiple ARM CPU's (either individually or shrunk into a single "package") on it's newer products. These products could then have various cores switched on, as required, by the OS in order to allow the hardware to carry out the users heavier processing tasks, by using more cores.
This then brings efficiency to the fore, as well as keeping the cost down (and not paying Intel). And as we all know, Apple have changed their "OS" to suit themselves, over the years and the customers still love them !
They could then use this hardware model on any product, depending on how many cores are needed for any given product?
> Apple does have some experience using non-Intel processors in the Mac, albeit long ago.
That was barely 10 years ago, the last PPC Mac rolled off the lines in November 2006. That's not "long ago" unless you're a teenager; is The Reg replacing the aged curmudgeons that we've come to know and love with child labour?
The article states:
"Apple does have some experience using non-Intel processors in the Mac, albeit long ago."
Well yes, that's one way of looking at it. Another way of looking at it is this:
Apple's original PC line - the Apple 1, 2, and 3 - used 6502 CPUs.
The Macintosh started out in 1984 using Motorola 68000 CPUs, following that line of CPUs until the 68040. Then Apple moved the Macintosh line to the PowerPC line of CPUs starting in 1994, and most recently transitioned the latterly re-branded Mac line to Intel architecture CPUs around 2006.
In other words, Apple's PC line originated outside the Intel ecosystem, the Mac - being the Apple PC line which lasted - has spent most of its life not running on Intel CPUs, Apple has a good deal of experience of moving a PC line from one CPU architecture to another, plainly has no attachment to a particular CPU architecture, so why not a switch to a mixed IA/ARM Mac?
Whatever the plan actually is, I'd happily bet it'll work well.
When everybody has access to the same components from Intel, AMD and NVidia, having more better chips that the competition does not have is a potential advantage.Whether you accelerate certain tasks or take over tasks from the main cpu, you're increasing raw speed of a machine beyond what the competition might offer. I can see how things like Siri, streaming, encryption, networking, push services, HomeKit and HealthKit can run on a separate processor, leaving more cycles available for user applications.
Incidentally, Apple also has experience with using separate processors for multimedia: the Quadra AV line featured a built-in DSP chip that handled digital audio and video separate from the main cpu. It gave these machines quite the edge in that area, and using ARM coprocessors could give Apple a similar edge in performance and the for mobile so important power savings - battery life is still a meaningful parameter.