Apple moving to ARM for Mac in 2021: Analyst • Hacker News Board

Re: Apple moving to ARM for Mac in 2021: Analyst

#21

Post by ac29 » Tue, Feb 25, 2020, 4:00 AM UTC

monocasa wrote: post #2

It's interesting that the actual quote from the investor call is that it's a processor designed in house, and doesn't call out ARM. IMO, an x86_64 chip makes way more sense. The patents are about to expire. Removing nearly all of the legacy mode only cruft (which is not as much as you might think, but tends to be in the critical data path) and making a chip that runs at least x86_64 user mode code would align with ho…

The patents for x86_64 might be expiring soon, but SSE3/4 and AVX1/2/512 are newer. I'd imagine there is a lot of performance critical code written making use of those extensions, and that's just vector stuff. The x86 architecture has added a lot of other new extensions in the past 20 years as well.

Re: Apple moving to ARM for Mac in 2021: Analyst

#22

Post by monocasa » Tue, Feb 25, 2020, 9:02 PM UTC

ac29 wrote: post #21

monocasa wrote: post #2

It's interesting that the actual quote from the investor call is that it's a processor designed in house, and doesn't call out ARM. IMO, an x86_64 chip makes way more sense. The patents are about to expire. Removing nearly all of the legacy mode only cruft (which is not as much as you might think, but tends to be in the critical data path) and making a chip that runs at least x86_64 user mode code would align with ho…

The patents for x86_64 might be expiring soon, but SSE3/4 and AVX1/2/512 are newer. I'd imagine there is a lot of performance critical code written making use of those extensions, and that's just vector stuff. The x86 architecture has added a lot of other new extensions in the past 20 years as well.

Yeah, but for that, Apple very well might have enough patents in the CPU design space to negotiate a license at this point.

Re: Apple moving to ARM for Mac in 2021: Analyst

#23

Post by johntb86 » Fri, Feb 28, 2020, 5:45 AM UTC

monocasa wrote: post #12

api wrote: post #11

Earlier quoted context omitted.

How hard would it be to re-use a lot of the ALU, MMU, and other components from the Apple A line of ARM64 chips with a different decoder and pipeline? Pretty much all modern chips "emulate" their instruction set anyway with the real core being a proprietary uop machine.

ALU - easy, it's pretty much orthogonal to ISA layout MMU - they're pretty different I def bet that if they're making an x86 chip, it shares a lot of RTL with their A series cores, but the distinction is probably more like they have a shared library of a lot of primitives, and have pretty different uarchs built from them.

Would they do something crazy like x86-64 usermode and aarch64 kernel mode? You might be able to share more of the MMU and so on with that - though given the memory-ordering differences it would still be difficult.

Re: Apple moving to ARM for Mac in 2021: Analyst

#24

Post by exikyut » Tue, Mar 03, 2020, 3:26 PM UTC

monocasa wrote: post #9

ajross wrote: post #6

Earlier quoted context omitted.

> legacy mode only cruft (which is not as much as you might think, but tends to be in the critical data path) I'm curious about what you're thinking about here. In fact almost all the code paths for user mode code are running out of the uOp cache in modern devices and completely decoupled from the legacy stuff. And even in the kernel, doing locking and mode switching on the normal paths doesn't hit any major fallback…

One example: the segmentation hardware needs to evaluated in the TLB lookup path between L1 and L2. Even special casing base=0 length=4G or not (and do the slow path in the not case) and just adding an extra mux there is still a minor burden in the designs I've heard about. Also, the instruction decode cases for 16bit mode is still in the main instruction decoder and not ucode AFAIK. They're almost the same encoding,…

I'm incredibly late with this reply and I completely understand that you may never see it, but I'd be extremely interested to dump myself in the deep end of stuff that's on the same wavelength as what you're describing, if you have any suggestions for resources I might be able to follow up on. Thanks!