RANT : Learning From the Amiga API/ABI : Zerro Below

All opinions on this site are those of the author alone.
No warranty of any kind is provided.   All information herein is provided as is without any warranty of any kind.

ASM
FUN
RANTS
WORK
CODE

Learning From the Amiga API/ABI:

The Amiga ABI is one of direct calling into shared libraries, without any run time linking at all. This is accomplished by calling through a table of branch instructions that is at a known point in the library. There is one library that is always at the same address, that being Exec.library, which includes the functions to get the addresses of the tables of other libraries. This is an ABI that can be learned from, and can be used today even with modern memory protection. In many ways the Amiga ABI is the ideal for applications written in C, Pascal, BCPL, Assembly Language, BASIC, etc as it does not rely on any CPU specifics and allows for any common methods of memory protection (memory protection is helpful to aid in developing software and finding bugs).

There are many things about the way that the API of Amiga OS is implemented that make for a much more usable Operating System than most are familiar with today. These include the way that the kernel implements lists, message passing, and multitasking, the way that Intuition implements call back widgets, the way BOOPSI does not need an OO language to provide OO programming for Intuition, etc. There has not been another OS that is as simple to program for or as well thought out as Amiga OS (and those clones that use Amiga Hunk format executable and library files).

All libraries are called by calling a negative offset from the library base address (need not be related to the image base address). On 680x0 based systems each entry is 6 bytes, consisting of a far branch instruction (two bytes for the opcode, four for the address). As far as I know it is 4 bytes per entry on PowerPC based systems (never had a PowerPC Amiga computer). This is for traditional Amiga OS, now that one branch uses ELF and Dynamic linking there is a debate about which is better, in my view it is hunk without any dynamic linking needed.




Exec, the Microkernel:

At the core of the Amiga OS API is Exec, a Microkernel that presents itself as a library with a call table base address of 0x000004 (on 680x0 systems). The Exec.library provides functions for memory management, task management, universal list management, starting a library (and getting the base), retrieving the base address of a loaded library, and some system management functions. Exec knows nothing about the HW, that is left to higher level libraries. Exec is one of the first widely successful Microkernels, and still today one of the best.




AmigaDOS and ARP:

AmigaDOS is a library that provides for the Disk and file I/O, as well as a lot of other device I/O management. AmigaDOS also provides the standard CLI of the Amiga OS, which is fairly simple to use.

The original versions of the AmigaDOS.library were ported from the TripOS file, device, and CLI library. This means that the early versions of AmigaDOS had an API that was heavily influenced by BCPL (the language of TripOS), and not as natural to C programmers. Enter ARP.library (AmigaDOS Replacement Library) that provides a more natural C API for the DOS functions. While early versions of ARP.Library were separate in Amiga OS up through 1.3, this effort became the default AmigaDOS in Amiga OS 2.0 and later.

The reason for mentioning AmigaDOS and ARP in this document is that it is one that began as a missfit though became a good fit later. With ARP replacing much of AmigaDOS showing how dynamic the OS is do to its well thought system of libraries.




Intuition:

Many forget the amazing Windowing System that is provided by Intuition, even before BOOPSI ever came into being. Intuition at its core is its own task that is able to call into user applications to deliver Windowing System messages, allowing a task to appropriately respond even if the primary task is temporarily zombied out. Think about that, in modern nix systems with X or Aqua how often do you see a task go zombie and be unresponsive as a result, this was not an issue in AmigaOS do to Intuition (except with very poorly written or very poorly ported programs).

In other systems events are delivered to the program, and the main program loop has to handle them, even in preemptive multitasking systems. This was simply not the case with Intuition, where the event handling can be completely asynchronous to the primary program.




WIP : TBC:

WIP: To Be Continued.

This is a Work In Progress. I wish to provide some insight, though not go into too much detail (I have an Amiga section on this site).




This site hosted by NEOCITIES
THIS SITE BEST VIEWED IN YOUR FAVORITE BROWSER
© 2022 David Cagle