271
Linux was called 'obsolete' in 1992, and now it powers servers around the world
(www.xda-developers.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 14 Sep 2026
271 points (97.9% liked)
Linux
19081 readers
786 users here now
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
founded 3 years ago
MODERATORS
ARM has multiple revisions that are incompatible with each other, such as ARMv7 being incompatible with AARCH64, but each ARMv7 implementation is compatible with other ARMv7 implementations, and each AARCH64 implementation is comaptible with other ARCH64 implementations, otherwise something like Android APKs or Linux binaries built for AARCH64 would only be able to be run on SoCs from a single company instead of being able to run on SoCs from Qualcomm, Samsung, Nvidia, and Mediatek just the same like they are.
Just because ARM does not maintain backwards compatability does not invalidate my point.
It does. ARM is basically a set of RISC processors that each of them are different. There is no single ARM well defined instruction set, because every ARM CPU is incompatible and an implementation of the RISC idea. You cannot say ARM is well defined. But you can say x86 is well defined.
I mean 80s computers had ARM CPUs, that has nothing todo with todays ARM anymore. This is not what I would call "well-defined".
If backwards compatibility bothers you, then replace it with "a series of well defined ISAs", which still does not define the RISC philosophy as a whole, which is the entire point I'm trying to make.
This is exactly what I'm saying, its not well defined architecture. You never know if the next ARM CPU will be compatible or not to any existing variants.
What do you mean? ARM is a RISC CPU. The entire philosophy of RISC is that anyone can implement this RISC system, and no guarantees are made to be compatible with any prior CPU. We have RISC CPUs since the beginning of 80s.
RISC literally just means reduced instruction set architecture. Any CPU that has a small amount of instructions (defined somewhat arbitrarilly) is considered to be a RISC CPU as opposed to a CISC (complex instruction set architecture) CPU. The idea behind RISC is to improve performance by reducing bloat, but the tradeoff is that performing more complex tasks takes more instructions to do.
Yes, but they could have compatibility like x86. The difference is that every CPU creator can have different sets, not just a superset. That's why ARM is not well defined, because its by nature cannot be. There is no definition of what an ARM or RISC CPU has to offer or be compatible to.
ARM is a series of ISAs, which are strict definitions which CPUs must conform to to be considered ARM compatible. RISC has no set or sets of ISAs, and is more of a philosophy.
If one company, like Mediatek or Qualcomm makes an AARCH64 CPU, compiles a binary for a common operating system, like Linux, and wants to run it on the others' CPU, that is possible because the ISA for AARCH64 is strictly defined.
On the other hand, take two incompatible RISC architectures, say one CPU that uses MIPS and another RISC-V, and try to run binaries compiled for the other architecture, then try to run it. It will not run because they are inherently incompatible, even though they are both a subset of the wider RISC umbrella.
Also depending on which ARM assembly programmer you ask, modern ARM isn't even really RISC due to its complexity despite the name. That is a whole other unrelated conversation, though.
Every CPU is a definition. Even if there is only one. That's not the point. I also said already that ARM is an implementation of the RISC idea. What makes ARM not being strictly defined is, that no one has to follow an existing ARM CPU definition. Its like saying that every CPU with a branding is strictly defined, yes obviously they are defined for themselves, otherwise it wouldn't be possible to build one.
I feel like we're talking past each other. I'm not saying you are wrong, at least in the sense what you are trying to say.
What do you mean "no one has to follow an existing ARM CPU definition"? That is quite literally what an ISA is and why different ARM CPUs (of the same revision) are compatible with each other. If you had different vendors implementing different specifications in an incompatible way, then binaries that run on one vendor's processor would be incompatible with another's and that processor would no longer be considered an ARM CPU.
ARM (the company) licenses both ISAs and reference implementations of their CPU cores to each licensee to implement how they wish. Some vendors use that reference implementation and make minimal changes to it, others scrap it and build their own based on the ISA that was provided to them, but regardless, they are still binary compatible with each other. That means that I can take one Android APK compiled for a single CPU architecture and run it on multiple devices that use the same ISA but have CPUs made by different vendors. That is, of course, assuming Android has been ported to both devices. That is why I can run, say an aarch64 build of NewPipe on my phone, on a modded Nintendo Switch, and on a Mac running Asahi Linux with Waydroid.
Intel and AMD both implement the 64 bit AMD64 and the 32 bit x86 ISA due to a weird cross licensing deal from the failure of the Itanium architecture and the success of AMD's backwards compatible implementatiom of a 64 bit version of x86, for instance, but they do not share implementation designs with each other. Regardless, they both can run the same binaries.
RISC-V is a royalty-free ISA that is strictly defined by RISC-V International with extensions being approved over time. Many different companies all over the globe are implementing wildly different RISC-V designs, but since they all use the same strictly defined ISA (assuming the same bitness and ignoring differences in operating systems/lack of OSs, bootloaders, etc), they can all run the same binaries. If you try running a RISC-V version of some Debian package on a SiFive CPU, that exact same precompiled binary package will run on a StarFive CPU. There are even RISC-V cores that have proprietary extensions, but since they also implement the base ISA, any code compiled with support for the base ISA will run. Now on the other hand, code compiled that require those proprietary extensions will only run on CPUs that implement those proprietary extensions. This does not mean that RISC-V is not strictly defined, but due to the way the permissive licensing of the ISA works, modifications without contributions upstream are allowed.