# 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 I would like to take this moment to express my gratitude to Pasi 'Albert' Ojala for [his written 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 (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 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.**