In my last post, we explored how to build WASM modules, both with and without WASI support, using Clang. In a comment on Reddit, it was mentioned that much of the setup I walked through in that post could be avoided by just leveraging Zig’s WASI supprt. This is a great point, and I would recommend doing the same. The following command is inarguably simpler than what I described. $ zig cc --target=wasm32-wasi However, there are two reasons why knowing how to use Clang for compilation is useful.| danielmangum.com
I recently acquired an ESP32-C3-DevKitC-02 module, and, as I tend to do, jumped right into reading about how the system boots and how the (pretty good!) tooling Espressif offers works. We have typically used QEMU in the RISC-V Bytes series, but getting our hands on physical hardware starts to make things feel a bit more real. In this first post on the ESP32, we’ll do some basic setup and look at a simple custom bootloader.| danielmangum.com
In the last two posts in the RISC-V Bytes series we have looked at a bootloader for the ESP32-C3, then built a Zephyr application that was loaded by it. In this post we’ll take a closer look at that “Hello, World” application, diving into what happens prior to printing our message to the UART console. Note: all analysis and code samples used in this post correspond to the v3.3.0 release of Zephyr.| danielmangum.com
If you write any code that deals with manual memory management, you are likely familiar with the concept of a “use after free” bug. These bugs can be the source of, at best, program crashes, and at worst serious vulnerabilities. A lesser discussed counterpart to use after free, is “use after return”. In some cases, the latter can be even more troublesome, due to the operations that are performed when one procedure calls another.| danielmangum.com
This is part of a series on the blog where we explore RISC-V by breaking down real programs and explaining how they work. You can view all posts in this series on the RISC-V Bytes page. I once took a class on compilers where my professor told us that a CPU is like a human brain: it can store important data and access it quickly, but there is a limit to the amount of data that can be stored.| danielmangum.com
This is part of a series on the blog where we explore RISC-V by breaking down real programs and explaining how they work. You can view all posts in this series on the RISC-V Bytes page. So far in this series, we have been looking at the assembly generated when compiling relatively simple programs. At this point, we have seen instructions that perform a wide variety of operations. Let’s take another look at our minimal example from the Passing on the Stack post:| danielmangum.com
This is part of a series on the blog where we explore RISC-V by breaking down real programs and explaining how they work. You can view all posts in this series on the RISC-V Bytes page. It has been a bit since our last post, but today we are going to begin our journey into some of the more interesting areas of RISC-V systems. In the first post in the series, we installed our RISC-V toolchain, which included QEMU.| danielmangum.com