website/content/news/20260511-interrupts-timers-system-time.md

+++
title = 'Interrupts, Timers and System Time Infrastructure'
author = 'Aiken Harris'
date = '2026-05-11T21:33:37+01:00'
+++
Since commit 64b5de98c8 from March 27, 2026, the ExectOS kernel has received a substantial update focused on interrupt
handling, hardware timer infrastructure, system time management, RTC support, and early SMP-related functionality.
The work completed during this development cycle establishes the first fully integrated timing subsystem within the
kernel and expands the low-level x86 hardware support. This update lays the essential groundwork for true multi-tasking
and multi-core execution in ExectOS.
<!--more-->

## Interrupt Handling Infrastructure
### Unified Interrupt Handlers
One of the largest architectural changes introduced during this development cycle is the redesign of the interrupt
handling path for both AMD64 and i686. The previous interrupt handling implementation was replaced with a unified
dispatcher-based model. Low-level assembler stubs now save processor context in a standardized format before
transferring control to common architecture-independent dispatching routines. The assembler entry code was heavily
reworked for both supported architectures. The changes include:
 * Unified interrupt stack frame layout
 * Consistent register preservation rules
 * Correct interrupt frame alignment
 * Improved exception and IRQ separation
 * Common interrupt dispatch path
 * Simplified vector handling logic
 * Removal of duplicated boot and trap entry code

The redesign reduces duplicated logic between AMD64 and i686 while also simplifying future SMP and scheduler integration.

### Interrupt Vector Registration
A new interrupt registration subsystem was added to allow runtime installation of handlers for interrupt vectors. The
kernel now maintains a centralized interrupt dispatch table which associates vectors with architecture-independent handler
routines. This replaces static or hardcoded interrupt paths and allows dynamic registration of:
 * Hardware IRQ handlers
 * APIC interrupt vectors
 * Timer interrupts
 * IPI handlers

The new mechanism simplifies hardware abstraction and makes it possible to register different interrupt providers depending
on detected hardware capabilities.

### Interrupt Dispatching
A dedicated dispatch layer was added in the kernel execution subsystem. This layer is responsible for:
 * Interrupt vector validation
 * Context handoff between architecture and kernel layers
 * Dispatching registered handlers
 * Managing interrupt acknowledgment flow
 * Supporting future deferred interrupt processing

This work also prepares the kernel for future scheduler preemption and SMP-aware interrupt routing.

## I/O APIC Support
### I/O APIC Integration
The hardware layer received major updates related to interrupt controller support. The kernel now supports I/O APIC-based
interrupt routing. ACPI MADT parsing was extended to enumerate:
 * Local APIC controllers
 * IO APIC controllers
 * IRQ overrides
 * APIC interrupt routing information
 * Global System Interrupts (GSI)

Unlike the legacy PIC architecture, modern x86 systems frequently expose more than one I/O APIC controller. ExectOS already
supports enumeration and initialization of multiple I/O APIC units and dynamically selects the correct controller depending
on the GSI range associated with a given interrupt source.

The I/O APIC subsystem internally operates on Global System Interrupts rather than legacy ISA IRQ numbers. A GSI represents
a globally unique interrupt line within the system interrupt topology. Instead of routing interrupts through fixed ISA IRQs
(0-15), modern firmware exposes interrupt routing information through ACPI tables which map devices to GSIs. This design allows:
 * More than 16 interrupt lines
 * Flexible interrupt routing
 * Multiple interrupt controllers
 * Interrupt source overrides
 * APIC-based SMP interrupt delivery

The kernel translates legacy IRQs into GSIs using ACPI MADT override entries before configuring I/O APIC redirection tables.
The I/O APIC initialization code dynamically configures redirection entries and routes hardware interrupts through APIC
infrastructure.

### Interrupt Routing Improvements
Several interrupt routing issues were fixed during the I/O APIC implementation work:
 * Correct handling of IRQ source overrides
 * Proper GSI translation
 * Correct I/O APIC controller selection
 * Proper vector remapping
 * APIC interrupt masking fixes
 * Interrupt acknowledgment corrections
 * Improved initialization ordering
 * Consistent handling across AMD64 and i686 architectures

These changes were required to ensure reliable interrupt delivery.

## Clock and Timer Infrastructure
### Clock vs Timer
ExectOS now distinguishes between two independent concepts:
* Clock device
* Timer device

A clock device generates periodic interrupts at a fixed frequency. These interrupts are used to maintain kernel timekeeping,
scheduler ticks, and periodic accounting. A timer device is responsible for precise time measurement. Unlike a clock source,
a timer does not necessarily generate periodic interrupts. Instead, it provides accurate time interval measurements used for:
* High resolution timekeeping
* Performance counters
* Timeout calculations
* Precise delay measurements
* Thread accounting

This distinction allows ExectOS to combine different hardware sources depending on hardware capabilities. For example: ARAT
may be used as the periodic clock source and Invariant TSC may be used as the high precision timer source.

### Supported Clock Devices
The kernel currently supports the following clock sources:

|Clock Source                     | Description                                                         |
|---------------------------------|---------------------------------------------------------------------|
|ARAT (Always Running APIC Timer) | Local APIC timer operating independently from CPU frequency changes |
|HPET                             | High Precision Event Timer operating in periodic mode               |
|PIT                              | Legacy Programmable Interval Timer fallback                         |


### ARAT Support
The preferred clock source in ExectOS is the Local APIC timer operating in ARAT mode. Always Running APIC Timer guarantees
that the Local APIC timer continues operating at a constant rate regardless of:
 * CPU frequency scaling
 * Power management transitions
 * Turbo boost state changes
 * Deep sleep states

This makes ARAT reliable for periodic scheduler and system clock interrupts. The kernel intentionally avoids using the
traditional Local APIC timer when ARAT capability is not available. Without ARAT support, the APIC timer frequency may
drift when processor frequency changes occur, causing inaccurate scheduler timing and unstable system time accounting.
If ARAT is unavailable, the kernel automatically falls back to another supported clock device.

### HPET Clock Mode
HPET can also operate as the kernel periodic clock source. HPET is a modern hardware timer subsystem introduced to replace
older legacy timing devices such as the PIT and RTC periodic interrupts. The HPET implementation includes:
 * ACPI HPET table parsing
 * Frequency detection
 * Comparator configuration
 * Periodic interrupt generation
 * Interrupt routing integration

When used as a clock source, HPET periodically generates interrupts at a configured frequency used by the kernel scheduler
and system clock subsystem. HPET provides significantly better precision than the legacy PIT while remaining independent
from CPU frequency scaling.

### PIT Fallback
The PIT implementation remains available as a compatibility fallback for systems lacking HPET or ARAT support. The
Programmable Interval Timer is one of the oldest timing devices present on x86 systems. It operates using a fixed hardware
frequency derived from a 1.193182 MHz oscillator and provides periodic interrupts through legacy IRQ routing. Although
PIT is considerably less precise and introduces higher interrupt latency, it guarantees compatibility with older x86
hardware and virtualized environments. Due to limited precision and relatively high interrupt overhead, PIT is used only
as a last-resort fallback device when modern timing hardware is unavailable.

### Supported Timer Devices
The kernel currently supports the following timer devices:

|Timer Source  | Description                      |
|--------------|----------------------------------|
|Invariant TSC | Constant-rate Time Stamp Counter |
|HPET          | High Precision Event Timer       |
|ACPI PM Timer | ACPI Power Management Timer      |
|PIT           | Legacy PIT fallback              |

### Invariant TSC Support
Invariant TSC is the preferred high precision timer source in ExectOS. Invariant TSC guarantees that the processor
Time Stamp Counter increments at a constant rate regardless of:
 * CPU frequency scaling
 * C-state transitions
 * Turbo frequencies
 * Power management state changes

This allows the kernel to use the TSC as a stable high resolution timer. The kernel intentionally refuses to use
a non-invariant TSC. Traditional TSC implementations may drift or change frequency dynamically depending on processor 
tate. Using a non-invariant TSC would produce unreliable timing results and incorrect system time calculations. If
the processor does not provide Invariant TSC support, the kernel falls back to another supported timer source.

### HPET Timer Mode
HPET may also operate as a high precision timer source. In timer mode, HPET is used as a continuously running hardware
counter rather than a periodic interrupt generator. The counter is driven by a fixed-frequency oscillator and operates
independently from processor frequency scaling, power management transitions, and CPU sleep states. This makes HPET
a stable and monotonic timing source suitable for high resolution elapsed time measurements and timer calibration.
The HPET implementation supports:
 * Main counter access
 * Frequency conversion
 * Nanosecond-scale timing calculations
 * High precision interval measurements

Unlike TSC, HPET access requires memory-mapped I/O operations, resulting in higher read latency compared to the RDTSC
instruction. Despite the additional overhead, HPET remains one of the most reliable fallback timing sources on x86
systems because its frequency remains constant regardless of processor state changes.

### ACPI PM Timer
The ACPI Power Management Timer is implemented as an additional fallback timing source for systems lacking reliable
Invariant TSC or HPET support. The timer operates as a free-running monotonic counter clocked at approximately
3.579545 MHz and is exposed through ACPI firmware interfaces. Unlike traditional TSC implementations, the ACPI PM timer
is completely independent from processor frequency scaling and power management behavior.
The implementation includes
 * ACPI FADT integration
 * Counter rollover handling
 * Frequency normalization
 * Stable elapsed time calculations

Although the ACPI PM timer provides significantly lower precision and higher access latency than HPET or Invariant TSC,
it remains highly reliable due to its fixed-frequency operation. It is also useful during early kernel initialization
and on virtualized systems where TSC behavior may be inconsistent or unstable.

### PIT Timer Mode
PIT timing support remains available as a final compatibility fallback. Although low precision, it allows the kernel to
maintain functional timing support even on minimal hardware configurations.

## Kernel Boot Parameters
### CLOCK Parameter
The kernel now supports the **clock=** boot parameter used to select the preferred periodic clock source responsible
for generating regular system clock interrupts. Supported clock devices currently include: arat, hpet, pit. The selected
clock source is responsible for generating periodic interrupts. The kernel validates hardware capabilities before
activating the requested clock device. For example, clock=arat succeeds only if:
 * Local APIC support is available
 * The processor exposes ARAT capability

If the selected clock device does not satisfy kernel requirements, initialization automatically falls back to the next
supported clock source available on the system. This allows deterministic clock selection while preserving compatibility
across different hardware configurations.

### TIMER Parameter
The **timer=** boot parameter selects the preferred high precision timer source used for elapsed time measurements and
runtime timing calculations. Supported timer devices currently include: tsc, hpet, acpi, pit. The kernel again validates
hardware capabilities before enabling the selected timer source. For example, timer=tsc succeeds only if the processor
provides Invariant TSC support. If the selected timer source does not satisfy kernel timing requirements, the kernel
automatically falls back to another supported timer device.

## RTC and Timekeeping
### RTC Support
RTC support was implemented as part of the new timekeeping subsystem. The Real-Time Clock is used primarily during system
startup to obtain the initial wall-clock time. The implementation includes CMOS RTC access, BCD to binary conversion,
update-in-progress synchronization, date normalization, and integration with kernel system time initialization routines.
The RTC is not used as the primary runtime timing source. Instead, runtime timekeeping is maintained using the active
clock and timer infrastructure. The RTC may later be queried periodically to compensate for timer drift on inaccurate
hardware configurations.

### XT Epoch and Unix Epoch
Unix Epoch represents time as the number of seconds elapsed since January 1, 1970, 00:00:00 UTC. This representation is
commonly used by Unix and BSD operating systems as well as POSIX-compatible interfaces. ExectOS internally uses XT Epoch
as its native kernel time representation. XT Epoch is based on January 1, 1601, 00:00:00 UTC and stores time using
100-nanosecond intervals instead of seconds. The runtime library and kernel now provide complete conversion support
between multiple time representations, including:
 * RTC calendar time fields
 * Unix Epoch
 * XT Epoch

The conversion layer performs normalization and translation between second-based Unix timestamps and the native
100-nanosecond XT Epoch format used internally by the kernel. This functionality allows ExectOS to maintain a high
precision internal time representation while preserving compatibility with Unix and BSD-compatible interfaces and future
POSIX-style APIs.

## System Time and Scheduler Integration
One of the most significant milestones introduced during this development cycle is the first fully integrated system time
infrastructure within the ExectOS kernel. The kernel now processes periodic clock interrupts generated by the selected
clock device and uses them to maintain runtime timing state. Each clock tick advances the internal system clock and
provides the timing foundation required for scheduler operation and runtime accounting.

This work also introduced the initial thread runtime accounting implementation. The kernel can now track execution time
consumed by threads and maintain basic runtime statistics required for future scheduler development. Although the
scheduler itself is still under development, the timing infrastructure required for preemptive multitasking, quantum
accounting and timeout handling is now in place.

## Inter-Processor Interrupts (IPI)
Initial Inter-Processor Interrupt support was implemented as part of the Local APIC infrastructure redesign. The kernel
now contains the low-level mechanisms required to deliver interrupts between processors using the APIC Interrupt Command
Register (ICR). The implementation introduces vector-based IPI dispatching infrastructure together with helper routines
responsible for APIC IPI delivery and interrupt routing. This work is primarily intended as groundwork for future SMP
support and multi-core scheduler integration.

Although ExectOS does not yet fully initialize secondary processors, the current implementation establishes the required
architecture for future processor startup sequencing, cross-core synchronization, deferred work scheduling, and
inter-processor signaling.

The APIC subsystem was also refactored to provide cleaner interrupt routing semantics and more consistent behavior
between AMD64 and i686 implementations. Several issues related to interrupt acknowledgment, APIC vector initialization,
and interrupt masking behavior were corrected during this process.

## Additional Low-Level Improvements
Besides the interrupt and timing infrastructure work, this development cycle also introduced substantial cleanup and
refactoring across multiple kernel subsystems.

The ACPI subsystem received multiple improvements related to MADT, FADT, and HPET table parsing together with expanded
hardware discovery support required for APIC and timer initialization. Processor support code was reorganized and
extended to improve feature detection, APIC capability handling, and timing source validation.

The kernel dispatching infrastructure was also expanded in preparation for future scheduler integration. Several internal
runtime structures were redesigned to better support interrupt-driven execution flow, runtime accounting, and future
deferred execution mechanisms.

## What's Next
The current state of the ExectOS kernel now includes fully functional interrupt dispatching infrastructure, dynamic
interrupt handler registration, IO APIC interrupt routing, periodic system clock operation, runtime system time updates,
RTC-based wall clock initialization, and high precision timer support using multiple hardware timing sources.

The next stage of development will focus primarily on SMP implementation, which is already reflected by the creation of
a dedicated development branch for multi-processor support. The interrupt, APIC, timer, and IPI infrastructure introduced
during this development cycle was designed specifically to provide the low-level foundation required for future multi-core
execution.

Following SMP bring-up, development efforts will shift toward thread management, scheduler infrastructure, and context
switching support. With the core timing and interrupt subsystems now operational, the kernel is approaching the stage
where fully interrupt-driven task scheduling and multi-threaded execution can be implemented on top of the existing
architecture.