Preface
After joining INF, I started shifting to FPGA driver work and heterogeneous computing API development, which is even more low-level than my previous work on networking libraries. Although our PCI driver is now relatively mature and there are not many holes left to fill, many details are still worth understanding thoroughly, so that I can keep stepping into pitfalls in the future... So over the past few weekends I reviewed IA32 system architecture, finally finished CSAPP (should have done that long ago; procrastination...), and then worked through NJU's system architecture lab ics2016. Overall, the gains were significant. The key point is that there are too many concepts in system architecture that, if you only read the theory, are easy to forget—after all, they are not that relevant to day-to-day work—so the experience and depth of understanding you get from reading a book versus writing code yourself are completely different.
NEMU
The main content of this system architecture lab is essentially implementing a simple—or rather crude—version of an IA32 virtual machine. Although the codebase is not particularly large and performance is quite constrained, it is small but complete. After finishing it, you can boot a simplified operating system—in fact, it only provides the most basic system calls. The highlight is that on top of that you can run a simple typing game, and even the DOS version of The Legend of Sword and Fairy! That result is pretty interesting, but looking at the implementation details of the whole project, you can tell that to achieve such a fun outcome, the students who designed the lab must have stepped into countless pitfalls.
In short, although emulating an instruction set sounds easy, in the second phase of the lab, personally grinding through the emulation of a large number of CISC instructions makes you feel like you are eating shit. The overly messy instruction encoding design of i386, the complicated operand formats, and the vague—or even error-ridden—documentation make you seriously question the world: how did something this disgusting end up dominating the market?! The only explanation I can accept is that back then, compiler and linker authors encapsulated these messy details well enough that users did not have to feel it.
Another headache with nemu is that its emulation performance for the IA32 memory mechanism is truly disastrous. After finishing it, when running The Legend of Sword and Fairy, I found the game lagging badly. After profiling, I discovered that a huge amount of time was spent on memory reads and writes—which is not surprising. Segmentation, TLB, paging, L1/L2 cache: when these operations are chained together, it is not an exaggeration for a single memory access to become hundreds of times slower. After all, using loops to emulate set-associative or even fully associative caches is inherently catastrophically slow... Hardware circuits can perform cache lookups efficiently, but software cannot! And even if you disable cache emulation, performance may actually get worse, because the overhead of layered simulated memory calls is simply too large. Under the existing design framework, there is basically no way to optimize it. This is also different from a real virtual machine: a VM can use some tricks to "fool" the hardware into performing address translation efficiently. So this "pseudo-VM" called NEMU is still good enough for profiling tasks like tracking cache hit rates for simple programs, but once the complexity exceeds something like Sword and Fairy, it is not feasible to tinker with it there.
Kernel
As mentioned above, this Kernel is actually a highly simplified version. The main difficulty is debugging, because support for interrupts and serial output is only added in the final stage of the lab. Before that, debugging any code running inside nemu relies entirely on reading assembly and dynamically tracing assembly. This process, however, greatly deepened my understanding of the gcc compiler, and was actually a good experience. Overall, the most valuable part of this lab is really the pitfalls + debugging—it adds a lot of experience.
SDLPAL
Finally, a few words about The Legend of Sword and Fairy. It is the biggest highlight of the entire lab, and whoever prepared the lab must have put a lot of effort into porting it. In practice, only a handful of functions from the SDL library are ultimately used. Although it runs unbearably laggy on my MBP, it truly connects everything end to end. But I have to complain: since this lab is hosted publicly, it should also have the data prepared. Instead, I had to piece things together for a long time before I found all the corresponding data files. I am speechless.
Also, one somewhat incomplete aspect is that the kernel hardcodes the names, sizes, and so on of these data files. In reality, it could be made a bit more complex by designing an fs that supports creating and reading/writing files, storing filename information on the virtual disk rather than hardcoding it in the code. That would make the overall organization much cleaner.
End
Well, I finished cs143 over the National Day holiday, and now I have also wrapped up ics2016. So the next goal is MIT 6.828, and I hope to finish it within two months. Looking back, I spent my wonderful undergraduate years on ACM and research on ocean numerical models. After switching fields, it is too late for regrets; I can only write more code in my spare time. These excellent assignments, combined with classic books, really bring a fundamental understanding of the essence of the corresponding field.