Top • Entries • FAQ • Features • Screenshots • Downloads • Links

25 November 2003

What I want, part 1

What I want Karig to have and to be able to do is subject to change. At the moment I'm still teaching myself how to do things. In the short run, the Karig feature list will be driven by the features I know how to implement. For example, I know how to use the BIOS services to read from and write to disk, but not how to use the ports to control the floppy and hard disk controllers directly — so Karig will use the BIOS services for now. In the long run, however, there will be a number of features that Karig should get eventually.

My main requirement is that Karig be simple. I don't want to implement a complex solution when a simple one will do. I don't want to add to Karig something that an OS is supposed to have if I don't believe I really need it. I probably also won't be adding too many safeguards to protect against programmers' mistakes — I figure that I'll probably be the only person writing code for Karig, so the only mistakes I need to guard against are my own. I don't mind if this means that Karig ends up a toy, because I picture Karig as a toy OS anyway — something enjoyable to play around with, not something you'd use to host a website.

ColorForth

Two things inspired me to work on Karig. Chuck Moore's colorForth system is one of the two.

ColorForth has two sides. On the one hand, it's a programming language. On the other hand, it's an operating system.

ColorForth is probably the simplest programming language there is. A word in colorForth is just a sequence of printable characters surrounded by whitespace, and every word corresponds to a chunk of code to run. Words are executed in the order in which they appear in the source code; there are no precedence rules or parentheses or curly braces to change the order. Condition words set or clear the zero flag in accordance with some condition; the word IF inserts a JZ instruction to skip over code if the condition was not true. The word definition is the basis for the loop; there is no need for special loop keywords such as WHILE or UNTIL. ColorForth has a severely restricted vocabulary, so writing a compiler for it is easy.

It is vital that the colorForth compiler be as fast as possible, because colorForth runs programs by compiling their source code on the fly. Executable programs are stored as pre-parsed source code, not as machine code in any form. First, source code is saved, not as ASCII text, but as 32-bit "cells." Each cell represents not only a particular word but also what the compiler is supposed to do with it — create a new word definition, create a CALL instruction to the word's definition, run the word's definition during compile-time, and so on. Second, a major portion of the compiler is made up of words that are to be run at compile-time, not when the program being compiled is run. For example, the definition for IF is run at compile-time, in order to add a JZ instruction to the end of the machine code being generated. Words that would be "reserved" or "keywords" in other languages are compile-time words in colorForth. This helps to keep to a minimum the work that the compiler must do, and therefore the compiler itself is small and fast.

On the other hand, colorForth is an operating system — again, one of the smallest and simplest in existence. Some of its attributes are as follows:

• No memory protection. All code runs in Ring 0, so there are no restrictions on what the code can do. There is nothing to stop the programmer from experimenting with the hardware; there are no barriers for him to circumvent. Of course, there's also nothing to stop the programmer from trashing the system, whether by accident or by design.

• Single-user. The system was designed to be used by a single user, so there are no login screens and no password files.

• Two threads. The number of threads that can run at once is apparently fixed at two. One thread updates the video display, and the other one takes care of everything else.

• Cooperative multitasking. Each thread yields to the other; they are not interrupted at arbitrary points, as they would be on a pre-emptive multitasking system. Thus there is no need for locks or critical sections, or any of the other gimmicks that are required to ensure that two or more threads can share a resource (a device or a section of memory) but that only one thread at a time can actually use the resource.

• Dual-stack architecture. This is required by all versions of Forth, not just colorForth: You need one stack for return addresses, and you need another stack for passing data between subroutines and the code that calls them.

• Word dictionary. The dictionary is that which tells the compiler what source-code word corresponds with what section of code. It is equivalent to a symbol table in C, except that the symbol table lasts only as long as it takes for compilation to complete, and the dictionary remains always in memory. It makes the compiler faster to relieve it of the chore of rebuilding the dictionary whenever another compilation job is begun.

• Single-load. Everything is read from disk into memory in one go at startup. The system never has to open files later on.

• Floppy-based. ColorForth loads from and saves to floppies only. It does not touch the hard disk.

Jef Raskin

My other inspiration for Karig is the work of Jef Raskin. He wrote a book called The Humane Interface, and he designed a simplified computer called the Canon Cat [documentation]. Some of the suggestions that Raskin makes are as follows:

• Use quasimodes; avoid modes. Regular modes are to be avoided, because after you put the computer in a mode, it is easy to get distracted, forget about the mode, and enter a command that doesn't work as you expect as long as the mode is in effect. Thus modes trip you up.

  Any key, any toolbar button, that functions both to turn something on and to turn it off again — such as the Caps Lock key, or the buttons for bold and italic on a word-processor toolbar — introduces modes. You have to stop and look at the toolbar, the status bar, and the keyboard before you know what's going to happen when you start typing or moving the mouse. This makes the computer harder to use.

  A quasimode is a mode that is in effect only as long as a key is being held down — once you let go of the key, the quasimode is no longer in effect. You cannot forget that the computer is in a quasimode. One obvious example is the use of the Ctrl key as a command key — in Windows, as long as you're holding down the Ctrl key, the C key copies the current selection to the clipboard.

• One set of commands. The software on the computer should not consist of a collection of applications, each with its own way of doing things. There should be a single set of commands that always work no matter what you're doing. For example, the same text-editing commands that work when you're typing a document should be available when you're adding text to a picture, or entering data into a database field. If there is a command to change the contrast in a picture, it should be available whenever you need to edit a picture, regardless of the context. In other words, there are no applications; there are only commands.

  (Applications introduce modes, because very often a keystroke that does one thing in one application does something completely different in another application.)

• Universal undo. The system should store a history of the edits that the user makes to each document, so that each change can be undone and then redone. This makes the system more forgiving of the mistakes a user makes.

• "Calculate" command. It would be useful to be able to highlight some text describing a mathematical formula (such as "4 + 3") and to hit a key to store the original formula away somewhere and replace the formula with its result (7). Storing the formula is useful if the formula needs to be recalculated, as it might be if it depends on the results of formulas stored elsewhere (which would be the basis for the spreadsheet).

• No files. The user shouldn't have to open files to get to his documents; he should just be able to boot up the system and enter the command to find his document and have the system bring it to him. In addition, all documents should be available simply by scrolling through the sequence of documents that comes up after the system boots.

• Incremental search. The Canon Cat provided a Leap Forward key and a Leap Backward key. The user would hold down the Leap Forward key (to search forward) and type in the first few characters of the string he was looking for. The system would respond, on each keypress, by bringing up the first occurrence of the text that the user had typed so far. The text that the user was looking for could contain spaces, carriage returns, page breaks, and document breaks, so he could find the beginning of the current document by holding the Leap Backward key and hitting the Document Break key.

• Dedicated keys for critical commands. Some commands, such as Undo and Find, are useful often enough that each one should be run by pressing a single key.

This essay is getting awfully long, so I'll post Part Two later.

Check the index for other entries.