What was the first operating system to feature a separate kernel?

Question

Kernels are programs that abstract the hardware of a computer to some extent, allowing other programs to use standardised system calls (e.g. malloc) to perform hardware tasks (e.g. writing to memory, displaying text on a screen) without resorting to "special memory values" or machine-dependent hacks.

Many early operating systems functioned as kernels. But by 1985 and the release of AmigaOS, separate kernels existed (i.e. Exec). When was the first independent* kernel** created?

^{* Where "independent" means "able to function without, or separately from, (the rest of) an operating system".
** Where "kernel", more specifically, means "resident monitor that is callable by user programs". (Thanks Ken Gober!)}

Answer 1

Reading through Per Brinch Hansen's The evolution of operating systems paper, I get the impression the two main candidates for operating systems with identifiably separate kernels are

• Dijkstra's THE multiprogramming system, started in 1965; it's a layered operating system — so you could view its layer 0 as a kernel, which is smaller than the whole operating system;
• Hansen's own RC 4000 multiprogramming system, built in 1969; it's the first operating system designed as separate components communicating with each other (which led to what are now known as microkernels).

To answer the revised question about callable monitors, the same paper indicates that

Atlas was the first system to exploit supervisor calls known as “extracodes”:

Extracode routines form simple extensions of the basic order code, and also provide specific entry to supervisor routines.

The Atlas system here is a computer built at Manchester University in the early 1960s.

Hansen's excellent book, Classic Operating Systems, reprints papers describing all these systems (and others) in detail. Regarding the Atlas supervisor:

It becomes activated in several different ways. Firstly, it can be entered as a direct result of obeying an object program. Thus, a problem being executed calls for the supervisor whenever it requests an action that is subject to control by the supervisor, such as a request for transfer to or from peripheral equipments or the initiation of transfers between core store and magnetic drums; the supervisor is also activated when an object program requires monitoring for any reason such as exponent or division overflow, or exceeding store or time allocation.

Answer 2

In the realm of microcomputers specifically, the BBC Micro of 1981 had a very sophisticated kernel in ROM for a machine of its class. There were a number of defined entry points that both language ROMs and user programs were expected to use to interface with the hardware.

Programs which relied exclusively on these interfaces could expect to run correctly on future versions of the BBC Micro and on the 6502-based incarnations of the Second Processor expansions. Much of this functionality was exposed in a programmer-friendly manner by the included version of BASIC.

For example, to draw text or graphics on the screen, you were expected to send ASCII characters, control codes and escape sequences to the VDU driver through the OSWRCH entry point at &FFEE - which was always present, even if the display memory had been remapped into the shadow bank (on the Master) or simply didn't exist in your memory space (on the Second Processor). Most graphics operations could be specified through a six-byte escape sequence corresponding to the BASIC PLOT statement. To check the colour of a pixel, or to perform a variety of auxiliary operations such as hiding the text cursor, the more general OSBYTE entry point could be used.

Some games found this interface too restrictive for adequate performance, so they had to access display memory directly. These games were consequently incompatible with the Second Processor and Shadow RAM, but could still be run on a machine so equipped, by temporarily disabling those features.

Other entry points dealt with handling a very basic command shell, filesystem operations (abstracted so that you didn't need to care about tape/floppy/HDD/network differences), and so on.

This approach to constructing an operating system was considered so successful that it was copied very closely in the subsequent Acorn Archimedes series, which introduced the now-ubiquitous ARM CPU to the world.

The story goes that a more professional microkernel-based OS (ARX) was being developed for the Archimedes, but that it was so slow and memory-hungry that it would have ruined the machine for its intended market. A large part of that was because it was written in Modula-2 via an incredibly inefficient compiler; to multiply two integers it would emit 25 ARM instructions and then call a subroutine. (The ARM2 could already do that with a single instruction.)

A demo was arranged, where the ARX devs proudly showed off sixteen clocks running on their desktop - under which load their top-of-the-line 4MB machine was swapping heavily, and each clock only updated every several seconds. The other team came in with a 256KB machine running the MOS-derived OS (Arthur), and they had sixteen clocks written in BBC BASIC, all running smoothly. ARX was cancelled the next day, and Arthur eventually became RiscOS.

Yes, that means you can still call OSWRCH and OSBYTE natively on a Raspberry Pi!

Answer 3

Even an OS kernel on a some very modern system (certainly compared to what is relevant here) uses "special memory values" and machine dependent hacks to provide an ABI.

https://stackoverflow.com/questions/2535989/what-are-the-calling-conventions-for-unix-linux-system-calls-on-x86-64

"Independence" of a kernel could likely be best measured by whether the kernel can force user programs not to interfere with it or not. This became possible as soon as memory management units or comparable hardware became available commercially - and likely operating systems quickly followed since these features - that were expensive to build in pre-single-chip-CPU systems - would be useless without an OS taking advantage of them. Architectures like IBM 370, DEC VAX and part of PDP-11 were tailored to such usage, and ran UNIX, VMS and even hypervisors in case of the 370 from the 1970s on. Home/Office grade computers only partially had that kind of feature set - the first widely used microprocessor CPUs that were capable without extra hardware were the 80286 (limited, the 80386 had far better features in that area) and Motorola 68030.

....

Added detail on why I said "limited" about the 80286: IIRC it was bugged and once you switched into protected/virtual memory mode (an x86 cpu always boots with these features switched off!), any attempt to return it to "real" mode (which you needed to do I/O) utterly crashed it unless you added extra hardware to guard against it (the A20 gate logic in the PC architecture).