Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Illumos to drop SPARC Support

github.com

Post reply on HN
Print view View original

41–50 of 184 posts

Re: Illumos to drop SPARC Support

#41

Post by klelatti »

userbinator wrote: post #17
spamizbad wrote: post #10

Earlier quoted context omitted.

A lot of these architecture have some drawbacks in modern times. 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…

...and MIPS has the weird branch delay slots as well as pretty horrible code density. 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.

Not sure anyone sees "pure" RISC as being an advantage these days though. Didn't Intel demonstrate that you could get RISC-like performance from a CISC ISA even with all the drawbacks of x86 (instruction decoding complexity etc).

Re: Illumos to drop SPARC Support

#42

Post by cbmuser »

sgift wrote: post #19
cbmuser wrote: post #11

Why don't they just upgrade GCC to a more recent version. GCC still actively supports SPARC to this date and Rust support is also present and while not perfect, it definitely works. So, while I don't really have a problem with removing SPARC support from Illumos which I wouldn't be using on SPARC systems anyway, the reasons mentioned in the document aren't convincing me at all. FWIW, we still support sparc64 in Debia…

How would upgrading GCC help with the problem that they don't have SPARC machines available for building Illumos?

Well, they could reach out to the Debian or Gentoo community and ask for help. We would be happy to help them.

Re: Illumos to drop SPARC Support

#43

Post by 1over137 »

spijdar wrote: post #33
sgift wrote: post #19

Earlier quoted context omitted.

How would upgrading GCC help with the problem that they don't have SPARC machines available for building Illumos?

It wouldn't, but they state that one of the benefits of dropping SPARC is being able to "[retire] the now-ancient GCC 4.4.4 shadow compiler that remains chiefly to support the SPARC platform" I'm guessing the problem isn't that newer GCC lacks SPARC support, but that their (now very old and bitrotted) SPARC support relies on some kind of undefined behavior or nuance of GCC 4 that prevents newer versions from building…

Illumos is a BSD, so perhaps, like other BSDs, they don't want to rely on GPLv3 projects like (current) gcc.

Re: Illumos to drop SPARC Support

#44

Post by cbmuser »

macksd wrote: post #29
cbmuser wrote: post #12

Earlier quoted context omitted.

> It's mildly interesting to me that there's now really no notable big-endian systems left 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.

Though as we recently learned, it's considered sufficiently "fringe" by a big chunk of the development community that it's not that big a deal to drop support for it. (Not to imply IBM couldn't be sponsoring development for it more).

But s390x support isn't dropped anywhere. On the contrary, IBM spends a lot of money and efforts to make sure it is well supported by free software.

Re: Illumos to drop SPARC Support

#45

Post by onedognight »

PedroBatista wrote: post #25
hulitu wrote: post #3

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.

Yes, but where can I buy a SPARC CPU? How many of those who have/can have it are running Illumos and are putting money/time in it? And more importantly what's the outlook for SPARC?

Intel (née Movidius) were selling SPARCs a year or two ago in the Myriad 2. SPARC is an open source CPU with solid GCC support.

Re: Illumos to drop SPARC Support

#46

Post by cbmuser »

PedroBatista wrote: post #25
hulitu wrote: post #3

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.

Yes, but where can I buy a SPARC CPU? How many of those who have/can have it are running Illumos and are putting money/time in it? And more importantly what's the outlook for SPARC?

> Yes, but where can I buy a SPARC CPU?

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.

Re: Illumos to drop SPARC Support

#47

Post by erk__ »

tyingq wrote: post #23
pabs3 wrote: post #7

Earlier quoted context omitted.

IIRC ARM devices can also be big-endian and GCC can even generate big endian 64-bit ARM code: https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html

Yeah, you can find an ARM big endian distribution of, for example NetBSD. No Linux that I can find. Apparently boot issues are a bit tricky.

I have found a Gentoo distribution with big endian for the raspberry pi 3, so it is out there https://github.com/zeldin/linux-1/releases

Re: Illumos to drop SPARC Support

#48

Post by spijdar »

1over137 wrote: post #43
spijdar wrote: post #33

Earlier quoted context omitted.

It wouldn't, but they state that one of the benefits of dropping SPARC is being able to "[retire] the now-ancient GCC 4.4.4 shadow compiler that remains chiefly to support the SPARC platform" I'm guessing the problem isn't that newer GCC lacks SPARC support, but that their (now very old and bitrotted) SPARC support relies on some kind of undefined behavior or nuance of GCC 4 that prevents newer versions from building…

Illumos is a BSD, so perhaps, like other BSDs, they don't want to rely on GPLv3 projects like (current) gcc.

Illumos is a fork of Solaris, itself a UNIX System V derived OS, very much not a BSD, though taking some code from BSD. I'm not sure what license they make new additions under, but the core is CDDL licensed and not BSD licensed, anyway.

(side tangent FWIW, NetBSD has no qualms with using GPLv3 GCC, only Free/Open do)

(Edit for another historical tangent: Sun helped create System V release 4, which specifically combined element of older SysV with BSD. Additionally, Solaris/"SunOS 5"'s predecessor SunOS 4 was a straight-up BSD. So Solaris is a pretty BSD-y UNIX, in a way...)

Re: Illumos to drop SPARC Support

#49

Post by octotoad »

1over137 wrote: post #43
spijdar wrote: post #33

Earlier quoted context omitted.

It wouldn't, but they state that one of the benefits of dropping SPARC is being able to "[retire] the now-ancient GCC 4.4.4 shadow compiler that remains chiefly to support the SPARC platform" I'm guessing the problem isn't that newer GCC lacks SPARC support, but that their (now very old and bitrotted) SPARC support relies on some kind of undefined behavior or nuance of GCC 4 that prevents newer versions from building…

Illumos is a BSD, so perhaps, like other BSDs, they don't want to rely on GPLv3 projects like (current) gcc.

Illumos is from the System V family tree, as it is a direct descendant of OpenSolaris.

Re: Illumos to drop SPARC Support

#50

Post by mastax »

userbinator wrote: post #17
spamizbad wrote: post #10

Earlier quoted context omitted.

A lot of these architecture have some drawbacks in modern times. 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…

...and MIPS has the weird branch delay slots as well as pretty horrible code density. 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.

Nowadays RISC seems to mean "load-store architecture" but I think the term should be left in the 90s. CS curriculum is slow to evolve.
Post reply on HN