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

Rust to C compiler – 95.9% test pass rate, odd platforms

fractalfir.github.io

Post reply on HN
Print view View original

221–230 of 264 posts

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#221

Post by cbmuser »

dralley wrote: post #159
CursedSilicon wrote: post #146

Earlier quoted context omitted.

Hi, retro computing person here. I've had a similar debate with Rust evangelists in past Something the Rust community doesn't understand is when they shout "REWRITE IT IN RUST!" at a certain point that's simply not possible Those mainframes your Bank runs? I'm sure they'd love to see all that "awful" FORTRAN or C or whatever other language rewritten in Rust. But if Rust as a platform doesn't support the architecture?…

>Those mainframes your Bank runs? I'm sure they'd love to see all that "awful" FORTRAN or C or whatever other language rewritten in Rust. But if Rust as a platform doesn't support the architecture? Well then that's a non-starter But Rust does support S390x? >Worse still, Rust seems to basically leave anything that isn't i686/x86_64 or ARM64 as "Tier 2" or worse Rust has an explicit documented support tier list with g…

> But Rust does support S390x?

It's not a tier-1 target though.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#222

Post by dralley »

cbmuser wrote: post #221
dralley wrote: post #159

Earlier quoted context omitted.

>Those mainframes your Bank runs? I'm sure they'd love to see all that "awful" FORTRAN or C or whatever other language rewritten in Rust. But if Rust as a platform doesn't support the architecture? Well then that's a non-starter But Rust does support S390x? >Worse still, Rust seems to basically leave anything that isn't i686/x86_64 or ARM64 as "Tier 2" or worse Rust has an explicit documented support tier list with g…

> But Rust does support S390x? It's not a tier-1 target though.

And?

How extensively is GCC testing on s390x, and do they hard-block merging all patches on s390x support being 100% working, verified by said test suite in a CI that runs on every submitted patchset? Or at least hard-block releases over failing tests on s390x? Do they guarantee this in a written document somewhere?

If they do, then that's great, they can legitimately claim to have something over Rust here. But if they don't, and I cannot find any reference to such a policy despite searching fairly extensively, then GCC isn't providing "tier 1"-equivalent support either.

I work for Red Hat so I'm well aware that there are people out there that care a lot about s390x support and are willing to pay for that support. But I suspect that the upstreams are much looser in what they promise, if they make any promises at all.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#223

Post by FractalFir »

cbmuser wrote: post #220
hedgehog wrote: post #115

Earlier quoted context omitted.

Did they abandon that goal? Last I heard it was still under development.

Well, the promise was that rustc_codegen_gcc would reach its goals very quickly which is why several people dismissed projects such as gccrs. But it turns out that rustc_codegen_gcc still hasn't delivered and it seems the project has fallen asleep.

I am not affiliated with `cg_gcc`, but I have contributed some tiny things here and there.

Currently, `cg_gcc` is within spitting distance of being able to bootstrap the compiler. There really are only 3(!) bugs that currently stop a stage 2 build.

I know for sure, because I found workarounds for them, and have a working stage 2 build. A stage 3 build requires a bit more RAM than I have, but, besides that, it is definitely possible.

Those 3 bugs are: 1. Lack of support for 128 bit SwitchInt terminators(Rust IR equivalent of switch). This is likely caused by an issue on the GCC side, since libgccjit rejects 128 bit labels provided by `cg_gcc`. 2. A semantic difference between Rust's `#[inline(always)]` and `__attribute__((always_inline)) `. In Rust `#[inline(always)]` is a hint and works on recursive functions, but the GCC equivalent is not a hint, but a gurante, and does not work on recursive function. 3. `cg_gcc` miscompiles the Rust compiler's interner code if level 3 optimzations are enabled. The Rust compiler interner is quite complex, and does a lot of fiddly unsafe things, so it is the most likely to break. The exact cause of this issue is hard to pin down, but it can be worked around(by setting a lower opt level).

If you work around those issues, `cg_gcc` is able to successfully build the Rust compiler, at least on `x86_64 Linux`. Going from that to other architectures will still take time, but it is not as far away as some might think.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#224

Post by koakuma-chan »

ryao wrote: post #214
koakuma-chan wrote: post #197

Earlier quoted context omitted.

Are you asking for LTS releases? https://ferrocene.dev/en/

I was not asking for that. I was answering your question. You asked for evidence of rust releases being abandonware. I gave it to you. Someone else trying to ameliorate Rust releases does not change this reality.

Well “abandonware” is a strange way to call that because nothing is actually abandoned.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#225

Post by koakuma-chan »

ryao wrote: post #210
koakuma-chan wrote: post #196

Earlier quoted context omitted.

I'm confused. Rust uses semantic versioning: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. What kind of version…

C and C++ are two different languages. They are versioned by years. Rust technically does not have versions. The rust tools have versions. Basically all versions of C are binary compatible with each other. I suggest you actually learn and use C rather than asking questions since you are never going to ask the right things to understand how it works without having firsthand experience.

> C and C++ are two different languages. They are versioned by years.

That sounds like Rust editions.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#226

Post by koakuma-chan »

ryao wrote: post #211
koakuma-chan wrote: post #205

Earlier quoted context omitted.

We're talking about learning C/C++ from scratch which makes no sense to do by using a decades old book because it wouldn't teach you any modern features. Also we're not talking about computer science.

You do not need to know about modern features to write code in C. This is part of computer science.

> You do not need to know about modern features to write code in C.

Then what’s the point of adding any new features?

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#227

Post by koakuma-chan »

ryao wrote: post #212
koakuma-chan wrote: post #194

Earlier quoted context omitted.

> The only way you could think this is if you have zero knowledge of these languages. Exactly. For context see my original comment above about C/C++ books being paid.

Are you unable to use search engines: https://www.learn-c.org/ There are so many free learning resources for these languages that it is ridiculous to say that you need books to learn them. The books are great, but non-essential. If you insist on reading books, there is an ancient invention called a library that you can use for free.

What C standard does that website describe?

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#228

Post by koakuma-chan »

ryao wrote: post #208
koakuma-chan wrote: post #199

Earlier quoted context omitted.

Does he prefer fighting libtool, make, cmake, configure, automake, autoconf and autoreconf just to add a couple libraries into his project? When I tried to use C, I wrote 10 lines of code and spent hours trying to make all that shit work. It makes me laugh when people say Rust is complicated.

It really is not that complicated. You just use -llibrary when linking and it links.

Oh I never realized I was supposed to install -dev packages, I thought I had to compile myself.

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#229

Post by whytevuhuni »

koakuma-chan wrote: post #177
uecker wrote: post #170

Earlier quoted context omitted.

Too much complexity, long build times, monomorphization, lack of stability / no standard, poor portability, supply chain issues, no dynamic linking, no proper standard, not enough different implementations, etc. It is a nice language though, but I do not prefer it over C.

> long build times, monomorphization Monomorphization is what causes long build times, but it brings better performance than dynamic dispatch. > lack of stability There was another comment which also never elaborated on how Rust is not stable. > supply chain issues Not a language issue, you choose your dependencies. > no proper standard, not enough different implementations Is that a practical problem? > no dynamic l…

> > no dynamic linking

> There is.

Eh, I'm a Rust fan, and I hate the dynamic linking situation too.

I genuinely cannot see how Rust would be able to scale to something usable for all system applications the way it is now. Is every graphical application supposed to duplicate and statically link the entire set of GNOME/GTK or KDE/Qt libraries it needs? The system would become ginormous.

The only shared library support we have now is either using the C ABI, which would make for a horrible way to use Rust dependencies, or by pinning an exact version of the Rust compiler, which makes developing for the system almost impossible.

Hopefully we'll get something with #[export] [1] and extern "crabi" [2], but until then Rust won't be able to replace many things C and C++ are used for.

[1] https://github.com/rust-lang/rfcs/pull/3435

[2] https://github.com/rust-lang/rfcs/pull/3470

Re: Rust to C compiler – 95.9% test pass rate, odd platforms

#230

Post by IshKebab »

dzaima wrote: post #216
IshKebab wrote: post #215

Earlier quoted context omitted.

Accessing non-existent CSRs is another big one, which also means you can't probe for features. There's loads more though. Just search for "reserved" in the ISA manual. Of course a Rust to C compiler is not going to hit any of these. I was just pointing them out.

Fair point on CSRs, though I'd count that as a subset of unsupported/not-yet-specified instructions; pretty sure all of the "reserved"s in the spec are effectively not-yet-defined instructions too, which'll have equivalents in any architecture with encoding space left for future extensions, not at all unique to RISC-V. But yeah, no try-running-potentially-unsupported-things-to-discover-what-is-supported; essentially…

Yeah I guess the difference is once an instruction/CSR has been defined in x86 or ARM the only two options are a) it doesn't exist, and b) it's that instruction.

In RISC-V it can be anything even after it has been defined.

Actually... I say that, but they do actually reserve spaces in the CSR and opcode maps specifically for custom extensions so in theory they could say it's only undefined behaviour in those spaces and then you would be able to probe in the standard spaces. Maybe.

I think they just don't want people probing though, even though IMO it's the most expedient solution most of the time. Otherwise you have to go via an OS syscall, through the firmware and ACPI tables, device tree or mconfigptr (when they eventually define that).

Post reply on HN