XOSIG IoI
From XCore Exchange
Contents |
XOSIG Index of Ideas
Copyright © XMOSlinkers jhrose, 2009-2010. Version 0.3.1. These notes are distributed with the FSF Free Documentation License version 1.3 as a community work.
Introduction
XOSIG provides a forum covering all theoretical and practical aspects of operating systems relating to XMOS technology.
Aims
These notes aim to outline substantive ideas within XOSIG, providing a first port-of-call to locate projects and those involved with them. Each may be expanded upon in related projects and their references.
Summary
XMOS processors such as the XS-1 core [4.1] equip system designers with process-oriented hardware and software building blocks, not unlike the INMOS Transputer cores which predated them. An XMOS XS-1 is a multi-core processor, each core with its own memory and i/o links [4.1]. The cores embed support for a number of services commonly provided by an operating system on general purpose processors, including multi-threading, communication, general purpose i/o, and timers. And like INMOS with Occam, XMOS provide a parallel programming language in XC [4.2] which can be considered the Operating System Language of XS-1 processors.
Using XC, an operating system is not a necessity in an system of homogenous XS-1 processors. However, there are a number of Operating System technologies that could be applied to extend the services provided by XS-1 and XC, and those that could be applied to network with heterogenous systems.
Table of Content
Each idea is listed in the table below and linked to a later section of these notes.
| Project | Summary | Status |
| 2 XOSS | XS-1 Operating System Services to extend services provided by XS-1 and XC and to network with heterogenous systems. | Just an idea |
| 3 HyperviXor | XS-1 as a Hypervisor servicing a number of Concurrent Operating Systems. | Abandoned |
| 4 PiXC | To use the pi-calculus as a model to extend XC with mobile processes and mobile channels. | Just an idea |
| 5 PiXOS | To use the pi-calculus as a model and PiXC to implement a Dynamic Operating System for XMOS processors. | Just an idea |
| 6 FreeRTOS | A port of FreeRTOS to the XS-1. | Project |
| 7 Next idea... | Next idea... | ... |
XOSS
Proposal for XS-1 Operating System Services to extend those services provided by XS-1 and XC, and in particular a form of paged memory management. To provide hardware that enables networking with mainstream host processors running Operating Systems like VxWorks or Linux.
Aims
The aim of XOSS is twofold:
- to expand the operating system services provided by XS-1 cores and the XC language,
- to integrate with multi-processor Operating Systems and extend application parallelism.
Contacts
| Identity | Contact |
|---|---|
| jhrose | Via XMOS Exchange |
Summary
The XS-1 processor does not provide an External Memory Interface (EMIF), which could introduce non-determinism between threads. And we are taught to program for limited xcore memory using data shared through channels, rather than writing large monolithic algorithms. Still, there are occasions when access to secondary memory would prove beneficial.
There are common operating system services which the XS-1 core does not embed, such as memory caching which would allow use of both a secondary cache and an external main memory, and services which XC does not support, such as a service registry which would allow a set of distributed services to be run across heterogenous processor networks. And the scope for parallel applications can be extended to run not just on multi-cores but also over multi-processors.
Project
To provide hardware for secondary memory, to extend PAR in XC to mark caching points, and to provide methods for communication with a host processor including virtual channels. The project is more fully described in [2.3].
Secondary memory
The XS-1 provides no memory objects beneath the L1 Cache, and the processor has no ability to address external memory. To provide the next level multi-cycle Level-2 Cache and lowest Main Memory necessitates both a system design and either toolchain support for XC.
Hardware
A proposed Level-2 Cache and Main Memory system design is proposed, using an FPGA to provide a cache and to interface an external 400MHz DDR SDRAM. And with some development the same hardware is proposed as an interface to a Host Processor Node, through Dual-Port Memory and an Xlink connection. Caching requires an extension to XC (or a custom library), and has a real-time performance overhead.
Extended PAR
Cache-misses would stall the processor for a large number of cycles, so facilitating them at known scheduling points is desirable. The XC programming language includes just such a known scheduling point in the PAR statement, where the programmer spawns threads. Consider the following proposed extended PAR, in which the set of threads is named and declared with proposed new keywords:
PAR set_of_abc IS PAGED
{
a( );
b( );
c( );
}
in which set_of_abc is a name like a variable name, and IS PAGED is an attribute. This works similarly for replicated PAR, for example:
PAR( int i=0; i<4; i++ ) array_of_a IS PAGED
{
a[ i ]( );
}
Virtual Channels
As each XS-1 core has a finite set of channel resources, XOSS could provide a library of Virtual Channels (VCH). A large number of VCHs could be multiplexed over a few physical channels. And exposing XOSS VCHs over the Host Processor Node Xlink interface as a Linux device would allow a direct exchange of data between XOSS/XS-1 and Linux threads.
References
[2.1] XMOS XS1 Architecture, May D., 2008
[2.2] Programming XC on XMOS devices, Watt D., 2009
[2.3] XOSS Proposal, jhrose, 2009.
HyperviXor
XS-1 hardware as a Hypervisor servicing a number of Concurrent Operating Systems.
Aims
- To use XS-1 threads and resources to virtualise Concurrently running Operating Systems
Contacts
| Identity | Contact |
|---|---|
| jhrose | Via XMOS Exchange |
Summary
A Hypervisor provides a low-level service to Operating Systems, much as operating systems themselves virtualise resources to software applications. In systems with multiply different real-time and concurrent requirements, benefit can be had in dividing the application among different Operating Systems with differing characteristics and services.
Project
Abandoned because it will be cheaper just to use another processor for each sub-system OS.
References
PiXC
To use the pi-calculus as a model to extend the XC programming language with mobile processes and mobile channels.
Aims
The aims of PiXC are:
- To use the pi-calculus [4.5] as a model to extend XC [4.2] with mobility
- To formalise (extensions to) a compiler for PiXC that targets XMOS processors [4.1]
Contacts
| Identity | Contact |
|---|---|
| jhrose | Via XMOS Exchange |
Summary
As Milner begins the introduction [4.5], "[pi is]...a calculus for analysing properties of concurrent communicating proceses, which may grow and shrink and move about". This fluidity takes the pi-Calculus to a level not reached by CCS, CSP or classical automata. In the broadest nutshell, pi is an extension to CCS that allows the very channels used for inter-process communication to be passed as communication elements.
PiXC makes programming with the Pi-calculus accessible and familiar, by modestly extending the XC programming language. These extensions allow mobile processes and channels to be declared and have a language semantics. Extensions to input and output statements allow mobile processes to be communicated along channels, so the mobile context leaves the sender process and arrives at the receiving process where it runs in parallel. The sender and receiver process can reside on different processors. The state (or context) of a mobile process is preserved over its migration, so that its lifetime persists for the duration of the whole program.
Project
To extend XC with mobile processes and mobile channels. The project is more fully described in [4.6].
Fluid architecture
In addition to modelling internets [4.5], we assert Pi is also well-suited for general purpose programming and expressing algorithms. The dynamic communication of mobile channels and mobile processes through channels enables the function and data control flow to evolve in response to run-time events [4.4].
Mobile Processes
Mobile processes are those which migrate, to run at different locations at different times. To be mobile, rather than just invoked in the accepted way, a process has to preserve some state and provide various function entry points, which suggests a mobile-context structure operating entirely within the process. And to be safe, a process has to be sent through a channel to a new location.
Mobile Channels
Mobile channels are those which migrate, to bind with different endpoints at different times. To be mobile, rather than just used in the accepted way, a channel has first to be emptied so that it is state-less before migrating. And to be safe, a channel has to be sent from a source process through a channel, possibly itself, to a destination process. Once sent, the source process can no longer access the migrated channel; and counterwise the destination process can only access the migrated channel once received.
References
[4.1] XMOS XS1 Architecture, May D., 2008
[4.2] Programming XC on XMOS devices, Watt D., 2009
[4.3] Occam-pi, RmoX, Occam-pi and RMoX, University of Kent
[4.4] Communicating Mobile Processes, Communicating Mobile Channels, University of Kent
[4.5] pi-Calculus, Milner R., Cambridge, 1999.
[4.6] PiXC proposal, jhrose, 2009-10.
PiXOS
To use the Pi-calculus to model and PiXC to develop a Dynamic Operating System for XMOS processors.
Aims
The aims of PiXOS are:
- To use the pi-calculus [4.5] as a paradigm for a Dynamic Operating System
- To use PiXC [4.6] to develop an Operating System for XMOS processors [4.1]
Contacts
| Identity | Contact |
|---|---|
| jhrose | Via XMOS Exchange |
Summary
In traditional operating systems, especially those targetting embedded systems, the executable unit is commonly statically linked so that the set of possible services is fixed during compilation, and resources like memory and CPU are shared among processes through virtualisation. In systems with an interface, libraries may be dynamically link-loaded at runtime to extend the set of kernel modules or device drivers. However, the concept of operation, the way people view and program for operating systems, largely remains fixed on a rigid architecture which is not at all fluid.
As Milner begins the introduction [4.5], "[pi is]...a calculus for analysing properties of concurrent communicating proceses, which may grow and shrink and move about". In the broadest nutshell, pi is an extension to CCS that allows the very channels used for inter-process communication to be passed as communication elements. In communicating a channel, the effect is a dynamic re-mapping of the architecture.
Project
To develop PiXC-language libraries that implement a Dynamic Operating System Architecture. The project is more fully described in [5.3].
Fluid architecture
In addition to modelling internets [4.5], we assert Pi is also well-suited for modelling a dynamic operating system, whose very architecture changes dynamically to fulfil the state transitions of its processes. The communication of mobile channels and mobile processes through channels enables network topology to evolve in response to run-time events [4.4].
Mobile Services
A dynamic operating system can publicise a set of mobile processes, which migrate to run at different locations at different times. Each mobile process can implement an Operating System Service (including Interrupt Service Routines). When not in use a Mobile Service (MS) resides dormant in a registry; and when needed an MS is claimed by a process, to which it migrates and runs in parallel.
Device Drivers
A dynamic operating system can publicise a set of static device drivers through mobile channels, whose endpoints migrate to bind with different processes at different times. A static driver controls a fixed-location hardware capability, such as an i/o port. When not in use a Mobile Endpoint (ME) resides dormant in a registry; and when needed an ME is claimed by a process, to which it migrates.
References
[5.1] XMOS XS1 Architecture, May D., 2008
[5.2] pi-Calculus, Milner R., Cambridge, 1999.
[5.3] PiXOS proposal, jhrose, 2010.
FreeRTOS
A port of FreeRTOS to the XS-1.
Aims
FreeRTOS aims to provide:
- a portable, Open Source, royalty free, mini Real Time Kernel
- tasks, co-routines, and inter-task communication
Contacts
| Identity | Contact |
|---|---|
| bianco | Via XMOS Exchange |
Summary
- preemptive, cooperative and hybrid scheduling
- support for over 23 distinct architectures
- designed to be small; typically a kernel binary image will be in the region of 4K to 9K bytes
- portable code structure predominantly written in C
- supports both tasks and co-routines
- stack overflow detection options
- no software restriction on the number of tasks that can be created
- no software restriction on the number of priorities that can be used
- no restrictions imposed on priority assignment - more than one task can be assigned the same priority
- queues, binary semaphores, counting semaphores, recursive semaphores and mutexes for communication and synchronisation between tasks, or between tasks and interrupts
- mutexes with priority inheritance
- Free embedded software source code
- royalty free
Project
To port FreeRTOS to the XS-1 architecture.
Source
The FreeRTOS kernel source is spread over 4 source files and 10 header files written in standard C, which are compiled using the XCC toolchain. Then there is a portable subdirectory, within which architecture-specific source files in C and assembler reside. A new portable sub-directory for XCC is created, and a target sub-directory for XMOS_XS1 containing C and XC source files.
XS-1 port
The port_xc.c source declares a timer resource, used to provide the FreeRTOS kernel timer. The kernel is run each time the timer expires, to perform a context switch. The portmacro.h file defines basic types, constants and macros, including atomic functions to enable and disable interrupts. A macro is provided to make a kernel call entry point, though the only kernel function implemented so far is a context switch. The port.c file supports scheduler functions. The port_asm.S file implements task context save and restore functions, the tick ISR, and functions to initialise each task stack and the kernel on startup. Memory allocation is provided using the XCC built-in heap library.
References
[6.1] http://www.freertos.org/
[6.2] http://www.xcore.com/projects/freertos-port
Next idea...
Aims
Contacts
| Identity | Contact |
|---|---|
