Hacker News Reader

Comment by shmerl | Hacker News Reader

Would be interesting to have a fully functional Rust compiler that's not based on llvm.

Sega genesis development

And Amiga, Atari, 68k-Macintosh etc.

FWIW, there is an out-of-tree m68k backend for LLVM [1]. I have already done some experimental work on Rust for m68k based on this backend [2].

> [1] https://github.com/M680x0/M680x0-llvm/

> [2] https://github.com/glaubitz/rust/tree/m68k-linux

Also, GCC has Xtensa ISA used on ESP8266/ESP32.

LLVM Xtensa port is in progress: https://github.com/espressif/llvm-xtensa

Lots of things are "in progress" (including rust support for gcc code generation, heh). But gcc has production-ready, mature backends for a ton of architectures that LLVM doesn't. It's a real feature.

Cranelift may become that in the future.

Although note the Cranelift backend has quite different goals from GCC and LLVM, being optimized for compiler speed over runtime performance, and is very unlikely to support many of the obscure backends that GCC can target.

Not likely, as the community is trying to get Rust to get ISO 26262. If they changed the compiler and they will have a whole lot more work to get it certified.

Unrelated. gcc-rust can be developed while rustc is ISO 26262 certified.

Out of curiosity, why would the community maintain two compilers. Wouldn’t that be double the work?

You mean like LLVM and GCC? Both compilers for C and C++ (and a lot more with various front ends). I can only imagine they're both maintained because people enjoy working on them and find them interesting projects to develop. When I find something interesting to work on, I certainly don't care that someone else is doing something similar somewhere else.

LLVM got where it is primarily because of GCC's licensing (and because GCC's design is deliberately compromised to support that licensing). It's unlikely that LLVM would have been maintained otherwise, and I would expect GCC to fall by the wayside in due course.

I would expect GCC to fall by the wayside in due course

This currently shows no sign of happening. What do you expect to change such that this happens?

It's unlikely that LLVM would have been maintained otherwise

Again, why? You're making this assertion as if it's fact, but there are a huge number of maintained pieces of software that do the same task as other maintained pieces of software. A great many pieces of software exist that didn't even get started until after similar software was already established. Do you have any logic behind your thinking beyond the fact that they're two pieces of software that do similar tasks?

I think your parent is exaggerating, but they do have a point. I can't point you to a concrete example off the top of my head, but there is quite a bit of anti-GPL sentiment in (parts of) the LLVM community. Apple I think is somewhat invested in spreading FUD about the GPL. I once spoke to some LLVM developers from Apple who said that they didn't believe they were allowed to look at the assembly code emitted by GCC, for copyright reasons. Which is strange since GCC explicitly does not claim copyright on its output.

That's why the LLVM people won't switch over to GCC, sure. But what do the GCC people think of it? If they're content to keep working on GCC, what's going to change such that they want to stop? I could imagine that if the LLVM group gets orders of magnitude ahead (seems unlikely - thus far, they seem to be mostly keeping up with each other in terms of performance and so on - but it could happen), GCC might start to be seen as a niche piece of legacy software and start to head towards retirement. Any other obvious pathways for the end of GCC?

Sorry, I should clarify: I think the OP had a point about licensing being a big factor in LLVM's uptake and especially its adoption by the likes of Apple and Google. I don't agree with the OP that this implies that GCC will be abandoned.

> This currently shows no sign of happening. What do you expect to change such that this happens?

Just natural turnover. I expect GCC to struggle to attract new developers. When it was clearly best open-source optimizer there was a certain cachet to it, but now all the advantages are with LLVM.

> Do you have any logic behind your thinking beyond the fact that they're two pieces of software that do similar tasks?

Apple in particular are documented as having tested the limits of GCC's licensing before funding work on LLVM; I believe other corporate contributors have made comments along the same lines.

Having independent language implementations is a good way to flush out unwarranted assumptions and other warts in the spec.

This is not an independent implementation, though.

GCC supports several targets like alpha, hppa, ia64, m68k, sh, v850 and vax (and more) that the LLVM-based Rust does not support because LLVM lacks support for these targets.

Okay, but:

* Alpha is more than a decade past end of life. * Hppa is EOL as of 6 years ago. * ia64 goes EOL next month.

.. and the list goes on. These aren't going concerns outside of some hobbyist work, and GCC has had difficulty retaining maintainers for some of the hardware and has threatened deprecation of them (in fact IA-64 is facing this exact situation and is going to be marked deprecated in GCC 10, and vanish in 11 https://gcc.gnu.org/ml/gcc/2019-06/msg00125.html). With instruction set support in that state, the odds are reasonable that bugs will be exposed, and difficulty will be had trying to support and fix them (exasperated by scarcity of hardware)

Adding support for obsolete hardware is not much of a good argument for taking on the work of supporting two compilers.

Also, m68k has been proposed for removal from GCC. (Dunno what actually happened.)

Motorola 68000 is still widely in use; why would they remove it?

https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02044.html

https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-m...

There are some back-end changes coming to GCC, and no one had ported m68k to it (presumably there is no maintainer for m68k in GCC?) The back-end code the m68k code was relying upon was going away, and it needed ported to use the modern one. Someone has stepped up and done that work, so it gets to live another day.

https://gcc.gnu.org/backends.html based on this is looks like avr, cris, h8300, mn10300 and vax are yet to be ported away from cc0.

It was proposed and retracted, because m68k got ported to the new infrastructure.

Is it the same folks for the two compilers?

I would welcome another rust compiler as it would give us choices.

Reply on news.ycombinator.com