# 01 - Noah

## Aufgabe 1
1.
Der Kernmodus hat erhöhte Privilegien. Code der im KM ausführt darf direkt auf die alle Hardwareresourcen zugreifen. Nur der "Kernel" des Betriebssystems darf code im KM ausführen. Der meiste Code führt dementsprechend im Benutzermodus aus.

Im BM besteht das Privileg direkt auf die Computer Hardware zuzugreifen nicht.

Wenn im BM ausführender Code auf die Hardware resourcen zugreifen will beauftragt er dafür das Betriebssystem indem er API Funktionen des Betriebssystems aufruft. Diese API Funktionen werden dann im KM ausgeführt und stellen für den Code des BM ein vereinfachtes und eingeschränktes Interface zum Hardwarezugriff da.

2.

a) Sollte nur im KM modus gehen.
(One of many) Reason(s):
Human Interface Device input works through interrupts. If any code running on the Comnputer could block all interrupts, the following might happen:
Program A blocks all interrupts and then enters an infinite Loop.
This would render the Computer unusable, as HID input would seize to work at all.

b) Should be possible in User Mode
Reason:
The system time is not sensitive information. Reading data can not by itself, interfere with the execution of any other code on the system.

c) Should be restricted to Kernel Mode
Reason:
A change in system time can mess with the execution of other programs. (Things liek timers might depend on it) Also the user likely expects the system time to either keep itself correct and up to date automatically or they expect it to follow a specific setting that they chose. All of this can be achieved through the operating system. There is no need for User Mode Applications to be able to set system time.

d) Should be restricted to Kernel Mode
(Some of many) reason(s):
By modifying allocation tables, a program could easily comprimise the stability of other processes or event the operating system itself. Malicious programs could even use this power to read sensitive information.

3.
1. Memory can be compressed
2. Memory can be moved to secondary storage, when needed

4.
1. Problem: The Program writes again, while the first write is still being processed
- Possible solution: The driver could put all write requests into a queue
2. Problem: The Program tries to read, while the previous write is still being processed, expecting the previous write have taken effect already.
- Possible solutions:
1. Read operations are blocked until all queued write operations are processd
2. The device driver caches write operations which are currently being processed and returns those cached values instead of the data on the physical device to read operations.

## Problem 2

1. MISSING Wo steht das?

2.

Multiprogramming:
- Several programs are held in memory, when one of the programs pauses because it requires IO, then another program is executed. The goal is minimizing downtime due to IO.
Timesharing:
- The CPU alternates between different programs in intervals. The goal is to share processing time across programs evenly.

## Problem 3

1.

| Name | Symbol | b=2 | b=1024 |
|-------|--------|-----|--------|
| yobi | Yi | 80 | 8 |
| zebi | Zi | 70 | 7 |
| exbi | Ei | 60 | 6 |
| pebi | Pi | 50 | 5 |
| tebi | Ti | 40 | 4 |
| gibi | Gi | 30 | 3 |
| mebi | Mi | 20 | 2 |
| kibi | Ki | 10 | 1 |

2.

Informationseinheiten werden oft mit binären Präfixen spezifiziert.
The smallest information unit is the bit and it can't be further divided, so we don't ever need to describe fractions of bits only multiples.

3.

1 TB = 1 * 10 ^ 12 bytes
1 TiB = 1 * 2 ^ 40 bytes

1 TB / 1 TiB = 0.9094947018
-> 1 TB = 0.909 TiB

## Problem 4

1.

a)

1. fetch: 1ns
2. decode: 1ns
3. execute: 1ns

-> 3ns per instruction

3ns/1i
-> 1i/3ns
1i/3ns = 1i/(3 * 10^-9 s) = 1/3 * 10^9 i/s

-> 1/3 giga instructions per second

b)

-> 5ns per instruction

5ns/1i
-> 1i/5ns
1i/5ns = 1i/(5 * 10^-9 s) = 1/5 * 10^9 i/s

-> 1/5 of a giga instruction per second

2.

a)

This question is not quite clear to me, so I've made some assumptions:

We assume that for any data read operation, the system first looks in the cache and it finds what it's looking 95% of the time. In the 5% of cases that it doesn't, it will then look at RAM and find what it is looking for in 99% of those cases. If cache and RAM are of no help, the system will then look at external storage and find what it is looking for 100% of the time.

This leads us to the following calculations:

Average access time
= 0.95 * 2ns + 0.05 * 0.99 * 10ns + 0.05 * 0.01 * 10ms
= 0.95 * 2 * 10^-9s + 0.05 * 0.99 * 10 * 10^-9s + 0.05 * 0.01 * 10 * 10^-3s
= 0.000005002395 seconds
= 0.005002395 milliseconds
= 5.002395 microseconds
= 5002.395 nanoseconds

b)

Average access time is not clearly dominated by any of the three access times. The average time is around 3 orders of magnitude away from 1ns as well as 1ms.
We can, however, say that external storage access time is the most dominant out of the three, because it is the only value at the magnitude of 1ms while there are 2 values at around the magnitude of 1ns.

c)

2002.395 ns = 0.95 * 2ns + 0.05 * 0.99 * 10ns + 0.05 * 0.01 * x ms

-> x is around 4

## Problem 5

2.

-std-c11:
Use the 2011 c standard

-g:
Activate debugging support
(Produce debug information in the .o file)

-Wall
Enable all compiler warnings

-Wpedantic
Generate warnings when code doesn't adhere to the c standard (but is still compilable)

3. Extra files:

.bc, .i, .o, and .s

.bc:
LLVM bitcode. It's an encoded version of LLVM Intermediate Representation.

.i
Output of the preprocessor. Still c code.

.s
Assembly source code.

.o
Object file. Result of assembly. Contains machine instructions. Only contains bits -> not human readable. Linking will turn this into an executable.

## Problem 6

1. -lm flag
Leads to math.h being linked properly

2. Alternative implementation
Instead of precalculating function values and storing them in a matrix, we could have calculated them on the fly.
Instead of generating and printing the function "image" line by line, we could have generated a string for the whole image and then printed it all at once.
Or alternatively we could have printed each character separately. This would've made our code a bit simpler, but also a slightly slower.