lol what makes you say that? I'd consider apple TV, apple music, apple maps, etc all as services. What is your definition of "services" and do the ones I listed fall into your definition.
Well, no shit. I was pointing out that they're placing more and more importance on being a services company rather than a hardware/product company. As that emphasis on services grows they'll probably switch to their own silicon for their cloud stuff which their services will run on.
It's coming. My prediction is Apple will start doing server chips not too long from now, at least for internal use. This is going to be especially important as they emphasize their services more and more over their hardware.
They already offer it to a lot of manufacturers but they mostly refuse. Prime example of this was Porsche. I still can't believe they turned down that offer.
I think it will be a big factor. Yes, they are two separate things in the car industry. But if I have a choice between two EVs, one with self driving and another with no self driving you bet I'm going to pick the one with self driving. And I'm willing to bet a lot of others will too.
I don't know about that. Sure, the F-150 is a nice option but what is Ford doing in terms of self driving. Tesla is tackling multiple issues at the same time, most car companies playing catch up usually just care about the EV part but not the self driving aspect. In 5 years Tesla will still be the dominant EV imo because feature wise their cars will be so far ahead of everyone else.
I would guess the processor would just cause an exception/interrupt and it would just call an OS level exception/interrupt handler which would probably tell the user what the exception/interrupt was that occured; in this case an unsupported instruction.
Do you have a source that they don't already support some sort of SVE? I don't think they would make this public information if they don't have to. As far as I can tell they wouldn't need to recompile any previous ARM binaries so this could remain under the hood and they would never need to tell you whether or not they're doing it. So I'd be interested if you have any source on this.
Who says they don't already support SVE; is it publicly known they support it or not? Especially if the binary doesn't have to be recompiled you'd never know whether they implemented it or not right?
"RISC CPUs have a choice. So e.g. smaller ARM CPUs don’t use micro-ops at all. But that also means they cannot do things such as OoO."
I don't agree with this. What do uops have anything to do with ooo execution. I can easily make a CPU with no uops doing ooo execution. Unless I'm misunderstanding and the article is just saying smaller cores don't do ooo since they are trying to stay within a certain area/power footprint.
Yeah, I think that's key to understanding this. They are supporting a version of ARM ISA running that maintains TSO even though official ARM doesn't need to support TSO. I guess this is all to get better emulation performance and avoid those extra synchronization instructions that would have to be added by Rosetta if the silicon did not have TSO support.
I think I understand now. Rosetta is just doing translation from x86 to ARM; however, native ARM doesn't have a notion of TSO which means they're still putting in the logic to maintain TSO just to assist with the better emulation performance. On a purely ARM machine I guess that logic wouldn't be needed.
so you're saying somehow Rosetta2 is looking at an x86 binary and figuring out exactly which portions of the program rely on the TSO ordering for correctness and then dynamically switches to weak ordering for parts that might be able to do without?
I don't really know much about the internals of macOS but figuring out when there are applications for example running on two different cores (since TSO is only really needed for multi-core use cases) that need to access the same memory and then applying TSO on the fly like that seems difficult. If that is what Rosetta2 is actually doing, that is impressive.
I didn't really understand the TSO explanation given in this article and found it to be a bit hand-wavy. The article says to emulate the x86 TSO consistency model on an ARM machine which is weakly ordered you have to add a bunch of instructions which would make the emulation slow. I followed that much but then after that it doesn't really explain how they would get around these extra instructions needed to guarantee the ordering. It just says "oh, it's a hardware toggle"; toggle of what exactly?
I could see them just saying no to following TSO for single core stuff and when running emulated code for single core performance benchmarks since technically you don't care about ordering for single core operation/correctness. That would speed up their single core stuff but then what about the multi-core.
Just to be clear, the RAM/memory and cache are not on the same chip/die/silicon. They are part of the same packaging though.
> which keeps the memory between caches and the system memory/RAM coherent
Isn't this already true of every multi-core chip ever designed; the whole point of coherency is to keep the RAM/memory coherent between all the cores and their caches.
I used to work in Austin. I always thought Austin was the Atom HQ of sorts because that was where ARM was also located. And at the time it seemed like Austin was the mobile epicenter of the chip world. But yeah, at Intel there has always been a rivalry of which location owned what projects. Thank god I'm not there anymore.