31–40 of 68 posts
I'm surprised at how m68k was rescued from oblivion in 2013... Who is using it?
Amiga users (like me), Atari users, x68000 users and mac classic users, among others. Some of these are using netbsd/m68k (like me), with some overlap.
Earlier quoted context omitted.
Just informational: the esc sound meaning "-like" is rendered as esque . We "borrowed" it from the French, and we're not giving it back.
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.
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.
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?
Earlier quoted context omitted.
Just informational: the esc sound meaning "-like" is rendered as esque . We "borrowed" it from the French, and we're not giving it back.
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.
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…
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?
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.
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?
Looking forward to a standardized MMU interface and page table format.
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…
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.