AHA: Automated Hardware Abstraction in Operating-System Engineering (DFG: LO 1719/4-1)
Operating systems have always served the purpose to abstract and complement the capabilities of the underlying hardware. Conceptually, the operating system generalizes and expands the instruction set of the machine by partial interpretation and multiplexing of hardware resources. It simplifies the development and portability of applications by hiding the hardware from the application developer.
The price for abstraction and generalization are inefficiencies (with regard to storage requirements, energy requirements, eventuality, predictability, security, etc.) for the concrete application: The power of the generalized concepts is not fully used – but still provided. Hardware resources are virtualized by multiplexing – even in cases a direct mapping would be possible. Even in the OS implementation itself, the hardware is often not used directly, but again accessed via a further, partially interpreting hardware abstraction layer.
Our goal with AHA (Automated Hardware Abstraction in Operating System Design) is to improve nonfunctional properties of system software by a very deep, but fully automated specialization of the application-hardware bridge represented by the operating system. We want to investigate, how more directly mapped implementation variants of the "same" OS functionality – which are semantically equivalent (only) for a particular application – can be generated fully automatically from analyzing this application and its specific interactions with the operating system.
In the context of AHA, "Application" and "operating system functionality" covers the domain of embedded special purpose systems (automotive control unit, IoT device, embedded server node ...); "Hardware" stands for commercial-of-the-shelf platforms (Infineon AURIX, ARM, ...) using their specific characteristics as well as for completely application-specific processor hardware (such as RISC-V). In an extreme case, the specific operating-system functionality required by a particular application is instantiated directly into the command set and pipeline of the processors.
The application developer can – transparently – select among different specialization stages: from "classic" software-based specialization over application-/hardware-specific specialization on standard hardware up to the specialization of the hardware itself to cover the actually needed operating-system extensions.
The basic research question we want to answer with AHA is: What is the highest possible degree of application- and hardware-specific specialization and generalization of system software? Which efficiency gains can be achieved at what cost by problem-specific specialization, on the premise that the process of specialization can be performed completely automatically?
People
Publications
-
FMCAD Conference
Automatic Verification of Application-Tailored OSEK Kernels -
Proceedings of the 17th Conference on Formal Methods in Computer-Aided Design (FMCAD '17)ACM Press2017.
PDF [BibTex]
-
LCTES Conference
OSEK-V: Application-Specific RTOS Instantiation in Hardware -
Proceedings of the 2017 ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES '17)ACM Press2017.
PDF Raw Data 10.1145/3078633.3078637 [BibTex]
