Live data from Hacker News

Debian Riscv64 port in mid 2019

people.debian.org

41–50 of 68 posts

Re: Debian Riscv64 port in mid 2019

#41
post #20
post #17

Earlier quoted context omitted.

Yeah would love to have a RISC-V board with similar performance as a Pi and that isn't as expensive as the hifive unleashed. Haven't found anything yet.

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 :-/ )

Re: Debian Riscv64 port in mid 2019

#42
post #24

Earlier quoted context omitted.

Similarly to "isch" from German, which we filed the serial numbers off of, and respelled "ish". For some reason we are squeamish about doing that to French. Perhaps ironically, we took squeamish from French escoymous , but substituted "our" suffix.

"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.

Re: Debian Riscv64 port in mid 2019

#43
post #27

Earlier quoted context omitted.

This is probably what you mean: https://github.com/thepowersgang/mrustc It's still a work in progress, with only x86 even supported. It's not a GCC frontend, it generates C, and is based on an old version of rust (1.19). Right now I think it's only useful to bootstrap rust, but that doesn't help you get a backend for another architecture.

Why not? Just bootstrap but on another architecture?

That is the usual case, but some people don't want to download any binary blob that's not a C compiler.

Re: Debian Riscv64 port in mid 2019

#44
post #38

Earlier quoted context omitted.

Why not? Just bootstrap but on another architecture?

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.

Re: Debian Riscv64 port in mid 2019

#45
post #7

Earlier quoted context omitted.

The Unleashed board has a performance similar to a Raspberry Pi 3 in cpu terms but it's biggest bottleneck is that the SD card is running on a SPI bus where it gets something like 2MB/s. This is due to having the complete SOC as opensource and the SD card association not allowing open source IP for it's interface.

I think there's some degree of compatibility between SD-card and MMC-card standards, and that the latter are comparatively more open. Surely that could solve the open-IP issue?

Last time I looked both MMC and SD were JEDEC standards available under the same terms?

Re: Debian Riscv64 port in mid 2019

#46
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.

> Basically LLVM is now a dependency of equal importance to GCC for Debian.

Yes, exactly. And until then, every time a new dependency on LLVM (or by extension on Rust) appears, users of architectures LLVM doesn't target complain bitterly and threaten to fork the last version without that dependency. (This argument has happened for Firefox, rsvg, and recently bzip2.)

Re: Debian Riscv64 port in mid 2019

#47
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.

Re: Debian Riscv64 port in mid 2019

#48
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 :-/ )

[deleted]

Re: Debian Riscv64 port in mid 2019

#49
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?

AFAIK there's no gcc port underway. There is another Rust compiler[1] but it's not a complete alternative to Rustc, in the short run it was mainly intended to be a way to bootstrap a Rust compiler without needing to go all the way back to the original ocaml implementation of the first Rust compiler. As such, it is only known to output correct binary when running on the code of the Rust 1.19 compiler. This was a reall…

Right, one can use mrustc to compile 1.19, but then they would need to progress through 1.XX -> current. A container chain for bootstrapping the Rust compiler would be a good idea.

Re: Debian Riscv64 port in mid 2019

#50

I'm surprised at how m68k was rescued from oblivion in 2013... Who is using it?

I suspected that it had something to do with ColdFire. It seems that was partly true, but another interesting factor was apparently ARAnyM (an Atari 68k ST/TT/Falcon emulator) which can conveniently run a Linux system: https://grep.be/blog/en/computer/debian/m68k/arrakis/

I used to run Debian/68k under aranym... Thanks Pelagatti
Post reply on HN