rustc_codegen_gcc
linux
Our great sponsors
rustc_codegen_gcc | linux | |
---|---|---|
49 | 980 | |
864 | 169,627 | |
1.9% | - | |
9.6 | 10.0 | |
6 days ago | 2 days ago | |
Rust | C | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
rustc_codegen_gcc
-
How hard would it be to port the Rust toolchain to a new non-POSIX OS written in Rust and get it to host its own development? What would that process entail?
Alternatively, there's another initiative called codegen_gcc which is about using GCC as a backend for the rustc compiler. It's (much) more advanced in Rust support, but I am not sure how easy it would be to use a modified libgccjit from there.
-
Rust contributions for Linux 6.4 are finally merged upstream!
Theres also an official GCC backend for rustc in the works, rustc_codegen_gcc
Yeah, rustc_codegen_gcc is a GCC backend for rustc, and its making a lot of good regular progress.
-
GCC 13 and the State of Gccrs
gcc-rs is one of two projects for bringing Rust to gcc. gcc-rs is the more ambitious of the two, with an entirely new frontend. There is also rustc_codegen_gcc (https://github.com/rust-lang/rustc_codegen_gcc) that keeps the rustc frontend, and only swaps out LLVM for GCC at the codegen stage.
-
Any alternate Rust compilers?
Additionally, there is gcc codegen for rustc (https://github.com/rust-lang/rustc_codegen_gcc), which is not a compiler per se, but an alternative code generator, with more architectures supported and other nice things. It's also coming along, but there's still a lot of work to do there too. There's also Cranelift codegen (https://github.com/bjorn3/rustc_codegen_cranelift), which is designed to make debug builds faster, but this is not as exciting/useful as the other 2.
-
rustc_codegen_gcc: Progress Report #21
Good idea. I added the tag "help wanted" to the issue.
-
A brave new world: building glibc with LLVM
I'm excited about both the backend & the frontend.
-
Rust front-end merged in GCC trunk
There is also a project for rustc to use GCC instead of LLVM for codegen.
-
Rust front-end approved for merge into GCC
All problems which the already existing rustc_codegen_gcc project does not have. As a supported code generation backend to the actual Rust compiler, it provides all the supposed benefits of GCC's Rust improved target support and literally none of the many downsides.
Not to be confused with rustc_codegen_gcc, which allows Rustc to use GCC as an alternative backend. gccrs is an alternative implementation of rustc (and Cargo) in C++ for GCC.
linux
- Show HN: Running TempleOS in user space without virtualization
- Linus Torvalds accepts a merge commit to the Linux kernel
-
TinyMCE (also) moving from MIT to GPL
Correct. And the combined work needs to carry the MIT license text and copyright attributions for the MIT software authors. With binary distribution it must also be overt, not hidden in some source code drop, but directly accompanying the binary.
Many people who talk about relicensing never credit the MIT developers or distribute the MIT license text. "Because it's GPL now."
I don't think that you believe that, but many developers do.
Some don't see the need for source code scans for Open Source compliance, because the license.txt says GPL, so it's GPL. Prime example is the Linux kernel. There is code under different licenses in there, but people don't even read https://github.com/torvalds/linux/blob/master/COPYING till the end ("In addition, other licenses may also apply.") and conclude it's simply GPL 2 and nothing else.
Also be aware that sublicensing is not the same as relicensing.
-
The Linux Kernel Prepares for Rust 1.77 Upgrade
So If we would only count code and not comments, it is only 9489 LoC Rust. Which would be about 0.03% and if we take all lines and not only LoC it would be around 0.05%
[0] https://github.com/XAMPPRocky/tokei
[1] https://github.com/torvalds/linux/commit/b401b621758e46812da...
-
Proposed Windows NT sync driver brings big Wine/Proton performance improvements
AIUI fsync is built on futex_waitv which has been upstreamed. So this has to be more than that.
https://github.com/torvalds/linux/commit/a0eb2da92b715d0c97b...
-
Tell HN: GitHub no longer readable without JavaScript
git clone --no-checkout --depth 1 https://github.com/torvalds/linux.git $dir
-
PixieFail: Nine Vulnerabilities UEFI Implementations
Device trees are what you get if you don't implement ACPI.
While there are alternatives, you generally seem to get "device trees and a barebones bootloader" on ARM and "UEFI + ACPI" on amd64.
ACPI will list hardware and necessary hardware properties based on some basic API calls to the system interface. UEFI initialises the ACPI data structure and exposes it to the bootloader so the appropriate drivers can be loaded and configured.
With device trees, you basically configure and build the drivers and configuration into the kernel/OS you're trying to load. That's why compiling Linux on amd64 is generally easy and produces a single image, while for many other devices (smartphones, some SBCs) you need to compile a kernel per device. The device trees only need to be imported/written once per device (or device type, depending on how nice the manufacturers are), but that's how you get stuff like this: https://github.com/torvalds/linux/tree/master/arch/arm64/boo...
On ARM there are actually a few devices that implement UEFI, but most of them have Secure Boot locked in and configured to only boot Windows.
ACPI is not perfect and it's not technically required to have UEFI to implement something better than device trees, but I'm not sure if reinventing the wheel here is necessary or even preferable. UEFI already has open source implementations ready to go, with kernels and other tools already containing code to interact with those APIs, whereas a custom ACPI replacement protocol would need more implementation work,
-
Maestro: A Linux-compatible kernel in Rust
The Linux Kernel Driver Interface
(all of your questions answered and then some)
https://github.com/torvalds/linux/blob/master/Documentation/...
-
Uniting the Linux random-number devices
A bit later another commit [1] was merged that makes reads from /dev/urandom opportunistically initialize the RNG. In practice this has the same result as the reverted commit on non-obsolete architectures, which do have a cycle counter and thus jitter entropy.
[1] https://github.com/torvalds/linux/commit/48bff1053c172e6c7f3...
The commit [1] was eventually reverted [2]
[1] https://github.com/torvalds/linux/commit/6f98a4bfee72c22f50a...
What are some alternatives?
zen-kernel - Zen Patched Kernel Sources
DS4Windows - Like those other ds4tools, but sexier
winapps - Run Windows apps such as Microsoft Office/Adobe in Linux (Ubuntu/Fedora) and GNOME/KDE as if they were a part of the native OS, including Nautilus integration.
Open and cheap DIY IP-KVM based on Raspberry Pi - Open and inexpensive DIY IP-KVM based on Raspberry Pi
serenity - The Serenity Operating System 🐞
DsHidMini - Virtual HID Mini-user-mode-driver for Sony DualShock 3 Controllers
RyzenAdj - Adjust power management settings for Ryzen APUs
void-packages - The Void source packages collection
edk2-sdm845 - (Maybe) Generic edk2 port for sdm845
illumos-gate - An open-source Unix operating system
vscode-gitlens - Supercharge Git inside VS Code and unlock untapped knowledge within each repository — Visualize code authorship at a glance via Git blame annotations and CodeLens, seamlessly navigate and explore Git repositories, gain valuable insights via rich visualizations and powerful comparison commands, and so much more
gccrs - GCC Front-End for Rust