Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 19:01 UTC (Mon) by flussence (guest, #85566)
Parent article: Woodruff: Weird architectures weren't supported to begin with

> I put this one last because it’s flippant, but it’s maybe the most important one: outside of hobbyists playing with weird architectures for fun (and accepting the overwhelming likelihood that most projects won’t immediately work for them), open source groups should not be unconditionally supporting the ecosystem for a large corporation’s hardware and/or platforms.

Isn't the whole root of this discourse that *Rust* is one of those?

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 19:43 UTC (Mon) by farnz (subscriber, #17727) [Link] (21 responses)

What do you mean by "Rust is one of those"? It's not hardware, nor is it a large corporation's platform (it's a programming language with an open-source implementation). And the complaint from the affected users is that their weird hardware is no longer supported because pyca switched from being C + Python to being C + Rust + Python, but the affected users aren't in a position to enable Rust support for their weird hardware. It's easy to forget that bringing up open source on a weird hardware platform took time and effort to begin with - GCC did not magically get an ARM backend in 1987, someone had to code it - and that it will take time and effort to keep the weird platforms working.

We've been in a long period of stability when the frontends GCC has defined what was a usable language for open source - either it needed a GCC frontend, or it needed an interpreter that only depended on GCC, and the backends GCC has defined what CPUs and platforms were usable. That stability is coming to an end, as more people turn to LLVM as their preferred compiler/JIT framework instead of GCC. and the resulting languages turn out to be interesting to more than just academia. In turn, this means that people who have been able to free-ride on the work done on GCC for their architecture in the past are losing that free ride, and will have to pay the LLVM (and possibly Rust) taxes for their architecture. Note, of course, that if you were starting truly from scratch with a hobby OS and CPU ISA, you'd also have to port a compiler, a libc, and many more pieces.

In the end, this is a natural extinction event for many architectures - if you really need support for hardware that LLVM doesn't currently work with, you either need to do what people like John Paul Adrian Glaubitz are doing and step up to provide support for your hardware in LLVM (and possibly Rust), or you need to accept that it's a toy project, and that if you don't have the resources to follow where the big boys are going, then you're not going to be able to keep up with the modern world.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 21:09 UTC (Mon) by pizza (subscriber, #46) [Link] (13 responses)

> In turn, this means that people who have been able to free-ride on the work done on GCC for their architecture in the past are losing that free ride, and will have to pay the LLVM (and possibly Rust) taxes for their architecture.

The thing is, *everyone* involved is getting some amount of "free ride". Including the pyca authors.

(And speaking of folks using these old architectures, the remaining holdouts tend to be the ones who had historically provided said free ride. They're been putting in sweat equity, and telling them "you have to do a _lot_ more work now" is ... kinda crappy..)

> In the end, this is a natural extinction event for many architectures - if you really need support for hardware that LLVM doesn't currently work with

It also widens the chasm that any new architecture needs to cross in order to be viable.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 22:33 UTC (Mon) by roc (subscriber, #30627) [Link] (3 responses)

Requiring LLVM doesn't necessarily widen the gap, since we can probably eliminate the requirement for a GCC backend.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 10:00 UTC (Tue) by xophos (subscriber, #75267) [Link] (1 responses)

As soon as the linux kernel builds reliably with clang...

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 5, 2021 18:29 UTC (Fri) by khim (subscriber, #9252) [Link]

Well… there are billions of people who use clang-built kernel today… thus should count for something…

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 13:05 UTC (Tue) by pm215 (subscriber, #98099) [Link]

I suspect most companies working on compilers would love to be able to focus on one compiler rather than two; but I would not bet on llvm taking over from gcc for generic desktop/server Linux in the next decade. Inertia is a strong force, it's currently only just verging on even technically possible (compiling the kernel with clang is only possible for a few architectures right now, I think), and for distros and server/desktop end-users there really isn't a strong motivation to change. (Contrast macos, Android and the BSDs, where the license is a motivating force.)

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 10:41 UTC (Tue) by farnz (subscriber, #17727) [Link] (4 responses)

Same sorts of things have happened in the past with other architectures, too, though - the people who brought us VAX and PDP-11 support were told that they didn't matter any more, and they didn't choose to keep doing the work

That's why I talk about this as a natural extinction event - we've had a period where the free ride was relatively widespread, and now it's being narrowed again to just the platforms that people who do the work care about (whether that's because they can do the work themselves, or are willing to pay for it to happen). Once the kernel compiles with clang (or someone revives https://dragonegg.llvm.org/), then the chasm narrows back down - you have to get LLVM supported, but you lose the need to support GCC in return.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 16:17 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> Once the kernel compiles with clang
Android has been building production kernels with clang for 2 years.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 19:52 UTC (Tue) by flussence (guest, #85566) [Link]

Isn't LLVM *better* at compiling the kernel right now? IIRC the LTO patchset only works with clang.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 5, 2021 7:35 UTC (Fri) by dvdeug (guest, #10998) [Link] (1 responses)

Are you going to compile the GNU utilities on a compiler that wasn't supported to begin with? It seems weird to respond to a complaint about people compiling for unsupported architectures to propose that you can begin to compile everything with a compiler that isn't supported upstream.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 5, 2021 9:28 UTC (Fri) by farnz (subscriber, #17727) [Link]

It puts you in exactly the same position that you're in now, but with a suite of compilers that support all the languages you want - remember that while the GNU utilities are only supported upstream with GCC, nothing is supported on your platform until you have a working compiler.

Thus, you're providing the support for everything - and I would have as much time for you complaining that GNU utilities don't work on your new platform as I have for people complaining that Rust doesn't work on their niche platform (none at all - you're the one doing something that upstream isn't supporting, you deal with the fallout).

And depending on what you're doing, you might not need the GNU utilities at all - Busybox, for example, provides alternatives to the GNU utilities.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 10:53 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

And also, a lot of the complaining is coming from people who haven't provided said free ride; the complainants talking about HPPA and S390 are literally complaining that it used to build on those architectures, but doesn't any more. I have a lot more time for the complaints about M68k support because (a) they're coming from people who actually used and bugfixed the software in past releases on M68k, and (b) they're actually working to find a way forward with Rust support for the platform.

If I flip the question round, it becomes clearer to me: what degree of effort does a project have to make to be compatible with platforms that are no longer properly updated? Are we choosing to limit ourselves to the versions of C and C++ that're supported by MIPSPro on IRIX because there are people who want to use it (there's a surprisingly vibrant IRIX hobbyist base), or are we going to say that you can use C99, C++11 and other more modern languages, and those platforms need to keep up or die off?

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 15:38 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

> there's a surprisingly vibrant IRIX hobbyist base

Interesting. CMake dropped support for IRIX years ago (because we don't have anything to test with). Are they just using an old CMake version, only using software from that era, or doing everything with CMake-less projects (possible, but more likely a result of not updating software stacks I'd imagine)?

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 3, 2021 9:14 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

Mostly running period-appropriate software on them, and either fixing things locally or not using modern software.

The systems involved tend not to be internet-connected because of this - the risk of running IRIX 6.5 on today's Internet is not worth taking.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 4, 2021 22:22 UTC (Thu) by ejr (subscriber, #51652) [Link]

It wasn't worth taking that risk then, either. xauth + at boot...

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 19:05 UTC (Tue) by flussence (guest, #85566) [Link] (6 responses)

> What do you mean by "Rust is one of those"? It's not hardware, nor is it a large corporation's platform (it's a programming language with an open-source implementation).

Java, Golang, C#, and Swift also have open implementations (some of them even bother to derive those from a specification), but most of us understand that “who owns C?” is a uniquely nonsensical question to ask.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 19:25 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

> but most of us understand that “who owns C?” is a uniquely nonsensical question to ask

That would apply to Rust as well since unlike other examples in your list, there is no single vendor driving the language.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 19:36 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

I think a lot of people still think of Rust as being something Mozilla is pushing, even though Mozilla has now laid off most of the Rust developers they once employed.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 2, 2021 23:48 UTC (Tue) by roc (subscriber, #30627) [Link]

I'm not aware of a single person Mozilla currently pays to work on Rust ... which is great. Rust grew up and Mozilla doesn't need to invest in it anymore.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 6, 2021 18:55 UTC (Sat) by Mook (subscriber, #71173) [Link] (2 responses)

There's an important difference between C and Rust at this point though; there are multiple production-level C compilers, but only one for Rust. That means that there is a chance that some group could take over Rust development in the future. In contrast, there are multiple production C compilers, some of which are closed source (and therefore difficult to take over).

That's probably reflective of Rust still being under heavy development; mrustc is smaller in scope (doesn't aim to do borrow checking), and still could not keep up to date with the current compiler. This is not really the fault of any party, of course.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 6, 2021 21:33 UTC (Sat) by farnz (subscriber, #17727) [Link]

On the other hand, that makes Rust the same as Linux; there's only one complete Linux kernel, but it's not exactly owned by any one company in particular. In theory, someone could buy out Linus and have the One True Linux Kernel, but in practice enough other people are involved that this is not a risk.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 6, 2021 23:05 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

There are efforts to add a Rust frontend for GCC: https://github.com/Rust-GCC/gccrs

Rust is getting pretty stable now, so this actually starts to make some sense. And unlike Go, Rust is a fairly straightforward language, it doesn't need a runtime or GC.