Goals

1. Develop the knowledge necessary to write a dynamic loader for the ELF file format, targeting a platform which explicitly lacks memory management features of any kind.

2. Develop software to serve as an example for future reference.

Rationale

The Kestrel-3's first several iterations will not include memory management features, just to keep things very simple. Nonetheless, it should have an operating system ported to it to make the computer usable interactively; in the longer term, it should be able to self-host software development directly on the Kestrel-3 itself.

To that end, I intend on porting a proper and minimal subset of AmigaOS functionality to the Kestrel-3, consisting primarily of exec.library and dos.library, and perhaps a few ancillary support modules. This should give the user a minimal, yet functionally complete, Tripos-like user experience.

Problem Statement

I intend on porting the system software from the BOAR Project. I would like to take this moment to express my gratitude to Pasi 'Albert' Ojala for his written permission to do so.

This will involve a ground-up rewrite of exec.library to take advantage of the RISC-V CPU's features; however, dos.library and its disk-resident tools should be portable enough in plain C to run almost as-is.

The BOAR project, however, uses a variation of the a.out format. Contemporary development tools easily available to most people no longer supports this format; further, its specific details differs depending both on CPU architecture as well as which OS you build the executable on. For this reason, we cannot use a.out for the Kestrel-3's disk-resident programs and libraries.

As I write this, the Executable and Linkable Format (ELF) has all but dominated the market for executable and dynamically linked library formats. In particular, software development tools for the RISC-V instruction set architecture all use ELF as their common object and executable format.

However, ELF has only one problem relevant to the Kestrel-3 project: it depends heavily on the host OS running a multiple-address-space, memory protected runtime environment. Because the Kestrel-3 lacks memory management or a kernel sophisticated enough to take advantage of it (for now), everything must run in a single address space. Executables can no longer be compiled and linked assuming they'll reside at a prescribed virtual address; the loader must select a unique location each time it loads a module from disk.

This means that applications and Exec-style shared libraries must be compiled as Position Independent Executables. These are, so far as I can discern, "shared object" files which happens to also include a PT_INTERP program header. (True shared object files do not need a PT_INTERP program header.)

Per the ELF standards, the program outlined in the .interp section (which the PT_INTERP program header covers) is typically launched by the host OS to take care of loading the ELF, relocating it, and performing any kind of symbol fixups required to get execution started. It then relies on run-time binding of imported symbols to resolve symbols only when they're needed. It is this "interpreter" which this project aims to explore and develop.