Since Wyrm is utilizing a bootstrapped Scheme variant, building data structures and writing files is surprisingly difficult. Scheme provides the ability to express almost any construct, but without standard libraries every tiny detail most be determined.
The “actual” Wyrm system will eventually provide low level data structures and type support. Any construct utilized by “Mini Scheme” will require duplication between both the Wyrm Scheme implementation, and the “generic” Scheme based system. Writing the ELF decoder, the first obvious challenge to address is some form of structured data support. Normal scheme applications might use a SRFI-1 based “associative list”. Ideally, Wyrm will implement an associative container with “better performance”, but for now, utilizing a wrapped associative list works well. Given the newly defined “dictionary” type, the next hurdle is implementing basic support for serializing structures. For this, a new ‘encoding’ structure is created. With a defined dictionary type and serialization structure, implementing basic support for the primary ELF file header is simple.
So far, basic Test Driven Development (“TDD”) practice has allowed development of substantial infrastructure without gnarly scaffolding. The current ‘Wyrm’ program remains a simple “Hello World” display, but substantial support for ELF and “Wyrm” common scheme library support is present.
The huge challenge remains focus. Even basic decisions get easily bogged down if considering all the possible angles of a full toolchain ecosystem. Worse, there’s nearly infinite complexity possible if attempting to expand to a more modern feature set. But, without the massive set of refactoring and “intelligent” coding tools, any added functionality becomes massively distracting. A worthwhile detour might include integrating Visual Studio Code for improving quick reference documentation.
With the July 4th Holiday, I enjoyed a 3-day weekend but intentionally limited the time I spent hacking on Wyrm. There’s a lot to unpack in creating a full operating system and toolchain (even with a limited scope). Instead of jumping into full fledged implementation, I took the opportunity to brainstorm and structure the project.
Given we’ve got a hugeeeee amount of work ahead in bootstrapping a kernel and toolchain, the big question becomes “where to start”. For this project, I’ll be trying to maintain a “Test Driven Development” practice. A unit test framework also creates a simplified environment for early development.
The first project milestone will be a “Hello World” constructed kernel from our toolchain. Qemu supports loading a binary ELF image, and most portable toolchains will work with ELF binaries. For the first project milestone, the Wyrm toolchain will construct a valid ELF kernel image with a “Hello World” assembly kernel. With ELF, the Wyrm toolchain may create images for either or fledging OS or the Linux ecosystem. The end-goal is a fully self-hosting system – but until that point, Linux or Windows can provide a host environment.
If someone forced me to select a ‘favorite’ programming language, I’d likely fall into the Python camp. Python does not, unfortunately, make for a good “system” programming language. However, both Julia and Nim advertise some degree of compiled / system programming features. For our toolchain, I’m going to pull a page out of Julia’s playbook and utilize the simplicity of Scheme for compiler and runtime implementation. With a strong Scheme toolchain, I hope to experiment with a maybe-Python / maybe-Scala frontend. With a scheme-work-alike, we can utilize a “proper” scheme implementation to bootstrap the system. I’ve selected “Chicken Scheme”.
With the few commits this weekend, there’s a small test framework and the start of some low level scheme primitives for building ELF files.