5 ms·
I think you are missing one thing. This would not be a general purpose ISA designed for 3rd parties to develop and run things on it, this would be an ISA specif
by mda 11y ago
I think you are missing one thing. This would not be a general purpose ISA designed for 3rd parties to develop and run things on it, this would be an ISA specific to Apple.
Apple has absolutely control on anything and everything that would run on this thing, I don't think it is about paying licenses to Arm. When you have almost infinite money, in long term having a leaner/ faster / more efficient custom ISA is better and lucrative than depending ARM or Intel for innovation. They can make it run existing applications with a transformation layer (already done by Nvidia/Transmeta mentioned elsewhere in this thread) So, I don't see why not.
- TheCondor 11y agoLeaner? Faster? More efficient? Hahaha, that's great! Really funny stuff...
- mda 11y agoWhy don't you humor us and explain why it can not be?
- TheCondor 11y agoWhy don't you point out some of the inefficiencies they are hobbled by? I'll assert that there aren't any at the isa layer, none that are measurable.
- mda 11y agoSo, 40 year old x86 and 30 year old ARM is not full of legacy issues and layers over layers of hacks? A good fresh start has always possibilities, real question is if Apple is competent enough to pull it off.
- monocasa 11y agox86 is rough, but ARM is still a fairly clean ISA.
- Nelson69 11y agoWhat about ia32e x86? Other than booting it, and EFI is addressing that, it's a fairly clean and nice architecture. Some of the registers have legacy names. Are there any really odd legacy behaviors?
- monocasa 11y agoPretty much everything still exists in AMD64. You can still set up a 16-bit process while running under long mode.
- rwmj 11y ago64 bit ARM is a mostly new ISA.
- astrange 11y agox86 is a variable-length encoding, which is a good thing for cache use, but it doesn't help these days because the most common instructions are not the shortest, and the shortest ones are things like BCD and BOUND that nobody uses. x86-32 doesn't have nearly enough register names, causing totally unnecessary memory spills, which the hardware was never good enough to hide, and having to pass arguments on the stack. That's why x86-64 is faster than -32, even though 64bit wastes so much cache space. And some instructions are just randomly slow because of handling the weird encoding, like 16-bit math is slower than either 8-bit or 32-bit math. Then there's eflags, but that's a minor complaint.