GIET_VM documentation

The GIET_VM is a static operating system for shared address space, many-cores architectures. These architectures are generally NUMA (Non Uniform memory Acces), because the memory is logically shared, but physically distributed, and the main goal of the GIET_VM is to address these NUMA issues.

The GIET_VM assumes that the hardware architecture is structured as a 2D mesh of clusters. There is one physical memory bank, and several processor cores per cluster. Each processor is identified by a composite index [x,y,p] where x, y are the cluster coordinates, and p is the local processor index.

The GIET_VM is written for the MIPS32 processor. The virtual addresses are on 32 bits and use the (unsigned int) type. The physical addresses can have up to 40 bits, and use the (unsigned long long) type.

The GIET_VM supports a paged virtual memory, with two types of pages BPP (Big Physical Pages: 2 Mbytes), and SPP (Small Physical Pages: 4 Kbytes). The physical memory allocation is fully static: all page tables (one page table per virtual space) are completely build and initialized in the boot phase. There is no page fault, and no swap on disk in the GIET_VM.

The GIET_VM supports parallel multi-tasks user applications. A GIET_VM user application is similar to a POSIX process: one virtual space per application. A task is similar to a Posix thread: all tasks in a given application share the same virtual space. Any task can be allocated to any processor, but the allocation is fully static : no task migration.

When there is more than one task allocated to a processor, the scheduling is pre-emptive, and uses a periodic TICK interrupt. It implements a round-robin policy between all runnable tasks.There is one private scheduler for each processor.

The GIET_VM supports generic architectures: The hardware parameter values (such as the number of clusters, or the number of cores per cluster) are defined in the hard_config.h file.

The GIET-VM configuration parameters (such as the TICK period, or the max number of open files) are defined in the giet_config.h​ file.

1) Mapping

Both the target hardware architecture and the mapping directives (placement of software tasks on the physical processors / placement of the software objects on the physical memory banks) must be described in a python script. This section describes the Python constructs used to describe the mapping. This python script generates the map.bin C binary file, that is used by the boot-loader to initialise the system.

2) Boot Procedure

This section describes the three phases boot procedure.

3) Common Functions

Here are presented the utility functions that can be used by both the bootloader (in the boot phase), and by the kernel (in the execution phase).

4) Kernel Services

Here are presented the functions implementing the main services provided by the GIET_VM in the execution phase: syscall handler, interrupt handler, exception handler, and context switch handler.

5) System calls

Here are presented all the C functions that can be used by an user application (in the execution phase) to require a service to the operating system. All these functions contain a syscall instruction that force the processor to enter the kernel mode.

6) User level libraries

Here are presented various libraries of C functions that can be used by an user application for synchronization, inter-task communications, or for dynamic memory allocation. All these services are provided at user level, and do not require the processor to enter the kernel mode.

7) Peripherals Drivers

This section defines the software drivers APIs for the peripherals supported by the GIET_VM.

8) File System

This section describes the FAT32 file system supported by the GIET_VM.

9) User Applications

This section describes the user applications that have been developed to analyse the TSAR many-cores architecture an the GIET_VM OS scalability.