This is really sad. The world is heading to a duopoly x86 - arm. Alpha is dead, Mips is almost dead, PA-RISC is dead, POWER is too expensive and RISC-V is mostly nice to have.
Alpha’s loosey-goosey memory model makes multithreaded code on SMP systems more challenging. Linux utilizes its Alpha port as a worst-case testbed for data race conditions in its kernel.
SPARC’s register windows are anachronistic and complicate the implementation of CPUs, and I’d guess also make it more difficult to build OoOE cores (so many SPARC chips are in-order, why?)
POWER isn’t so bad though. It’s open enough where you could build your own lower-cost core if you wanted. There’s nothing intrinsic to the ISA that would mandate an expensive chip other than volume constraints.
PA-RISC put up some great numbers back in the day but between the Compaq acquisition (bringing with it Alpha) and Itanium it was chronically under-resourced. They had a great core in the early 90s and basically just incrementally tweaked it until its death.
https://github.com/antonblanchard/microwatt
(Disclaimer: minor contributor)
I really liked PA-RISC. I thought it was a clean ISA with good performance at the time and avoided many of the pitfalls of other implementations. I think HP didn't want to pour lots of money into it to keep it competitive, though, and was happy to bail out for Itanium when it was viable. My big C8000 is a power hungry titan, makes the Quad G5 seem thrifty.
If you look at ARM, particularly the 64-bit version, you'll notice it attempts to squeeze multiple operations into a single 32-bit "instruction". It's still called RISC, but not really "reduced" anymore.
I thought Alpha and ARM were the same with respect to that.
ARM had some fairly nasty to track down XFS file system corruption bugs for quite a while for exactly this reason.
The issue has always been that x86 goes out of its way to generally be more forgiving than the spec.
Is that still true in the present tense? Anybody doing this in 2021? Seems like alpha has been dead for a long time.
(The stroke of genius of the C++11 memory model, compared to the older Java memory model, was that reordering could be treated the same way no matter if performed by processors or compilers).
That's not correct. s390x is big-endian and well supported in all enterprise distributions such as SLE, RHEL as well as Debian and Ubuntu.
Incidentally Rust's continued support for S390X is driven primarily by cuviper who works for Red Hat (even before the IBM acquisition).
The last PPC64 release of Ubuntu was 16.04 which is now out of support by about a month. Even on that, the two major web browsers didn't support building on the platform for a long time.
Yes, it can be done if you want enough to do it.
https://catfox.life/2018/11/03/clearing-confusion-regarding-... for more info
Serialization formats like JSON/YAML/protobuf/etc. would be much more costly by comparison.
(Punch cards are big endian because the number 123 is punched as "123". So that's the order a decimal number will be stored in memory. The System/360 mainframes (1964) had a lot of support for decimal numbers and it would be kind of bizarre to store decimal numbers big-endian and binary numbers little-endian so everything was big endian. IBM's current mainframes are compatible with S/360.
On the other hand, in a serial computer, you operate on one bit at a time, so you need to start with the smallest bit for arithmetic. The Intel 8008 was a copy of a serial TTL computer, the Datapoint 2200, so it was little-endian. x86 is based on the 8008, so it kept the little-endian architecture.)
Correct. The data plane of all 'real' networking is done in ASICs and/or NPUs.
Increasingly things seem to be moving towards ASICs for switching and general purpose CPUs (usually with a lot of support from the NIC offload capabilities) for routing, even in 'real' networking hardware.
The vast majority of fabric ASICs would never actually utilize additional TCAM necessary to support full tables at line rate in hardware because top of rack switches do not have that many addressable targets, so it's a wasted cost.
And with DPDK optimized software implementations are achieving zero drop line rate for even 100G+ interfaces for much, much lower cost than full table routing ASICs married to fabric ASICs in a chassis switch.
It's not something a lot of users are aware of -- they often think they've bought an ASIC-based router! -- but essentially all of the big vendors entry and mid-level devices are software routers, and they're even trying to figure out how to sell their NOS experience on whitebox hardware without undercutting their branded hardware.
To be fair [to you], my original claim is a bit of a tautology as I don't really consider software/CPU based CPE gear to be 'real' networking.
I should be more specific. High radix switches/routers are, unequivocally, not built out of CPUs and software, period. To the point of the original discussion, these concentration points are the only place that byte order overhead would be significant. Others in this thread claim it's not significant even in CPU implementations due to optimized instructions, but I personally can't opine on that.
ARM: 1985 ARM64: 2011
RISC V: 2010
It took x86 about 10 years (1988) to become the most popular, and until 2005 to cause Apple to switch (another 17 years)
It took ARM about 25 years (2010) to become the most popular, and until 2020 to cause Apple to switch (another 10 years)
The Newton, then the iPod, then the iPhone, and now the M1.
The iPhone is a more important device for Apple than the Mac from a revenue point of view, and they've sold more devices with ARM chips in them than they have 68k, PowerPC, or x86. They've sold 2.2 billion iPhones. I can't find an easy number on how many Macintoshes they've sold totally, but I can't imagine it's close to that.
In fact, they used ARM in the Newton (1993) before they used PowerPC in the Power Mac (1994).
Switch from Power PC to Intel, and then from Intel to ARM. I'm using Apple as a tipping point, to when the new architecture was so much better than the old it completely took over. Obviously with 90% of Apple devices being ARM already it was an easier choice for them this time. But as each Architecture gets more power as the market is many times bigger, it may be more difficult for the new entrant.
That's why RISC V's win (if it occurs) will be because it's Open Source. Linux won in 30 years against everyone else due to that.
I'm guessing it already has a lot of influence over Arm though and there are other factors that strongly act in favour of staying with Arm.
If Nvidia takes over Arm though and starts making life difficult for the ecosystem then that could change ....
It would be interesting to know how important the ARM instruction set is to Apple.
Seriously though, I suspect that the ISA isn't that important for Apple but on the other hand I think they're probably quite happy with the direction of the Arm ISA (probably had a big say in parts of it) and it would take quite a lot to push them away.
I think that the odds on the Nvidia takeover are quite small by now so don't think a move likely at all.
Will RISC V do what ARM did to x86? Start at the low end, be more open, and slowly take over.
Agree with the point 100% but Apple also has a history of long and sustained investments in key parts of the stack where it sees long term value - including compilers and silicon - and long relationships with suppliers. I suspect their relationship with Arm is in that category and so in the absence of something that is demonstrably better, then that will continue.
The Nvidia purchase is irrelevant to Apple. They have a license that won’t be impacted.
The only thing that would make them move away would be a performance bottleneck in the architecture that necessitates a shift.
Why do you assume this?
Large companies like Apple have an architectural license and implement the entire instruction set on their own.
I worked for a couple of companies with ARM architectural licenses and there was a large ARM compliance suite of tests that had to be run and pass before you could claim that you made an ARM instruction set compatible CPU.
I have heard that Apple does not claim ARM compatibility and doesn't run the compliance suite which allows them a few shortcuts and other optimizations. Apple only cares about running Mac OS and iOS on their hardware so if they were incompatible with Linux/ARM or Windows/ARM they wouldn't really care.
I haven't been able to verify this. Linux/ARM seems to be running okay so far on the new Apple M1 chips.
I don't know if Apple would be affected much if Nvidia buys ARM. Their architecture license to implement from scracth is probably forever but maybe not
Still leaves Apple open to potential Nvidia's changes to the ISA's direction (and the ISA won't stand still). I assume a full fork of the ISA isn't on the cards even for Apple.
That, of course, is just with the Mac since Apple previously used variants of the MOS 6502 (1975 and allegedly an illicit clone of the MC6800). Apple, Atari, Acorn, Commodore (the owner of MOS for several years), BBC, Oric, and Nintendo used it in multiple systems each. Apple, Acorn, and Nintendo built additional systems on its updated sibling the WDC65816 series (1983).
The the 6800/6809/Hitachi 6300/68k/Dragonball/Coldfire dynasty and the bastard MOS6502/WDC65816 families were collectively basically the ARM of their day in a way. Everyone targeting low priced or power-sipping was building platforms around them at one time or another. Acorn went from a customer to a major competitor and successor.
It should be noted that the PowerPC and the whole POWER ISA multi-platform family was largely inspired by Apple in the first place. They were talking to IBM about a new platform and invited Motorola to the talks as their long-time processor provider. They formed the "AIM Alliance" that eventually morphed into the POWER Foundation and OpenPOWER initiatives. I can't really speak to how much of POWER ISA is inspired by Motorola's own "RISC" processor, the 88000 series.
You can buy them used or new in various kind of servers.
> How many of those who have/can have it are running Illumos and are putting money/time in it?
Dunno, I'm not really a Solaris guy. I use Solaris as a hypervisor for Linux and BSD LDOMs.
> And more importantly what's the outlook for SPARC?
Well, you could make the very same argument about Illumos. The Python developers wanted to drop support for Solaris already and OpenJDK upstream did actually drop it.
Newer SPARC systems are really quite good. And pretty cost-effective too. The problem is that the starting price is out of reach, and almost nobody is offering a cloud service based on SPARC, so you can't hire it either.
I'm running illumos on SPARC. I have some old hardware (desktop and server) that I like to make use of. Time, yes, but I'm not putting money into it.
And while OpenJDK upstream has dropped support for SPARC and Solaris, that was really all about problems with the Studio compiler. I' maintaining an illumos OpenJDK port with the gcc toolchain on x86 - it's not excessively hard, and realistically if you're using a common toolchain and common CPU most standards-compliant code is portable at the OS layer.