Aufgabe 1: Ein-/Ausgabe
Introduction & General Remarks
Although you will implement a fully functional operating system over the course of this semester, you won't have to start completely from scratch – you are provided a very basic skeleton including the boot up code required for the x64 architecture and some helper classes (e.g. for the Advanced Configuration and Power Interface).
- The Intel Architecture has constantly evolved over the past 40 years and, therefore, has quite an amount of inherited burdens: It is a cumbersome task to heave the CPU from Real Mode (16-bit, used in the 1980s) to the modern Long Mode (64-bit), which is the base for our journey. From a higher level perspective this surely is an interesting ride through the history (and we will explain it in a voluntary seminar), but its (low level) implementation is just dull copying of the Intel Software Developer's Manual (ISDM), e.g. 8.4 Multiple-processor (MO) Initialization – and therefore you are spared this task.
This will allow you to concentrate on the more interesting and challenging parts of operating system development. (Nevertheless, we strongly encourage you to take a look into those parts and the Intel manual!)
There are basically two different variants of StuBS (Studentenbetriebssystem):
- OOStuBS (Objektorientiertes Studentenbetriebssystem) as single-core variant
- MPStuBS (Mehrprozessor Studentenbetriebssystem) as multi-core variant
Each version has separate handouts, however, they only differ in a few places. If you are still unsure which variant you want to implement, we recommend starting with MPStuBS as it is relatively easy to downgrade from MPStuBS to OOStuBS at a later point in time.
You can find the description of the development environment here.
This website houses both assignments and documentation, in fact, they are quite closely linked: In the class documentation, methods to be implemented or extended are visually marked with a OOStuBS and MPStuBS are very similar, the documentation on the website is valid for both variants (if a variant requires special handling, it is explicitly mentioned).and contain further details in their descriptions. Since
The described class interfaces (and the file structures) are usually required for subsequent assignments, so please try to stick to the specification. However, it is totally fine to add helper attributes/methods/functions (or even classes).
We provide an example solution for each assignment (and variant), usually with a customized example application demonstrating the functionality of the assignments objectives. It can either be executed on the test hardware (in the corresponding Netboot menu) or launched in the emulator: The
Makefile provides a target
solution, which needs to be suffixed with the desired assignment number. For example, to see the solution for assignment 1, execute the following in your project's root on a CIP pool system:
In case you don't feel challenged enough by the regular assignments: We will frequently supply you with ideas for voluntary enhancements. These are easily recognizable by.
- We will not evaluate the voluntary exercises, so please ensure that the actual assignment works prior to starting with those parts. Also, we will obviously try to help you on serious problems with those additional exercises, however, the level of difficulty is intentionally higher and we expect good skills in independent task solving!
Similar to Google C++ Style Guide but with following exceptions:
- No license boilerplate
- Tabs instead of Spaces
lint target (employing cpplint) to check the compliance of your code:
- Variables: lowercase with underscore char* variable_name;
- Constants (and enum values): uppercase with underscore const int CONST_VALUE = 42;
- Type Names (class/struct/namespace/enum): Capital letter, camel case class SomeClassName;
- Methods/Functions (C++): start with lowercase letter, then camel case void someFunctionName();
- extern "C" Functions: lowercase with underscore (like variables).
- File Names: lowercase, main type name, underscores only if is a sub type
I/O Support for StuBS
Implement output (on the CGA Text Mode) and input (via Keyboard). Optionally, you can support the serial interface as well. The Class Overview will help you understand the structure of StuBS.
- Getting to know the development environment
- Refreshing the knowledge of the programming language C++
- Hardware programming (CGA text mode and keyboard)
Videos (WS21, in German)
- Bildschirm (CGA Textmode) (8 min)
- Tastatur (5 min)
- Serielle Schnittstelle (5 min)
- Entwicklungsumgebung (14 min)
- Aufgabe 1 (5 min)
Output on CGA Text Mode
When it comes to basic debugging in StuBS, output functions are quite essential. For simplicity, TextStream provides the same basic interface as the C++ I/O streams library. It is implemented with the help of the classes OutputStream (which itself is based on Stringbuffer) and TextWindow (based on TextMode, which makes use of the already implemented IOPort).
In case you have successfully solved the (voluntary) assignment 0, you should be able to use your solution of the OutputStream without any modifications.
TextMode is the central abstraction for the text mode, managing the output of characters on the screen and controlling the text cursor position. The derived class TextWindow can be configured via the constructor in such a way that it displays the output on an adjustable rectangular section of the screen. This allows you to divide the screen and have separate TextWindow instances responsible for the output in those individual subareas (so called windows). Furthermore, you can configure whether each corresponding window should use the hardware cursor or not.
To make sure that the output functions can be used everywhere in the operating system, several global TextStream objects should be created:
- The main window
koutfor application output using the hardware cursor.
- For debugging output, OOStuBS has a single debug window object called
dout, whereas MPStuBS uses an array of objects for each CPU core (also called
doutwith Core::MAX elements), providing a separate debug window for each core.
debug/output.h defines the macro DBG, which employs
dout and should be used for debug output: In MPStuBS this macro will select the
dout object for the corresponding core it is executed on (using Core::getID()).
All instances of the class TextStream should output their output in disjunctive areas of the screen to avoid overlapping output. Instead of statically defining those areas, you can implement an automatic arrangement of the windows as a voluntary extension.
Demonstrate the functionality of the output with the following code:
You can divide this task into three independent parts that can be solved and tested very well individually. We therefore recommend to implement the necessary classes in the following order:
- Stringbuffer and OutputStream (and a small test application)
- TextMode and TextWindow (and a small test application)
- TextStream, the debug macros and the test program
- In later tasks, application and test code will be implemented in the Application class instead of main(). It is up to you to already handle it that way in this assignment.
- Overview of files and classes
- List of mandatory and voluntary tasks
- Output in Text Mode
- The I/O subsystem
Input using Keyboard
In addition to text output, input via keyboard should also be supported (whereby the test of input is not possible without output). For this purpose you should complete the PS2Controller by using the KeyDecoder (which evaluates Make & Break codes in order to decode pressed keys).
Your test application should repeatedly query pressed keys from the keyboard and print their ASCII values using
For MPStuBS, the test program should look quite similar to OOStuBS: It is sufficient to run the test application on the first core (aka BSP, boot processor) – the other cores (aka APs, application processors) should only do output using the debug macro to verify their functionality.
- If multiple cores perform concurrent output via
kout, you will end up in an alphabetical jumble. Try to locate the root cause of this issue (you will be able to fix it in subsequent assignments).
Input & Output using Serial Console (Voluntary)
As an additional task (if you got hooked right away), you can extend your StuBS with a serial interface. A SerialStream further enables output in a VT100-compatible terminal. This is useful when debugging your code on real hardware.
- Qemu will redirect the
COM1port to an unused pseudoterminal device and notify you about its path during startup:
char device redirected to /dev/pts/2 (label serial0)You can easily access it using
screen /dev/pts/2or even
cat /dev/pts/2(if you are just interested in the output). The four hardware test machines are connected to the host
/dev/ttyBS1is the interface for the first test system
StuBS1. The utility
/proj/i4stubs/tools/serialsimplifies the configuration of the connection settings (baud rate, parity & stop bits), run it without any arguments for detailed usage instructions.
Handing in your Solution
Try to stick to our specification as much as possible and solve all required parts of the task according to the specification before you try to hand in.
Your tutors expect extensively tested solutions (on our test hardware) which are compliant with the coding style. The functionality implemented by you should be described with concise source code comments.
You can either demonstrate your solution in person during the computational exercise (this is the preferred way) or remotely by submitting your changes as Merge Request to the
master branch. In either case, your tutors will evaluate your code, discuss important key points, and request changes if necessary.
- We'd suggest having a separate git branch for each assignment, while using the GitLab Continuous Integration (CI) feature to verify builds and coding style (which is already provided in the
.gitlab-ci.ymlfile, there is no need to change it).