Skip to content

Stage 28

NEXSM Architecture Specification

  • Two cores
  • Contains an additional Core Flag
  • Primary core and Secondary core
  • Active Mode and Reset Mode
  • In Reset Mode, secondary core is non functional
  • The core flag allows a program to test whether it is currently executing in the primary or the secondary.

**Dual-Core Bootstrap

  1. When powered on, the machine starts in reset mode. The primary core starts execution and the secondary core is non-functional. Here, the functioning is similar to XSM.
  2. The secondary core starts execution when the primary core executes a START instruction.
  3. Upon execution of the START instruction, the machine enters the active mode. The START instruction sets the IP value of the secondary core to physical address 65536 (page 128) and secondary is powered on.
  4. Normally, when the machine is powered on, the primary executes a bootstrap code which loads the initialization code for the secondary into memory page 128 before executing START.
  5. When the machine is running in active mode, if a RESET instruction is executed by either the primary or the secondary, then the machine goes back to reset mode and the secondary stops execution.

The START instruction is ignored if executed in active mode, similarly the RESET instruction is ignored when executed in reset mode.

Memory Organization

NEXSM machine has 144 memory pages (as against 128 pages of XSM). The memory organization of pages 0 to 127 are exactly as in XSM. The organization of the remaining 16 pages are as:

  1. Page 128 and 129 are reserved for loading the bootstrap code for the second core.
  2. Pages 130 and 131 are reserved for an additional software interrupt INT 19.
  3. Pages 132 to 143 are available as free memory.

Disk Organisation

NEXSM has 16 additional free blocks of disk space, with block numbers 512 to 527.

The Secondary Bootstrap Loader is in 512-513 Additional Privileged Instructions

1) TSL Rj, [loc] - The contents of loc is copied to Rj and the value is set to (atomic process)

Interrupts and Exceptions

1) Disk and the terminal interrupts apply to the primary core only. 2) Software interrupts, timer and exceptions applies to both the cores.

Concurrency

  • A process is not scheduled simultaneously on both cores
  • Only one core will be executing critical kernel code at a time (update to data structures)
  • Only one core will run scheduler code that involves updates to kernel data structures at a given time.
  • The login and shell process will run only on primary core (This for simplicity of kernel implementation)
  • When either logout or paging is running on primary, IDLE2 will be scheduled on secondary

Hold and Wait constraints - A process, after acquiring an access lock will quickly perform the action and release the lock. Moreover a second access lock will be acquired only after releasing the first. This prevents deadlock

Policy Primary Core (Core 1) Secondary Core (Core 2) Technical Reason (The "Why")
Disk Interrupts Handles exclusively. Physically ignored. Hardware Wiring: XSM routes Disk interrupt lines only to Core 1. Avoids two cores fighting over Disk Status registers.
Terminal Interrupts Handles exclusively. Physically ignored. Input Affinity: Terminal interrupts are wired to Core 1. Pinning them avoids slow Inter-Processor Interrupts (IPI) to wake up waiting processes.
Login / Shell Scheduled here only. Never scheduled. Resource Proximity: These are I/O-bound. Keeping them on the core that receives terminal interrupts prevents massive synchronization overhead.
Paging / Logout Executes the module. Forced to IDLE2. System Integrity: Prevents Core 2 from accessing memory or process table entries while Core 1 is actively deleting or swapping them.
Timer / Software Int Handled independently. Handled independently. Local Control: Each core must handle its own exceptions (e.g., Page Faults) and perform its own context switching (Timer).
Critical Kernel Code Requires KERN_LOCK. Requires KERN_LOCK. Mutual Exclusion: eXpOS drivers are "Non-Reentrant." The "Giant Lock" prevents race conditions in shared tables (Memory Free List, etc.).
Scheduler Code Requires SCHED_LOCK. Requires SCHED_LOCK. Consistency: Prevents both cores from picking the same "READY" process or updating the SYSTEM_STATUS_TABLE at the same time.
### Modifications to Scheduler Module
  1. SCHED_LOCK must be acquired
  2. If the core is primary, it should run not run IDLE2 and the process running on secondary core. If LOGOUT_STATUS is 1 and the secondary core is not running IDLE2, then schedule IDLE.

If the core is secondary, 1. If PAGING_STATUS or LOGOUT_STATUS is set (in the system status table ), then IDLE2 must be scheduled). 2. IDLE (PID=0), LOGIN (PID=1), SHELL (PID=2) and SWAPPER_DAEMON (PID=15) should never be scheduled, as the eXpOS design stipulates that these processes will run only on the primary. 3. Process which is currently running on the primary core must not be scheduled (read CURRENT_PID field of the system status table ). 4. The PID of the process that is selected for scheduling in the secondary core must be set to CURRENT_PID2 field of the system status table.

Modifications to Timer Interrupt Handler

  1. Do not invoke pager module from the secondary core.
  2. When running on the primary core, call AcquireKernLock() and ReleaseLock(KERN_LOCK) of the access control module before and after calling pager module.

Modifications to Process Manager and Pager Modules

  1. Kill All function in process manager module must not call Exit Process function for IDLE2 (PID=14) as this process is never killed.
  2. Pager module must not swap out IDLE2 (PID=14).

Modifications to Logout System Call

  1. In Logout System call , first set LOGOUT_STATUS=1 in the system status table , but then call the scheduler (wait until secondary core schedules IDLE2 before proceeding).
  2. After execution of Kill All function, set LOGOUT_STATUS=0. In the system status table .

Modifications to Shutdown System Call

Before calling KILL ALL function in the process manager, reset the secondary core and release the SCHED_LOCK.