ARM-based MacBook Air test sample spied | Hacker News Reader

ARM-based MacBook Air test sample spied

reghardware.com

44 pointsfvbock41 comments

I think that Apple is going to move to a side-by-side x64/ARM model with the ARM chip running the full OSX kernel and the x64 chip being an on-demand auxiliary processor available for user-space applications that haven't or can't be recompiled for ARM (ie: VirtualBox) or need more horsepower.

The new interconnects on the Intel chip should ensure that both CPUs can access RAM and various peripherals without performance suffering. Apps can then choose whether to be run as native ARM or x64. The core apps will all run on ARM, allowing x64 chip to sleep and the new Macbook Airs to boast 20+ hour runtimes when performing core tasks only.

I haven't seen anyone else with this theory, but it makes a great deal of sense that Apple would push this. They have control over most of the stack: the ARM CPU, the kernel and the motherboard design. More details here - I'd be interested in hearing if others think this is feasible:

http://grack.com/blog/2011/05/07/how-apple-can-make-use-of-a...

It's certainly possible I think, but what you're talking about is more-or-less asymmetric multiprocessing, which (according to Wikipedia at least) is generally more complicated to implement at a hardware level:

http://en.wikipedia.org/wiki/Symmetric_multiprocessing#Alter...

Exactly, this is just an asymmetric MP configuration. Note that this isn't exactly groundbreaking either. Others have already been using QPI to hook FPGAs up as accelerators. I don't doubt that it's a complicated technical endeavour, but Apple is certainly home to a number of talented engineers:

http://www.nallatech.com/Latest-News/xilinx-demonstrates-int...

http://www.eetimes.com/electronics-news/4207772/Xilinx-demos...

Getting the two to interoperate eg cache invalidation would be hard without Intel cooperating I think. Running as independent systems but maybe sharing some pci devices might be easier. They would have to run two OS kernels anyway as mixing a dual architecture kernel would be hard.

The Mach kernel uses messaging as its core component, that is what it is built on. Messaging means it becomes easier to share state since it is all messages anyway.

This is a wild idea, but there is precedent in the example of the dual-graphics systems.

That said, I'd be very surprised if Apple implemented this initially in the MBA first. Maybe the MBA will move to A5, then down the road, the high-end laptops will go dual Ax/x86. One approach might be to expect a multi-core Ax machine with a single Ax core dedicated and custom designed to emulate an x86... Might be worth keeping an eye on Apple job ads, since we know they have used emulation techniques in the past, such as Rosetta.

I haven't seen anyone else with this theory

I was going to post and suggest it, but was too afraid of looking like a doofus.

On the one hand, VMWare Fault Tolerance keeps two virtual machines on two separate hosts in sync down to the CPU instruction. VMotion moves running processes around live. Suspend to RAM and Disk do work on running processes, and Apple have a two-video-card model in production, and 32/64bit tolerance, and have had PPC/Intel combined tolerance, and dual core, dual CPU computers exist. These are all mildly supporting evidence that such low level trickery and successful complex solution might be possible.

On the other hand, I have no idea what two different classes of CPUs working on the same motherboard would mean, or how much complexity and bugs it would introduce, or how much cost. Or whether they'd be better off spending the effort on reducing power use somewhere else. Or whether they could deal with running the kernel on Arm and Virtualbox on Intel and still dissipate the heat while also having much reduced battery life.

My biggest counter is that low level stuff seems to be a lot harder in practise than the higher level discussions always make it sound.

<sarcasm>I can't wait to have the PPC vs i386 arguments all over again... </sarcasm>

Seriously though, what are the implications for virtualization software (Vmware, VirtualBox, etc) on an ARM platform?

I'm all for innovation, but the fact that MacOS/Linux/Windows/BSD all currently support one common architecture has been very convenient, in recent years.

They will want to support x64 on ARM anyway, because Windows is going on it. If Apple was to do this, now is a good time. Have a Windows program, and a Mac port you care about? Port both (hopefully). That's assuming anyone other than VM and driver companies will notice the change and will have to code for ARM.

> They will want to support x64 on ARM anyway, because Windows is going on it.

Could you explain that?

There's an ARM version of Windows 8, either it launches with no software or MS builds in a way to support all the existing stuff.

Microsoft is porting Office. There is no way a current ARM can emulate a modern x86 with performance comparable to real hardware. Microsoft can make it easy for companies to compile their codebases for ARM, provided they use Microsoft tools. C# and Java should be able to run cleanly, but there is a lot of VB6 code still floating around.

There are ways to use the transistor surplus an ARM code has (it's much simpler than a comparable x86) to hardware-assist the translation, but, by the time you have a functional silicon, you will be in the x86 size range, negating all the advantages ARM has.

I have no inside knowledge, but I'm betting that the ARM version of Windows will strictly run .net user applications. (There's already precedence for this with Windows Phone.)

Microsoft already tried to support Windows on two different architectures (x86 and Alpha) and failed when application developers never bothered porting to Alpha. They're not about to repeat that.

Couldn't they automatically recompile x86/x64 .NET stuff to ARM on install or first run (some of the time)?

.NET stuff is not native code. It's CLR bytecode, interpreted much the same way Java bytecode is. Some runtime environments do JITing, when the bytecode gets translated to native instructions.

x64 is a specific 64-bit derivative of the x86 architecture, ARM has it's own 64-bit arch. Microsoft is porting Windows 8 natively to ARM.

True, but you got my point, calls that used to be purely written for x86 have been ported to run on ARM.

I love the idea of lower power ARM devices, but the first thing my mind goes to is visualization. What are the implications?

VirtualBox has been a boon for me for virtual server environment testing.

You quite probably won't get decent x86 emulation speed out of an ARM processor. It takes an order of magnitude more transistors than an ARM has just to make an x86 out of hardware. You can do code translation on the fly, but doing that and keeping your virtual environment anything like the server you are trying to emulate.

When it comes to simulating servers, I've been opting for things like lxc and openvz. OSX should be able to use BSD's jail.

In the novel "Shogun," Toranaga has Blackthorne build a ship, secretly burns it down and has him build another. The ships are meant as bargaining tools for Toranaga's negotiation with the Portuguese, who control sea trade with Japan.

A working Macbook-anything running an A5 chip would be extremely useful for Steve Jobs when negotiating terms with Intel, even if in the end he "burns" it.

The fact that we know about this supports this idea. Apple is quite capable of keeping much bigger secrets than this when it tries.

How about MacBook Express[1]? - ARM based, Mac App Store only for applications[2], no touch screen[3]. Users can be given a trojan free experience and Apple gets a big stick to nudge developers into the Mac App store?

This would rule the casual, unsophisticated user market. HN readers might have one as a second machine, but would probably get a "real" MacBook with the x86 and the freedom to code.

[1] Initially I thought MacBook Light, but then that's why I'm forbidden to name products. Express is already in the Apple product vocabulary and doesn't carry a negative connotation.

[2] Require a cryptographic signature from the Mac App store before any code can be executed. Remember, this gets complicated when you have interpreters on the platform, you have to control the input to them as well or only permit them in sandboxes. (Developers get some sort of testing exemption.)

[3] I don't think touch screen is a part of it. As great as it is for things on a tablet, the ergonomics on a laptop are awkward, and you need to design the application UI twice for people with and without.

About that [3]: the first thing I thought is that Apple must have some innovative idea about the ergonomics of a touchscreen on such a device.

A laptop that supported desk accessary (http://en.wikipedia.org/wiki/Desk_Accessory)/Side kick (http://en.wikipedia.org/wiki/SideKick)-like use of iOS apps would be a way to lure existing iOS users to such a device.

And for naming: the OS would be Mac OS X Singapura :-)

Just thinking out loud: How about a device like the Nintendo DS (normal screen above, touch screen below) scaled up to a normal laptop size?

This was my thought as well. Recompiling your application for ARM that has already been accepted in the Mac App Store would be pretty straightforward. It would also mean that the only productivity applications on the device would be new ones - Microsoft Office and Adobe Creative Suite would probably never qualify.

Supposedly, OS X ran on intel chips for years before Apple made the switch for their products. I've got to imagine that Apple has been running OS X on their own chips, even if they have no specific plans to make the switch.

I've been expecting this for awhile. At the LLVM developer's conference in November, there were tons of compiler engineers working on the ARM backend, but I didn't meet anybody working on the x86 backend.

Granted, iOS is important and runs ARM exclusively, but I would've expected more love for the x86 backend given how important the laptop segment is for Apple. It made it seem like x86 was not of long-term importance for Apple.

I don't think the legacy x86 code issue is anywhere near as big a hurdle as many people seem to think, because Apple have a weapon there that Microsoft doesn't have, and Apple didn't have (at least to anywhere near the same level) during the 68k/PPC and PPC/x86 transitions: Xcode.

Just about every native Mac app these days was developed and built on Xcode, and Xcode already supports ARM targets. The only remaining obstacle is porting AppKit to ARM, and if (as the original story suggests) Apple already have hardware running OSX-on-ARM, they must have already done that. That means most Mac apps can be ported from x86 to ARM with little more effort than changing the target in a dropdown list and hitting Build.

(For those not familiar with Mac development: AppKit is the GUI library, part of Cocoa, used in most modern Mac apps. iOS apps use a slightly different GUI library, UIKit. At the moment AppKit only targets x86/x64 and UIKit only targets ARM, at least in the officially released versions.)

Microsoft can do something similar with .NET, as others have pointed out, but .NET apps don't dominate the Windows software ecosystem to anywhere near the same extent that Xcode+Cocoa dominates the Mac one.

(One thing I'm quite certain we're not going to see is the hypothetical dual-CPU ARM+x86 machine that some people are speculating about. For the simple reason that, if you're going to put an x86 in the box anyway, why bother with an ARM as well?)

If this new MacBook Air has a touch screen to run all the current iPad apps, while all OS X apps can simply re-compile to an x86/arm Universal app to run on it, it would definitely be my dream laptop.

A touchscreen MacBook Air with a clever hinge so that you can flip it around and use it as a tablet would be pretty sweet.

I know there have been some attempts at this kind of laptop-tablet form factor in the past, but has any manufacturer ever actually managed to solve the hinge problem?

I didn't know it was a problem. I have a Viliv S7 (touchscreen, flip-to-tablet netbook) since maybe a couple of years, no issue with the hinge.

What if they just put iOS on it & have it run iPhone & iPad apps. Add some first party support from Apple where they develop some cloud based apps/services that take advantage of the extra hardware(e.g. keyboard) & differentiate it from the MacBook Air by naming it the "MacBook Cloud"?

I'd buy this immediately. MBA has the perfect form factor, and I'd rather have great battery life than a fast processor.

Anyone wants to speculate on battery life?

I'd wager it's going to be similar to current levels. The past few Apple refreshes didn't change battery much (Macbook Pro actually dropped in battery life.)

Once battery is good enough, weight optimization is the next step. I bet these will be beyond ultra light.

It didn't really drop in battery life, it was just that Apple's testing protocol was revised to more accurately describe real-life usage.

An Asus Transformer with a keyboard can last about 15h, because it has a battery in both the tablet and the keyboard, while still remaining reasonably lightweight and thin.

If Apple keeps the same size of the Macbook Air you'll probably see ~100% improvement in battery life compared to the current Macbook Air. If they decide to make it even thinner and lighter, than it won't gain that much in battery life, but I'm sure it will still be a significant improvement (definitely more battery life than an iPad).

"The iOS-like Mac OS X 7 Lion"?

Mac OS X Lion (Mac OS X version 10.7, don't ask me why they stated it as Mac OS X version 7) is getting some iOS features[1], hence the comparison.

[1] http://www.apple.com/macosx/lion/

Ah, thanks.

Looking closer! http://news.ycombinator.com/item?id=2258693

Reply on news.ycombinator.com