> 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.)
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 cmov memory -> register blocks speculation?
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 think Thorsten Glaser resurrected the port because he wanted to test his shell (the MirBSD Korn shell) on m68k. Many other people also helped of course.
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 really successful project, but it's not something you can use to replace to compile your own arbitrary rust code.
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.
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.
Nightly Rust already has basic RISC-V support, but the problem is Rust's libc binding is not yet ported to RISC-V. Without libc, Rust's std will not be usable, that's the main blocker here. While the theory is you don't require std to compile a Rust program, most, if not all, Rust programs leverage std in some extent.
What's the precise problem? As far as I know the privspec has standardized enough in this area.
In any case, as one of the maintainers of the Fedora/RISC-V port (we also work closely with Debian) we're relaxed about kernel changes, because those are simple to make. (The big problems are changes in userspace code and glibc)
Any "Pi'esc" boards available yet? I would love to run Buster on a RISC-V board.
Seeedstudio has an "Arduino'esc" RISC-V board for around USD 30 which looks very interesting. [1]
This board [2] also looks very interesting but is around USD 1000 and I can't find any comparisons on performance to a "regular" PC. I know these things are like comparing apples to oranges but I would like to know how for example a browser performs loading a webpage in comparison with another CPU.
There also appears to be an expansion board with PCI so you can add a GPU for USD 2000. [3]
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.
Whoa, I had considered the unleashed board to play around with and bookmarked it, but they are not very overt with the price. I didn't realize it was $1000 USD. You have to click through twice to discover it.
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.
[+] [-] josteink|6 years ago|reply
Hopefully this will help motivate expanding architecture-support for LLVM, and by proxy Rust.
[+] [-] JoshTriplett|6 years ago|reply
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.)
[+] [-] simcop2387|6 years ago|reply
[+] [-] ncmncm|6 years ago|reply
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 cmov memory -> register blocks speculation?
[+] [-] kstenerud|6 years ago|reply
[+] [-] boomlinde|6 years ago|reply
[+] [-] pmarin|6 years ago|reply
[+] [-] snvzz|6 years ago|reply
Some of these are using netbsd/m68k (like me), with some overlap.
[+] [-] ncmncm|6 years ago|reply
[+] [-] littlestymaar|6 years ago|reply
[1] https://github.com/thepowersgang/mrustc
[+] [-] pedrocr|6 years ago|reply
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.
[+] [-] Dylan16807|6 years ago|reply
[+] [-] xuejie|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] ncmncm|6 years ago|reply
Just can't live without that popcount.
[+] [-] kristianp|6 years ago|reply
[+] [-] Taniwha|6 years ago|reply
[+] [-] sjmulder|6 years ago|reply
There's some work to be done in rust on portability - it's been a problem in pkgsrc too.
[+] [-] als0|6 years ago|reply
[+] [-] rwmj|6 years ago|reply
In any case, as one of the maintainers of the Fedora/RISC-V port (we also work closely with Debian) we're relaxed about kernel changes, because those are simple to make. (The big problems are changes in userspace code and glibc)
[+] [-] sschueller|6 years ago|reply
Seeedstudio has an "Arduino'esc" RISC-V board for around USD 30 which looks very interesting. [1]
This board [2] also looks very interesting but is around USD 1000 and I can't find any comparisons on performance to a "regular" PC. I know these things are like comparing apples to oranges but I would like to know how for example a browser performs loading a webpage in comparison with another CPU.
There also appears to be an expansion board with PCI so you can add a GPU for USD 2000. [3]
[1] https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-...
[2] https://www.sifive.com/boards/hifive-unleashed
[3] https://www.crowdsupply.com/microsemi/hifive-unleashed-expan...
[+] [-] stan_rogers|6 years ago|reply
[+] [-] carlosedp|6 years ago|reply
[+] [-] asveikau|6 years ago|reply
[+] [-] 0x76|6 years ago|reply
[+] [-] snvzz|6 years ago|reply
If that's insufficient, your best bet is to get a risc-v capable FPGA.