Live data from Hacker News

Debian Riscv64 port in mid 2019

people.debian.org

51–60 of 68 posts

Re: Debian Riscv64 port in mid 2019

#51
post #19

They say Rust support is blocked by having no RISC-V backed for LLVM, and no Rust Gcc front-end. But I thought there was a working Gcc front-end, just without the borrow checker, which is superfluous for code generation. Maybe it is for an old version of the language, and can't build the current library?

The lack of LLVM backend surprises me. How much work is it to add a backend with 60 instructions (and few addressing modes)? It's clearly far more than I would have guessed.

LLVM has an experimental Riscv backend. Adding it is easy. QAing it to the point that is can be considered non experimental is a lot of work.

Re: Debian Riscv64 port in mid 2019

#52
post #38

Earlier quoted context omitted.

Just because you may have a functional compiler running on a another architecture, doesn't mean the compiler actually outputs code FOR that architecture. The compiler would still only support the architectures it did when you bootstrapped it, which in that case would not include that specific architecture.

The Rust compiler is a cross-compiler by default, so the usual way that you bootstrap on a new platform is to add it to the existing compiler, and then cross-compile to the new architecture. Which is what I read your parent as suggesting.

The discussion is not about bootstrapping. Bootstrapping using mrustc on riscv64 would get you a working rust 1.19 compiler that runs on riscv64 and knows how to emit x86 code. It wouldn't even allow you to go up to the latest version. That's not very useful, Debian already has a rust compiler that emits x86, it needs a rust compiler that emits riscv64.

Re: Debian Riscv64 port in mid 2019

#53
post #23
post #5

Basically LLVM is now a dependency of equal importance to GCC for Debian. Hopefully this will help motivate expanding architecture-support for LLVM, and by proxy Rust.

Godbolt shows that Clang is a lot more aggressive with use of "cmov" -- conditional move instructions. When the Spectre and Meltdown family of security debacles surfaced, cmov was promoted as a way to choke off speculative execution. But that suggests, also, that cmov would be bad for performance in places where cross-process security isn't a concern. Did something important change, or did I misunderstand? Maybe only…

Choice of cmov vs branch is pretty tricky because profitability depends on branch probabilities, which are commonly not known. LLVM has an X86 cmov conversion pass that does this based on some cost modeling for loop-carried dependencies, but it does not always make the right choice. Common problem is binary search code where you really, really want that cmov, but might not get it.

Re: Debian Riscv64 port in mid 2019

#54
post #41
post #20

Earlier quoted context omitted.

The likely source will be lowrisc.org. Several folks that were involved with the Rpi are on the project. "We will produce a SoC design to populate a low-cost community development board and to act as an ideal starting point for derivative open-source and commercial designs." - https://www.lowrisc.org/docs/untether-v0.2/

I wouldn't hold your breath (although I wish them luck). There are however a bunch of low cost high performance RV64 chips coming this year and next from China that will change things dramatically. (I'm a Fedora/RISC-V maintainer, and I'm in Beijing today and tomorrow talking to RISC-V people. It's 23:57 here, got to go to bed :-/ )

Do you know what companies are making them? I'd love to take a closer look as I've also been looking for a risc-v rpi alternative.

Re: Debian Riscv64 port in mid 2019

#55
post #52

Earlier quoted context omitted.

The Rust compiler is a cross-compiler by default, so the usual way that you bootstrap on a new platform is to add it to the existing compiler, and then cross-compile to the new architecture. Which is what I read your parent as suggesting.

The discussion is not about bootstrapping. Bootstrapping using mrustc on riscv64 would get you a working rust 1.19 compiler that runs on riscv64 and knows how to emit x86 code. It wouldn't even allow you to go up to the latest version. That's not very useful, Debian already has a rust compiler that emits x86, it needs a rust compiler that emits riscv64.

Right. They could add the riscv64 backend to the current compiler, and then cross-compile it from x86_64, meaning that the bootstrap chain for riscv64 would start at 1.37.0. No mrustc even needed.

That said, I feel like we may be talking past each other... what I'm saying is, to get support for riscv64, you don't need to do a full new bootstrap. Maybe I'm misunderstanding the point of the thread.

Re: Debian Riscv64 port in mid 2019

#56

Earlier quoted context omitted.

There's also the Apollo core used in the Vampire accelerator, that's much faster than anything else m68k, and even faster than ColdFire.

Yes, but that doesn't explain the m68k porting effort of 2013. The Apollo core doesn't have an MMU so it won't run Linux.

Wait, even a 68040 embedded the MMU on die. The Apollo core doesn't have a MMU?

Re: Debian Riscv64 port in mid 2019

#58

Earlier quoted context omitted.

Yes, but that doesn't explain the m68k porting effort of 2013. The Apollo core doesn't have an MMU so it won't run Linux.

I thought m68k/nommu exists and is used?

That's true and I didn't know of that. That said, the Amiga configuration depends on an MMU. I don't know how hard it would be to retarget it for an MMU-less system.

Re: Debian Riscv64 port in mid 2019

#59

Earlier quoted context omitted.

"From Middle English -ish, -isch, from Old English -isċ (“-ish”, suffix), from Proto-Germanic -iskaz (“-ish”), from Proto-Indo-European -iskos." https://en.wiktionary.org/wiki/-ish

Yeah, it's a little misleading to say that English borrowed that ending from German, English is a Germanic language and always had it.

Ok, and "-ish" and "-esque" clearly both trace back to the Proto-indo-european. So we're really just talking about spelling standards, which are a recent innovation.

Re: Debian Riscv64 port in mid 2019

#60

Earlier quoted context omitted.

Yes, but that doesn't explain the m68k porting effort of 2013. The Apollo core doesn't have an MMU so it won't run Linux.

Wait, even a 68040 embedded the MMU on die. The Apollo core doesn't have a MMU?

I frequently see it advertised as not having an MMU, but it turns out that it does...it's just that it's a new design that isn't Motorola compatible.

On Amiga, where programs typically all live in the same shared memory space, this is not a great concern for a regular user. It could be useful for developers and some specialist applications, and of course for more modern OS models.

Post reply on HN