23
graphics support and no file mapping. WINC is intended to provide EPOC APIs for
higher-level Windows-based programs, including EPOC Connect (which uses it to access
EPOC data through application engines already developed for the emulator), the EPOC
help builder, and other utilities.
EPOC’s runtime system comprises two components, cryptically titled E32 and F32. E32 provides
the kernel executive and server, with a kernel API providing services to device drivers. F32
provides a bootstrap loader, file services, an API for writing new file systems, and a command
shell for use primarily in test ROMs.
When implementing EPOC on a new target device, a major milestone is the implementation of a
ROM, which runs E32, F32 and the text shell. In terms of capability, such a ROM is something
like a clean and powerful DOS command line: the text shell provides simple utility and
debugging commands, and a DOS-like batch language — but there is no legacy 16-bit
architecture, and the multi-tasking infrastructure is much more powerful.
8.2.2.2 Kernel
EPOC has a very lightweight kernel designed to provide high performance, and to require the
minimum amount of code to run in privileged mode.
8.2.2.2.1 Scheduler
The kernel supports pre-emptive multi-tasking using threads, which are the basic unit of
execution. The scheduler runs the eligible thread with the highest priority. Thread priorities are
not aged.
Processes are the basic unit of memory management: a process has its own address space, a
primary thread, and any number of other threads. Context switching and inter-thread
communication between threads in different processes is fast, and between threads in the same
process is very fast.
8.2.2.2.2 Tick interrupt
A tick interrupt, every 15.625ms (64Hz) on ARM implementations, or 100ms (10Hz) on PC-
based implementations, is used to drive timer queues and round-robin scheduling of the highest-
priority threads. Some device drivers also use the tick interrupt, e.g. for keyboard and scanning
and digitizer polling. User-side timer requests operate with a maximum resolution defined by the
tick interrupt.
A microsecond timer is available for kernel-side use.
8.2.2.2.3 Memory management
EPOC supports a conventional two-level memory management unit (MMU). In other OSs, two-
level MMUs use one page directory per process, so that process switching involves changing a
single control register (and some cache flushing).
EPOC uses only a single page directory, with each process represented by as many PDEs (page
directory entries) as are needed to hold the relevant page tables. This saves RAM, and is possible
because there is no requirement for EPOC to support potentially very large virtual addressed
spaces backed by swap files on disk.
Memory is allocated in chunks, which are consecutive in virtual address space. A thread typically
uses a single chunk, with a stack at the bottom and a guard page table entry to detect stack
overflow, and heap at the top. Such chunks may expand upwards, but not downwards. Chunks are
typically private, but may be shared. A chunk requires at least one PDE and, as it expands, may
require more PDEs.
Context switching on EPOC’s ARM3 implementation involves moving all a process’s PDEs from
a “low” location, where the process runs, to a “high” location, where its data is accessible only by
the kernel. EPOC R5 supports fixed processes whose PDEs do not move, so that switching
between these processes, the kernel and one non-fixed user process is much faster. The practical
limit to the number of fixed processes is four (a separate protection domain is used for each, and
there are only four such domains). The fixed processes in EPOC R5 are the file server, serial
comms server, window server, and font and bitmap server.
