Introduction Lately I’ve been doing a lot of work with the ARM64 instruction set, and I thought it would be fun to try to visualize it. ARM64 encodes every instruction as a 32-bit integer, so one way to visualize the instruction set is by plotting the instructions along a space-filling curve, such as a Hilbert curve1, and coloring them according to their instruction class (i.e., general, advsimd, float, sve, etc…).
I came across this issue on the Rust issue tracker recently: https://github.com/rust-lang/rust/issues/57893.
One of the GitHub comments shows how you can abuse this bug to write a transmute1 function without the use of unsafe (and then you can obviously use this to cause undefined behavior in Safe Rust programs).
trait Object<U> { type Output; } impl<T: ?Sized, U> Object<U> for T { type Output = U; } fn transmute_obj<T: ?Sized, U>(x: <T as Object<U>>::Output) -> U { x } fn transmute<T, U>(x: T) -> U { transmute_obj::<dyn Object<U, Output = T>, U>(x) } fn main() { // make a null pointer let p = core::ptr::null_mut(); // "safely" transmute it into a reference let x = transmute::<*mut i64, &'static i64>(p); // access the reference println!
A new feature in Knit I’ve been writing a build tool called Knit (I’ve written a blog post about it here). In Knit v1.1.0 there is a new feature I’m calling “dynamic task elision”, which allows Knit to skip a build step if, at the time when it tries to run the task, it can determine that out-of-date prerequisites that got rebuilt ended up not changing anything. This is possible thanks to Knit’s support for hash-based file modification detection (and is not possible if this feature is disabled).
This article is about a new build tool I’ve been working on called Knit. Check it out on GitHub!
What’s wrong with Make? This might be surprising but I actually like Make overall. It has a concise syntax for declaring dependencies, and it doesn’t make any assumptions about the programs I am building. These are the two biggest factors I consider when looking for a replacement, and so far I haven’t found any build systems that manage to keep Make’s core simplicity while improving on it1 2 3.
This is a follow-up to my previous post about writing bare-metal RISC-V programs using D. This time we’ll get our code running on actual hardware. We’ll be using the VisionFive 2 board, a recently released RISC-V SBC with 4 application cores (SiFive U74) clocked at a maximum of 1.5 GHz1 and 1 monitor core (SiFive S7). The main difference between the U74 cores and the S7 core is that the S7 core does not have an MMU, and therefore cannot support virtual memory – but that won’t be relevant to us today.
This post will show you how to use D to write a bare-metal “Hello world” program that targets the RISC-V QEMU simulator. In a future blog post (now available) we’ll build on this to target actual hardware: the VisionFive 2 SBC. See blog-code for the final code from this post. For a more complex example, see Multiplix, an operating system I am developing that runs on the VisionFive 2 (and Raspberry Pis).
Hi there! I’ve set up a blog. I’ll probably write about things I’m working on or find interesting. Lately that includes things such as OS development, the D programming language, symbolic execution, hardware design and verification (with Chisel), build systems, text editors, and more. Stay tuned!