Hacker News new | ask | show | jobs
by mda 3930 days 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.
1 comments
TheCondor 3930 days ago
Leaner? Faster? More efficient? Hahaha, that's great! Really funny stuff...
link
mda 3930 days ago
Why don't you humor us and explain why it can not be?
link
TheCondor 3930 days ago
Why 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.
link
mda 3930 days ago
So, 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.
link
rwmj 3930 days ago
64 bit ARM is a mostly new ISA.
link
monocasa 3930 days ago
x86 is rough, but ARM is still a fairly clean ISA.
link
Nelson69 3930 days ago
What 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?

link
astrange 3930 days ago
x86 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.

link