RTFM Section G) Analysis and guarantees for -core and -coore programs

In this section we cover:
  • General analysis of RTFM-lang
  • Run-time targets

General analysis of RTFM-lang

RTFM-lang builds on the concepts of tasks and resources, and is designed form the outset of analysis and efficiency. The -core compiler create static task sets, (instances of task definitions of the -core program). This allows us to reason on the generated task sets on from the basis of common scheduling theory.

Time offsets are inherent in the programming languages, hence can be exploited towards tighter scheduling and resource analysis.

Having a static task set and fully specialised code allows for compile time assessment of resource requirements (defining the number of threads/interrupts required by the application). Moreover, given information on the stack memory for each task (C code function) it is possible to derive the maximum stack requirement for both hosted and bare metal execution.

Run-time targets

For execution under managed (hosted) environments we provide thread based run-times:
  • The PTCORE run-time, for systems providing POSIX/Pthreads (with real-time extensions). Under PTCORE, the run-time exploits the provided mechanisms to priority inversion avoidance. However, pthreads are hard/impossible to analyse, as overhead (inferred managing queues etc.) may be susceptible to system wide artefacts. I.e., without detailed knowledge on the pthread library implementation and their relation to the native threads, overhead cannot be reasoned on. And even if so, mechanisms internal to the hosting operating system, may be beyond control. To this end, PTCORE is by no means inferior to any another thread based library or language extension, on the contrary, PTOCORE ensures best effort scheduling, as well as compile time deadlock analysis (by the -core compiler).
  • The WINCORE run-time, for systems supporting the Win32 API. Our current implementation has only been tested on desktop operating system (Win7/Win8/Win8.1). For these platforms, the thread API offers no support for explicitly controlling real-time scheduling (in favour of a clean and straightforward abstraction an best effort scheduling managed by the operating system). Future work might lead us to their embedded counterparts, such as Windows CE, Windows Embedded etc. for which more detailed scheduling control is intended and made available.

However, predictive hard real-time scheduling for targets running POSIX/Win32 based operating systems may be difficult, without detailed control of the underlying hardware (such as interrupt management, cache locking mechanisms, branch predictions, etc).

To this end, bare metal execution may be the only viable choice.
  • The RTFM-Kernel, has been initially developed for ARM Cortex M3/4 series micro controllers, as they hold a dominating market position and feature hardware support for priority ceiling based scheduling though the ARM defined NVIC. RTFM-Kernel exploits the NVIC for static priority Stack Resource Policy (SRP) based scheduling, with 0 cycle/0 Byte RAM overhead for task admittance, and a 10 cycle/4 Byte overhead for critical sections (given that the interrupt vector suffice to implement the task instances). Currently the RTFM-Kernel does not implement the full -core timing semantics (after constructs not supported), but implementation of the full semantics till follow shortly. Unfortunately, the ARM defined SYSTICK timer is unsuited to implement continuous timer (free-running) due to the lack of compare functionality. While the ARM defined debug timer offers this functionality, we are not certain that user's in general agrees to scarifying the debugging option in favour for being used by the RTFM-Kernel implementation (sharing the timer in between RTFM-Kernel and debugging is infeasible to our understanding). Moreover, form the perspective of scheduling, multiple (physical) timers are preferable, in order to avoid priority inversion for the dispatching of the timer queue. Vendors typically provide multiple timers, suitable for scheduling in RTFM-Kernel, and vendor specific RTFM-Kernels will follow shortly.

From a perspective of analysis the RTFM-Kernel provides.
  • deadlock free execution (given by SRP),
  • predictive single stack execution (given by SRP),
  • minimal and fully predictive scheduling overhead,
  • outset for offset based resource and response time analysis.

Word from the author:

Already today RTFM-lang can be efficiently executed onto both hosted and bare metal solutions. We foresee development of vendor specific timer implementations for the RTFM-Kernel. A long term goal is to provide dead-lock free execution also for hosted run-time systems, as well as predictive hard real time scheduling of bare metal multi-cores.

Per Lindgren, founder of RTFM-lang, September 2014

Last edited Sep 2, 2014 at 11:20 PM by RTFMPerLindgren, version 4