4 ms·
The thing with x86_64 is that Apple/Amazon/Google/Samsung/Fujitsu/etc cannot license it. There are only two corporations with x86 licenses granted by Intel: AMD
by Xixi 6y ago
The thing with x86_64 is that Apple/Amazon/Google/Samsung/Fujitsu/etc cannot license it. There are only two corporations with x86 licenses granted by Intel: AMD and VIA. These licenses are not transferable, and a even a badly managed acquisition could result in the license being revoked.
So moving out of the x86/x86_64 world is really a no-brainer: why would all the electronic giants keep paying for x86 when they can get out of the de-facto duopoly? It seems that they are settling on ARM (Amazon Graviton, Fujitsu A64FX, Apple A12Z, etc.). It could have been another architecture, but it couldn't be x86_64.
On the other hand, there are other architectures besides ARM and x86: RISC-V, OpenSPARC, etc. Maybe one of these would be better for developers who don't want to deal with the ARM landscape fragmentation.
- fiddlerwoaroof 6y agoX86, as I understand, has the advantage of a fairly widely implemented ISA that specifies all sorts of things about how other things on the motherboard communicate with each other and with the CPU
- 737maxtw 6y ago> specifies all sorts of things about how other things on the motherboard communicate with each other and with the CPU That used to be true, but I dont know how true it is now. Once upon a time, ISA and ATA were both wired right to the bus. By the P3/Athlon era everything was probably on a super-io controller and or south bridge, but that communication towards the northbridge/CPU was over PCI or ever fancier links. But the clear cutting point to me is EFI. Most of the standards in how things communicate on older PCs was more based on the IBM BIOS. Early clones couldnt exist until that was nailed down. But... EFI replaces all of that with a new abstraction.
- fiddlerwoaroof 6y agoI’m not a hardware person, really, but—even with EFI—my understanding is that x86 motherboards all implement standards that specify how the motherboard’s features can be accessed from software in a way that is fairly uncommon in ARM/MIPS/etc.
- yjftsjthsd-h 6y agoBasically correct; the key bit is that x86 usually has a bus that can be enumerated by the OS. So you boot, and the OS can look around and see what hardware it has (and where it all is). On most ARM, the OS boots blind and you have to tell it (usually via device tree) what devices are attached and where.
- vertex-four 6y agoThere's a spec for putting a device tree in an ARM chip's rom, the problem being that it's often wrong in some way, requiring device-specific corrections. Note, however, that there's a lot of "quirks" and similar device-specific corrections for x86 as well. These get presented to Microsoft by the manufacturer, and Linux gets to reverse-engineer them.
- yjftsjthsd-h 6y ago> There's a spec for putting a device tree in an ARM chip's rom, the problem being that it's often wrong in some way, requiring device-specific corrections. I was aware of being able to have ex. u-boot pass a device tree file to the kernel at boot time; are you talking about that, or something more generic?
- grawprog 6y ago>The thing with x86_64 is that Apple/Amazon/Google/Samsung/Fujitsu/etc cannot license it. There are only two corporations with x86 licenses granted by Intel: AMD and VIA. These licenses are not transferable, and a even a badly managed acquisition could result in the license being revoked. I don't disagree with you, but is that really a world developers or even consumers want? A world where each device manufacturer creates their own chip based around arm's processor designs that's incompatible with the next device's chip despite being virtually identical? You're right, as a corporation looking to make money off all aspects of everything, it's a no brainer. For everyone else, it's a worse situation than the processor fragmentation of the 80's and early 90's. X86_64, amd and intel, took advantage of the situation of the time and provided a somewhat standard, though controlled by them, processor design that allowed tons of individuals and companies to flourish. Moving to yet another highly controlled set of fragmented platforms is a step back to the 80's. Ideally, we should be moving forward towards a system that provides a universal set of instructions licensable by all, without allowing licensees to restrict their implementations. There's a lot of problems with our current paradigm but backpedaling to an even more controlled and fragmented platform is not the solution. I really believe open hardware is a serious issue that's only starting to be addressed, meanwhile big established players are making their moves to stop it. Arm is a big established player, one of the biggest, they may not be as forward facing as Microsoft or Apple or google, but damn does that company have a huge influence on everything. Widely adopted open standards for hardware that does not encourage proprietary licences on basic chip design is a definite no brainer on the way forward. The hurdles that need to be crossed though are greater than with software. Real tangible goods that require manufacturing require tons of overhead and complexity. This challenge is something I feel is the open source idealogy's next great obstacle and overcoming it will open computing so much more than even open source software has for the world. But, only if people has a whole come together and work towards it by not accepting anything less.
- pabs3 6y agoPeople seem fine with not being able to install the OS of their choice on iPhones, televisions and robot vacuums. So it seems unlikely that software compatibility is that important in that space. The manufacturers will just compile their code for the chip in question, move on to the next device and do the same thing. Of course there will be the ARM SBC corner for devs to play in. Your vision of an open ISA like RISC-V winning is something that I mainly see benefiting manufacturers making closed hardware, not people who want general purpose hardware for running general purpose operating systems. For example Western Digital and nvidia are going to be using RISC-V as part of every SSD/HDD and GPU, but we will not get to run our own code on them. There are also hardware vendors selling RISC-V microcontrollers, but nothing that could run Linux or BSD, even SiFive only has Arduino-level boards out (they had Linux-capable ones but don't seem to be making more of them for sale). Eventually there might be a RISC-V entry in the SBC market, but I think ARM is still going to own that market for a long time.
- DaiPlusPlus 6y agoWhy does x86 need a license anymore though? Any patents on x86 and its extensions right through to the first-gen Pentium 4 chips released in 2000 will have expired by now. Creating a clean-room implementation of an existing ISA doesn't necessarily mean you need a license - it's basically the same thing as reimplementing the Java VM specification: no royalties to Oracle required! (...for now). I do appreciate that the x64 is more recent and will still be patented to heck - but there's only 3 more years until the first of those expire, methinks. PAE for x86 means that programs needing more than 4GiB of main-memory can be run without needing a true 64-bit ISA - and PAE won't be patented anymore as that was introduced around 1995.
- mkl 6y agoYes 64 bit is probably impossible, as there will be new patented features in pretty much every model coming out, so most of your instruction set would be stuck 20 years out of date. I think there's not much point in new 32 bit x86 processors now, as there are low power SBCs that would cover most uses (unless you need old proprietary x86 software, but then just buy a PC second hand).
- classichasclass 6y agoDon't forget OpenPOWER. The Power ISA is royalty-free.