Alpine Linux 3.15 bids a fond farewell to MIPS64 support The compact Linux distribution Alpine has gained the latest LTS Linux kernel with the update to version 3.15, but fans must say goodbye to support for the MIPS64 architecture. The release is the first in the 3.15 stable series and, as well as the 5.15 LTS Linux kernel, received a raft of updated tools and components, including …
It's funny, MIPS was always more performant than ARM. ARM got its foothold in mobile phones by being extremely low power albeit poor performing. When making the leap to smartphones, it would have made sense to go with MIPS, but the company kept changing hands, going through financial difficulties, and were effectively missing when the huge technology shift was in progress. If they were a healthy company when Apple and Google were releasing smartphones, it could be a MIPS world. It would make more sense, too, as it took years for ARM to up their performance game to match MIPS, and MIPS has a long history in high-end computers where ARM never did.
MIPS has a lot of oddities in it's design that were hard-coded from the early architecture. Branch delay slots and register timing are what I remember from the blog post below.
Apple could likely have bought MIPS when they were ready to go 64-bit, instead of using AArch64. Their M1 now beats Intel by several metrics.
Also, the top supercomputer is AArch64.
It looks like ARM really put some thought into enterprise performance, and removed similar scalability problems from Furber & Wilson's original ARM design.
https://www.jwhitham.org/2016/02/risc-instruction-sets-i-have-known-and.html
"MIPS is the worst offender. It deliberately omits a feature which is so fundamental to CPU architecture that software people don't even think about it. The architecture leaves out the mechanism in the CPU pipeline which would otherwise stall execution until the data was ready. A register access which would have created a minor inefficiency on any other architecture instead creates a "hazard" on MIPS. You can read from a register before that register is ready. If you are writing or debugging MIPS code, you have to know how this works...
"Both SPARC and MIPS share another horrid feature - delayed branches. These create a dependency between instructions, in which the branch takes effect after the next instruction, rather than immediately. When using assembly code, you have to know which instructions have a delayed effect, and what rules apply to the instruction (or, sometimes, instructions) in the "delay slot" following it. The delay slot is restricted in various ways: for instance, you can't put another delayed branch there."
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
