Intel and Rust: The Future of Systems Programming [video]
1–10 of 21 posts
Re: Intel and Rust: The Future of Systems Programming [video]
#2Interesting, the video mentions that the BIOS, Firmware, and Bootloaders used to be heavily implemented in assembly, and then nowadays it is mostly C with a sprinkling of assembly.
What's the chance this is also due to less limitations in the hardware, rather than C compiler achieving "parity" ?
Re: Intel and Rust: The Future of Systems Programming [video]
#3Interesting, the video mentions that the BIOS, Firmware, and Bootloaders used to be heavily implemented in assembly, and then nowadays it is mostly C with a sprinkling of assembly. What's the chance this is also due to less limitations in the hardware, rather than C compiler achieving "parity" ?
Memory mapped registers also help avoid the need to drop into inline assembly. I didn't get to the end of the video but it didn't seem like that was mentioned.
Re: Intel and Rust: The Future of Systems Programming [video]
#4Interesting, the video mentions that the BIOS, Firmware, and Bootloaders used to be heavily implemented in assembly, and then nowadays it is mostly C with a sprinkling of assembly. What's the chance this is also due to less limitations in the hardware, rather than C compiler achieving "parity" ?
My guess is that the assembly portions are used to get better optimization than available with C, which is also pretty common in Linux kernel development.
Re: Intel and Rust: The Future of Systems Programming [video]
#5Josh talks about a lot of exciting things that Intel's driving in Rust. Does anyone know if AMD is doing similar, especially around SIMD?
Re: Intel and Rust: The Future of Systems Programming [video]
#6Interesting, the video mentions that the BIOS, Firmware, and Bootloaders used to be heavily implemented in assembly, and then nowadays it is mostly C with a sprinkling of assembly. What's the chance this is also due to less limitations in the hardware, rather than C compiler achieving "parity" ?
Indeed, compilers are still very easy to beat on size optimisation, and the whole (U)EFI monstrosity was largely enabled by higher capacities of BIOS EEPROMs, which were in the 128/256KB range for a long time before multiple-MB ones became available. Now that motherboards with 16 and even 32MB(!) EEPROMs are available --- this is more than the entire RAM of regular PCs throughout the 80s and early 90s --- firmware has bloated considerably. In contrast, the original IBM PC had an 8KB BIOS.
If you looked at pre-EFI BIOS, they were exclusively written in very size-optimised and elegantly clever Asm; now it's just the usual bloaty compiler output you can find everywhere else, which makes me a bit sad.
Re: Intel and Rust: The Future of Systems Programming [video]
#7Interesting, the video mentions that the BIOS, Firmware, and Bootloaders used to be heavily implemented in assembly, and then nowadays it is mostly C with a sprinkling of assembly. What's the chance this is also due to less limitations in the hardware, rather than C compiler achieving "parity" ?
since C pretty much requires a stack, and a stack requires "RAM" of some form, it used to be necessary that the memory system be trained prior to executing any C code. however once the cache grew large enough, and appropriate "cache as ram" hooks were designed, it became possible to stand up a stack before even the memory system was alive. this definitely reduces the footprint which has to be assembly.
Re: Intel and Rust: The Future of Systems Programming [video]
#8Interesting, the video mentions that the BIOS, Firmware, and Bootloaders used to be heavily implemented in assembly, and then nowadays it is mostly C with a sprinkling of assembly. What's the chance this is also due to less limitations in the hardware, rather than C compiler achieving "parity" ?
since C pretty much requires a stack, and a stack requires "RAM" of some form, it used to be necessary that the memory system be trained prior to executing any C code. however once the cache grew large enough, and appropriate "cache as ram" hooks were designed, it became possible to stand up a stack before even the memory system was alive. this definitely reduces the footprint which has to be assembly.
CAR definitely works when a typical CPU these days has more RAM than an entire PC from the early 90s, but it's something that BIOSes (even pre-UEFI) have been doing for a long time, probably ever since CPUs had built-in caches that were large enough.
Re: Intel and Rust: The Future of Systems Programming [video]
#9Interesting, the video mentions that the BIOS, Firmware, and Bootloaders used to be heavily implemented in assembly, and then nowadays it is mostly C with a sprinkling of assembly. What's the chance this is also due to less limitations in the hardware, rather than C compiler achieving "parity" ?
Indeed, compilers are still very easy to beat on size optimisation, and the whole (U)EFI monstrosity was largely enabled by higher capacities of BIOS EEPROMs, which were in the 128/256KB range for a long time before multiple-MB ones became available. Now that motherboards with 16 and even 32MB(!) EEPROMs are available --- this is more than the entire RAM of regular PCs throughout the 80s and early 90s --- firmware ha…
To be fair to the modern BIOS, there is a whole lot more hardware to initialize than in 80s and 90s, the added ROM space isn't consumed only by bloated compiler output. Some motherboards store a second pristine copy of the BIOS image for fail-safe upgrades.
> and elegantly clever Asm
I personally miss returning boolean result in C (carry) flag.
Re: Intel and Rust: The Future of Systems Programming [video]
#10Interesting, the video mentions that the BIOS, Firmware, and Bootloaders used to be heavily implemented in assembly, and then nowadays it is mostly C with a sprinkling of assembly. What's the chance this is also due to less limitations in the hardware, rather than C compiler achieving "parity" ?
Indeed, compilers are still very easy to beat on size optimisation, and the whole (U)EFI monstrosity was largely enabled by higher capacities of BIOS EEPROMs, which were in the 128/256KB range for a long time before multiple-MB ones became available. Now that motherboards with 16 and even 32MB(!) EEPROMs are available --- this is more than the entire RAM of regular PCs throughout the 80s and early 90s --- firmware ha…
> If you looked at pre-EFI BIOS, they were exclusively written in very size-optimised and elegantly clever Asm; now it's just the usual bloaty compiler output you can find everywhere else, which makes me a bit sad.
As a person who cares way more about software reliability than cleverness, I am unreservedly happy about this change.