One thing which has been causing me to scratch my head more than any other as I have chugged along the development of CORNELIUS (my bare-metal operating system and language for the Raspberry Pi) is the difference between the code needed when building an application and the code needed when running an application. For example, …
It’s funny how ideas work their way out sometimes. Today I spent an hour ow two simplifying the memory map for my operating system and language CORNELIUS. I had thought that the way I had laid out the memory was pretty much as simple as it could be for this application, but just yesterday it …
Following on from yesterday’s post about developing code which uses the memory-mapped IO on the Raspberry Pi, but on a separate development system which does not have the same hardware, I began to think about the steps needed for testing such code. The first stage is unit-level testing. As much of the code as possible …
I’m trying to make a concerted push on a first working version of CORNELIUS at the moment, and it’s throwing up all sorts of interesting aspects of software development. For the first version I am building the minimum OS and language in C. However, I am trying very hard to minimise the amount of C …
I feel as though I have been spending most of my CORNELIUS efforts on the ELIUS (language) part, and neglecting the CORN (operating system) part. Recently, though, I have been thinking about the notion of a “hardware abstraction layer” (HAL). This is a common part of many systems, and serves to isolate the messy, hardware-specific …
Forth, and similar languages inspired by Charles Moore’s approach to software have evolved in a particular direction. Like Donna Noble in “The Doctor’s Daughter”, FORTH is “good with numbers”, but traditionally very limited in its string processing abilities. In Programming A Problem-Oriented-Language (POL), Moore writes: What can you do with a character string? I’ve only …
I have been reading about the early days of FORTH recently, and learned a lot about the ideas and philosophy behind the language and the system. In the past, when I had tried to create my own FORTH-style languages I think I was missing something important. I had been confusing the “language” of available FORTH …
A few days ago I took a few small steps toward creating a project structure and build process which would allow me to build and test the majority of my bare-metal Raspberry Pi code on my development (Windows or Linux) machine, with only the very hardware-specific bits needing to be built and tested on the …
Continue reading ‘Unit testing bare-metal Raspberry Pi code’ »
Several Posts ago, during a discussion of why I am interested in bare-metal operating systems development, I linked to Charles Moore’s biography on his ColorForth.com web site. At the time I was interested in looking at a variety of stack-based languages for inspiration, including ColorForth. Sure enough, ColorForth had some interesting ideas, but what stopped …
Continue reading ‘Programming a Problem-Oriented Language’ »
A few days ago I wrote about looking for metaphors to get to grips with what happens when a computer appears to be doing multiple things for multiple people at one time. The outcome was some ideas based on the physical metaphor of a house I lived in while studying at university. At that point …