This commit is contained in:
David Schirrmeister
2024-12-05 13:57:04 +01:00
134 changed files with 1052 additions and 151 deletions

View File

@ -103,7 +103,7 @@
- bspw. _mkfifo myPipe ls > myPipe_
### Promises (Futures)
### Promises (Futures) [-]
- Konzept für _asynchrone Programmierung_
- Programm wartet auf Ergebnis/Rückmeldung einer asynchronen Operation
- blockiert dabei NICHT Haupt-Thread

View File

@ -1,4 +1,4 @@
# Energieeffizienz
# Energieeffizienz [-]
## Energieverwaltung
- Frequenzskalierung der CPU
- Spannungs- und Frequenzanpassung

View File

@ -51,7 +51,7 @@
- sehr ineffizient
![image_282.png](image_282.png)
## Dynamische Partitionierung
### Dynamische Partitionierung
- BS weist jedem Prozess eine zusammenhängende Partition zu
- mit exakt benötigter Größe
- dabei auch Fragmentierung

View File

@ -1,4 +1,4 @@
# Dateisysteme
# Dateisysteme [-]
## Warum Dateisysteme
- Neben Verwaltung des Hauptspeichers und Cache
- Verwaltung des Massenspeichers (bspw. SSD, Festplatte)

View File

@ -1,4 +1,4 @@
# Plattenspeicherverwaltung
# Plattenspeicherverwaltung [-]
## Mögliche Strategien
**Speicherung von einer Datei mit n Byte**
- n aufeinanderfolgende Byte auf der Platte reservieren

View File

@ -33,6 +33,9 @@
- Energieeffizienz
- Dateisysteme
- Plattenspeicherverwaltung
- Historie
- Formeln / Mathe-Shit
- POSIX-API Befehle
- Und alles was da oben nicht steht :)

View File

@ -250,7 +250,7 @@
## Composite Pattern
- Baumartige Objektstruktur
### Structure Composite Pattern
![image_405.png](image_405.png)
![image_543.png](image_543.png)
#### Component (Abstract Class)
- Deklariert Interface für Objekte in der Komposition
@ -270,7 +270,7 @@
![image_407.png](image_407.png)
## Strategy Pattern
![image_408.png](image_408.png)
![image_544.png](image_544.png)
## State Pattern
![image_409.png](image_409.png)

View File

@ -2,50 +2,8 @@
## [UML (Unified Modeling Language)](UML.md)
```mermaid
classDiagram
class AdventurePackage {
-title: String
-description: String
}
## [Agile Design](AgileDesign.md)
class Trip {
-startingDate: Date
}
class Accommodation {
-name: String
-address: String
}
## [Design Principles](DesignPrinciples.md)
class Person {
-name: String
-address: String
}
class Participant {
}
class TourGuide {
}
class Booking {
-bookingDate: Date
-isPaid: Boolean
}
Person <|-- Participant
Person <|-- TourGuide
AdventurePackage "1" --o "0..*" Trip : contains >
Trip "0..*" -- "1" Accommodation : has >
Trip "0..*" -- "1" TourGuide : leads >
Trip "0..*" -- "0..*" Participant : booked by >
Participant "1" --o "0..*" Booking : makes >
Booking "0..*" -- "1" Trip : for >
Booking "0..*" -- "1" Participant : by >
TourGuide "1" --o "0..*" AdventurePackage : certified for >
```
## [Design Patterns](DesignPatterns.md)

View File

@ -0,0 +1,7 @@
# ARM-Befehlsübersicht
![QRC0001_UAL-1.jpg](QRC0001_UAL-1.jpg)
![QRC0001_UAL-2.jpg](QRC0001_UAL-2.jpg)
![QRC0001_UAL-3.jpg](QRC0001_UAL-3.jpg)
![QRC0001_UAL-4.jpg](QRC0001_UAL-4.jpg)
![QRC0001_UAL-5.jpg](QRC0001_UAL-5.jpg)
![QRC0001_UAL-6.jpg](QRC0001_UAL-6.jpg)

View File

@ -0,0 +1,227 @@
# Caches
## Cache-Speicher
![image_502.png](image_502.png)
- Deutlich schneller als Zugriff auf Hauptspeicher
- viel kleiner als Hauptspeicher
## Grundprinzipien
![image_503.png](image_503.png)
## Speicher-Zugriff über Cache
- Transparenter Zugriff für die CPU
- Zugriff auf Speicher anhand der Speicheradresse aus der CPU
- Daten werden zurückgeliefert
- dazwischen: Cache
## Aufbau Cache Speicher
![image_504.png](image_504.png)
- Cache Line
- Einheit für Kopie eines Memory-Blocks
- mehrere Worte
- Index
- Adressiert die Cache-Line
- Data
- Daten aus dem Speicher
- V
- Valid Bit
- 1 = Vorhanden
- 0 = nicht Vorhanden (_Anfangswert_)
- Tag
- Blockadresse
- welcher zum Index passende Memory-Block ist abgelegt?
### Offset
#### Zugriff innerhalb des Caches
- Mit Offset innerhalb der Cacheline auf einzelne Wörter/Bytes zugreifen
- Beispiel
- Byte-Offset im Speicher
- 2Bit
- Größe Cache-Line
- 4 Byte
- Wort-Offset für Adressierung der Wörter in Cache-Line
- 2 Bit
- Offset in ADresse gesamt
- 4 Bit
#### Offset Beispiel
![image_506.png](image_506.png)
![image_505.png](image_505.png)
### Index: Cache Adressierung
![image_507.png](image_507.png)
- Speicherort wird durch Index-Teil der Adresse bestimmt
- $Cacheadresse = Speicheradresse \mod ZeilenImCache$
### Tag: Zuordnung der Daten
- Woher ist bekannt welcher Block im Speicher abgelegt ist
- Speichern der Blockadresse (TAG) und der Daten
- ![image_508.png](image_508.png)
### Assoziativität: Cache-Zeilen mit gleichem Index
![image_510.png](image_510.png)
- Durch weiteren Satz von Cache-Lines
- Daten mit gleichem Index aber unterschiedlichen Tags speichern
- ![image_509.png](image_509.png)
#### Grad der Assoziativität
- höhere Assoziativität verringert Fehlerzugriffrate
- 1-Fach: 10,3%
- 2-Fach: 8,6%
- 4-Fach: 8,3%
- 8-Fach: 8,1%
## Cache-Beispiel
![image_511.png](image_511.png)
![image_512.png](image_512.png)
![image_513.png](image_513.png)
![image_514.png](image_514.png)
![image_515.png](image_515.png)
![image_516.png](image_516.png)
![image_517.png](image_517.png)
## Zusammenfassung Adressierung
![image_518.png](image_518.png)
## Cache Organisation (Assoziativität)
- [Direkt abgebildet (direct mapped)](#direkt-abbildender-cache)
- ein Datenwort kann in einem Eintrag abgelegt sein
- ![image_522.png](image_522.png)
- [Voll assoziativ (fully associative)](#voll-assoziativer-cache)
- ein Datenwort kann in einem beliebigen Cache-Eintrag abgelegt sein
- ![image_524.png](image_524.png)
- [Satz assoziativ (set associative)](#n-fach-satzassoziativer-cache)
- ein Datenwort kann in wenigen Cache-Einträgen (_typischerweise 2-8_) abgelegt sein
- ![image_523.png](image_523.png)
### Direkt abbildender Cache
![image_519.png](image_519.png)
### Voll assoziativer Cache
![image_520.png](image_520.png)
### N-Fach satzassoziativer Cache
![image_521.png](image_521.png)
## Lesezugriff
- Wenn Prozessor Wort aus Hauptspeicher lesen will
- Cache-Logik prüft, ob Wort schon im Cache ist
- **cache hit**
- Daten im Cache
- Wort an Prozessor weitergeben
- Trefferrate = Treffer / Zugriffsrate
- **cache miss**
- Daten nicht im Cache
- Daten aus HS lesen
- Fehlerzugriffsrate = 1 - Trefferrate
- ![image_525.png](image_525.png)
## Lesen von Daten
### Ersetzungsstrategien im assoziativen Cache
- Falls Wort nicht im Cache vorhanden
- aus Speicher in Cache laden
- Bei direkt abgebildeten Cache
- Zuordnung der Adresse des Wortes zu einer Cache-Zeile eindeutig
- Beim assoziativen Cache verschiedene Strategien möglich
- **Least Recently Used (LRU)**
- Wählt Zeile, die am längsten nicht genutzt wurde
- Für mehr als 4-Fach zu aufwendig
- **Zufällig**
- Wähle zufällige Zeile
- Ähnliche Trefferrate wie LRU bei hoher Assoziativität
- **Round-Robin**
- Zyklischer Zugriff
### Initiales Lesen von Daten
- Zwei Lese- / Füllstrategien
- **on demand, demand fetching**
- Beim ersten Lesen einer Information aus HS
- ganze Zeile in Cache laden, falls noch nicht drin
- **Prädiktiv, prefetch**
- Vorhersage, welche Speicherzeilen gebraucht werden
- Während Leerlaufphasen in Cache vorladen
- Zweiter Programmzähler (Remote PC)
- Künftigen Programmablauf bestimmen
- Gut weil
- Bessere Nutzung [räumlicher Lokalität](Rechnersysteme_Intro.md#r-umliche-lokalit-t)
- Prefetching durch Hardware
- Stream Buffers zwischen Cache und Speicher
- Prefetching durch Software
- ```c++
for (int i = 0; i < 1024; i++){
prefetch (array1 [i+k]); // stride k
array1[i] = 2* array1[i];
}
```
## Schreibzugriff
- Daten in Cache und HS müssen konsistent bleiben
- Wenn Prozess Speicherstelle schreiben möchte, die schon im Cache ist
- **write-through**
- Schreiben erfolgt sowohl im Cache als auch im HS
- langsame Schreibzugriffe
- **write-back**
- Schreiben nur im Cache
- Eintrag markieren
- _dirty bit_
- Wenn Cache-Line verdrängt wird in HS schreiben
- _Gefahr Inkonsistenz_
- **No-write**
- Wort nur im HS schreiben
- im Cache als invalid markieren
- langsame Schreibzugriffe
- ggf. danach langsame Lesezugriffe
### Initiales Schreiben von Daten
- **write-around**
- nur in HS schreiben
- **write-allocate**
- fetch on write
- erst Cache-Line in den Cache, dann wie oben
### Übliche Kombinationen
- write-allocate write-back
- write around write through
### Schreib-Buffer
- ![image_526.png](image_526.png)
- beschleunigt Schreiben, da kein Stall erfolgt
- Wenn Buffer voll ist
- strukturelle Abhängigkeit
- Warten bis Schreiben in HS abgearbeitet ist
- Bei direkt folgendem Lesezugriff auf zu schreibende Daten
- Datenabhängigkeit
## Cache Spezifikation
- Definiert durch
- Anzahl der Cache-Zeilen C
- Größe einer Cache-Zeile L
- Assoziativität m
- Daraus lässt sich bestimmen
- Aufteilung der ADress in Offset, Index, Tag
- [Gesamtgröße Cache](#gesamtgr-e-cache)
## Gesamtgröße Cache
![image_527.png](image_527.png)
## Cache-Leistung
![image_528.png](image_528.png)
### Beispiel Cache Leistung
![image_529.png](image_529.png)
![image_530.png](image_530.png)
## Multilevel Cache Organisation
![image_531.png](image_531.png)
- Level 1
- Cache für Instruktionen und Daten
- Level 2
- vereint für Instruktionen und Daten
- Level 3
- auf Board-Ebene (Static RAM)

View File

@ -86,4 +86,56 @@ stateDiagram
```
```
## Z3
- von Konrad Zuse
- auf Basis von Telefonrelais
- Elemente
- ![image_451.png](image_451.png)
- | | Ausführung |
|--------------------------------|----------------------------------------------------------------------------------------------------------------------|
| Technik | 600 Relais Rechenwerk<br/>1600 Relais Speicherwerk |
| Taktfrequenz | 5-10 Hertz |
| Rechenwerk | Gleitkommarechenwerk<br/>16 Takte Multiplikation<br/>3 Takte Addition<br/>18 Takte Division |
| Mittlere Rechengeschwindigkeit | Multiplikation 3 Sekunden<br/>Division 3 Sekunden<br/>Addition 0,7 Sekunden |
| Eingabe | Dezimaltastatur mit 20 Nachkommastellen<br/>Umwandlung nach Binärcode |
| Ausgabe | Mit Lampen<br/>4 Dezimalstellen mit Kommaanzeige<br/>Wortlänge 22 Bit<br/>Gleitkomma: Mantisse, Exponent, Vorzeichen |
| Anzahl Relais | 2000 |
| Anzahl Schrittschalter | 10 für Mikroprogrammsteuerung |
| Speicheraufbau | 1400 Relais, 64 Worte à 22 Bit |
| Leistungsaufnahme | ca. 4000 Watt |
| Gewicht | ca. 1 Tonne |
| Einsatzgebiet | FHügelberechnungen |
## ENIAC
- 17x10 Meter
- 30 Tonnen
- 174 Kilowatt Verbrauch
- Bestandteile
- 17000 Vakuum-Röhren zur Datenverarbeitung
- 7200 Dioden
- 70000 Widerstände
- 10000 Kondensatoren
- 6000 Schalter
- 1500 Relais
- **Keine Trennung zwischen Programm und Maschine**
- Für Programmänderung neu verkabeln
- Geschwindigkeit
- Addition/Subtraktion: 0,2 ms
- Multiplikation: 2,8 ms
- Division: 24 ms
- Quadratwurzel: 300 ms
## EDVAC
- binäres Zahlenformat
- Befehle werden im internen Speicher verarbeitet
- setzte [von-Neumann-Architektur](Prozessorkonzepte.md#von-neumann-rechner-speicherprogrammierter-rechner) um
## EDSAC
- erster elektronischer Computer mit von-Neumann-Architektur
- Programme werden im Speicher abgelegt und verarbeitet

View File

@ -0,0 +1,134 @@
# Multicore [?]
## Erweiterung Steuerwerk
- Zur überlappenden Verarbeitung von Befehlen
### Phasenpipelining
- Mehrere Befehle gleichzeitig im Prozessor in Arbeit
- in unterschiedlichen Phasen
- verwenden unterschiedliche Komponenten des Prozessors
- **Je mehr Stufen, desto mehr Befehle gleichzeitig**
- desto eher wird CPI = 1 erreicht
- Voraussetzung
- Anpassung Befehlssatz an Pipelinebedingungen
- RISC, Load-Store, Register-Register
- Probleme
- Steuerungs-, Daten-, strukturelle Konflikte (=Hazards)
- **Je mehr Stufen, desto schlimmer ist Leeren und Neustart der Pipeline nach falscher Sprungvorhersage**
#### 14-18 Pipelinestufen optimal
#### Verfahren zur Lösung der Konflikte
- Hardware
- Caches, Forwarding, Branch Prediction
- Befehlssatzerweiterung
- Software
- Pipeline-gemäße Sortierung der Befehle durch den Compiler
## Beispiel anhand einer 5-Stufigen Pipeline
![image_532.png](image_532.png)
- **Befehlsholphase (IF)**
- Lesen des Befehls
- separater Speicher von Befehlen und Daten
- Vermeidung von Konflikten mit Datenzugriffen
- `STR R1, [R2]` bzw `ADD R4, R5, R6`
- **Dekodier- / Register-Lese-Phase (ID)**
- Lesen der Register
- möglich wegen fester Plätze für Registernummern im Befehlswort
- `R1, R2` bzw `R5, R6` lesen
- **Ausführungs- / Adressberechnungsphase (EX)**
- Berechnung arithmetischer Funktionen
- `R5 + R6`
- bzw. Adresse für Speicherzugriff
- `[R2] + 0`
- **Speicherzugriffsphase (Mem)**
- Wird nur bei Lade- / Speicherbefehlen benötigt
- _Abspeichern des Werts R1 an zuvor berechnete Adresse [R2]_
- **Abspeicherungsphase (WB)**
- Speichern in Register
- Bei Speicherbefehlen (ohne Autoinkrement) nicht benötigt
- _Speichern des Ergebnisses der Addition in R4_
- **Reihenfolge ohne Pipelining (3 Befehle)**
- ![image_533.png](image_533.png)
- **Reihenfolge mit Pipelining (3 Befehle)**
- ![image_534.png](image_534.png)
- ![image_535.png](image_535.png)
## Pipeline-Konflikte
### Strukturelle Konflikte (structural hazards)
- resultieren aus Ressourcenkonflikten
- überlappende Instruktionen, die gleiche Ressource benutzen
#### Beispiel strukturelle Konflikte
- ![image_536.png](image_536.png)
- ![image_537.png](image_537.png)
- Alternative Darstellung:
- ![image_538.png](image_538.png)
### Datenkonflikte (data hazards)
- resultieren aus Instruktionen, die von Ergebnissen einer vorigen Instruktion abhängig sind
- _bspw. Read-After-Write_
- Instruktion liest aus Register, nachdem eine andere reingeschrieben hat
- **Lösung durch Forwarding**
- Write-After-Read
- Write after Write
- 2 Instruktionen haben gleiches Ergebnisregister
- WAR / WAW
- Konflikte durch Doppelverwendung
- können durch mehr Register gelöst werden
### Steuerungskonflikte (control hazards)
- resultieren aus Sprüngen
- Befehle, die PC verändern
- führt zu entleeren der Pipeline und einem erneuten Befüllen
- ![image_539.png](image_539.png)
## Sprungvorhersage
- Vorhersagen, ob Sprung ausgeführt wird
- Falls nicht ausgeführt wird
- Pipelinedurchlauf nicht unterbrechen
- PC inkrementieren
- nächste Instruktion machen
- Falls richtig, kann Pipeline normal weiter laufen
### Korrektur Sprungvorhersage
![image_540.png](image_540.png)
### Methoden Sprungvorhersage
#### Statisch (vom Computer implementiert)
- Default-Annahmen über Sprungverhalten zur Laufzeit
- Default not taken
- bspw. Verzweigung (Sprung vorwärts)
- Default taken
- bspw. Schleifen (Sprung rückwärts)
- Delayed branches
- ersetzen den freien Slot in der Pipeline mit sinnvollen, Sprungunabhängigen Befehlen
### Dynamisch
- in Abhängigkeit vom tatsächlichen Verhalten des Sprungs
- **Sprungvorhersagepuffer (Branch History Table - BHT)**
- ![image_541.png](image_541.png)
- Sprungziel muss noch ausgerechnet werden
- Kleiner Speicher
- wird mit (Teil der) Adresse des Sprungbefehls indiziert
- verwendet nur wenige untere Bits der Adresse
- Enthält ein Bit
- Sprung beim letzten Mal ausgeführt?
- **Taken / not Taken**
- Vorhersage
- Sprung verhält sich wie beim letzten Mal
- Nachfolgebefehle
- ab vorhergesagter Adresse holen
- Falls Vorhersage Falsch
- Vorhersagebit invertieren
- **Sprungzielvorhersage**
- **Branch Target Buffer (BTB)**
- ![image_542.png](image_542.png)
- Erfolgt in IF-Phase
- Verhalten ähnlich eines Caches
- adressiert mit Sprungbefehlsadresse
- BTB liefer vorhergesagte Adresse als Ergebnis
- Keine Verzögerung
- WENN KORREKT

View File

@ -0,0 +1,96 @@
# Rechnersysteme Intro
## Rechnerarchitektur
![image_495.png](image_495.png)
- **Interne Funktionsweise**
- Architektur eines Rechners
- Design von Maschinenbefehlen → ISA
- **Programmierung in Maschinensprache**
- Befehle
- arithmetic / logic
- Vergleich
- Flags
- Bedingungen
- Sprünge
- Speicherzugriff über Adressen
- Verwendung eines Compilers
- Umsetzung von Hochsprachenkonstrukten in Assembler
## Entwicklung von Mikroprozessoren
### Einfache In-Order-CPU mit kurzer Pipeline
![image_496.png](image_496.png)
- Grundprinzipien:
- Minimaler Hardware-Aufwand
- Höhere Dichte
- Höhere Frequenz
### Out-of-Order superskalare CPU mit vielfältigen Optimierungen
![image_497.png](image_497.png)
- Grundprinzipien:
- Pipelining (Fließband)
- Parallelisierung
- Prinzip der Lokalität
### Erhöhung der Performance durch Superskalarität
![image_498.png](image_498.png)
## Speicherhierarchie
![image_499.png](image_499.png)
### Prinzip der Lokalität
#### Temporäre Lokalität
- Tendenz zur Wiederverwendung zuvor genutzter Datenelemente
- bspw. Instruktionen einer Schleife
#### Räumliche Lokalität
- Tendenz auf Datenelemente zuzugreifen, die in der Nähe von bereits Zugegriffenen liegen
- bspw. sequenzielle Instruktionen, Felder
### Cache
- Pufferspeicher, die Lokalität ausnutzen
- zeitlich/räumlich lokale Daten werden im SRAM vorgehalten
## Performance
- Zielsetzung
- Architekturvergleich von CPU & Speicherarchitektur
- Identifikation ovn Einflussfaktoren auf Performance
**IPC = instructions per cycle**
- Durchsatz
- Arbeitsmenge pro Zeiteinheit
**CPI = cycles per instructions = 1/IPC**
- Latenz
- Zeit pro Befehl
CPU-Zeit = Rechenzeit für n Instruktionen (_messbar_)
$t_{cycle} = frac{1}{f}$
$$
t_{CPU} = n_{instr} * t_{instr}
= n_{instr} * CPI * t_{cycle}
= \frac{n_{instr}*t_{cycle}}{IPC}
$$
$IPC = \frac{n_{instr}}{f*t_{CPU}}$
### Einfluss von Unterbrechungen
- Idealsituation: $CPI = IPC = 1$
- Einzelne Pipeline
- Keine Hazards
- Speicherzugriff: Hit im 1st Level Cache
- Tatsächliche Situation
- ![image_500.png](image_500.png)
### Performance-Vergleich & Speedup
- Vergleich
- $\frac{performance_A}{performance_B}=\frac{t_{cpuA}}{t_{cpu_B}}$
- Speedup
- $\frac{t_{cpuOrig}}{t_{cpuEnhanced}}
#### Speedup durch Multicore
![image_501.png](image_501.png)

View File

@ -127,4 +127,32 @@
## Beispiel Kopieren indiziert
- ![image_437.png](image_437.png)
- ![image_438.png](image_438.png)
-
## Load/Store - Befehlsformat
![image_477.png](image_477.png)
## Adressierungsarten übersicht
| Art | ARM-Beispiel | Alternativer Name |
|-----------------------------|----------------------------------------------------------------------------------|--------------------------------------------------------------------------|
| Immediate | `mov r0, #8` | Literal |
| Direkt | wird nicht unterstützt | Absolute |
| PC-relativ | `ldr r1, [pc, #offset]`<br/>Pseudobefehl, `label` in `.text`<br/>`ldr r1, label` | |
| Register | `mov r0, r1` | Register-to-Register<br/>Register Direct |
| Register-Indirect | `ldr r0, [r1]` | Indexed |
| Indiziert / Index | `ldr r0, [r1, #4]`<br/>`ldr r0, [r1, #4]!`<br/>`ldr r0, [r1], #4` | Pre-indexed<br/>Post-indexed,<br/>pre-incrementing<br/>post-incrementing |
| Basis-indizierte | `ldr r0, [r1, r0, LSL#2]` | |
| Basis-indizierte mit Offset | wird nicht unterstützt | |
## Blocktransfer-Befehle
![image_478.png](image_478.png)
- Register mit niedrigster Nummer wird geladen von/gespeichert nach der niedrigsten Adresse
- Reihenfolge der angegebenen Register im Befehl spielt keine Rolle
### Beispiel
![image_479.png](image_479.png)
## Stacks
- push {}
- pop {}

View File

@ -0,0 +1,170 @@
# ARM Hochsprache Strukturen
## Unterprogrammtechnik
- wird durch `bl Unterprogramm` aufgerufen
- _Unterprogramm_ muss zu dem Zeitpunkt bereits ein bekanntes Label sein
| Blatt-Routinen | Nicht-Blatt-Routinen |
|--------------------------------|--------------------------|
| rufen keine Unterprogramme auf | rufen Unterprogramme auf |
## Unterprogrammaufruf
![image_482.png](image_482.png)
## Indirekte Unterprogrammaufrufe
- Falls Adresse zur Compilezeit nicht bekannt ist
- Annahme: aufzurufende Programmadresse steht in r0
- `mov lr, pc`
- `mov pc, r0`
- Durch Pipelining entsteht im PC die aktuelle Bitadresse +8
- Da jeder Befehl Länge von 4 Byte hat
- Linkregister zeigt auf Rücksprungadresse
## ARM Procedure Calling Standard (APCS)
- Schnittstelle zwischen Programmteilen
- Wie werden Parameter an Unterprogramme übergeben
- Welche Register dürfen zerstört werden
- Wie werden Ereignisse zurückgegeben
- Wie sieht das Stackframe eines Unterprogramms aus
### Konvention zur Parameterübergabe von 32Bit-Daten
- ![image_483.png](image_483.png)
- Parameter 1-4 werden in den Registern r0-r3 übergeben
- Rückgabewert von Funktionen steht im Register r0 oder r0/r1
- Register r0-r3 und Register ip sind Scratch Register
- Inhalt darf im Unterprogramm zerstört werden
- Informationen in r4-r10, fp, sp müssen erhalten werden
- Inhalt von lr wird zur Rückkehr ins aufrufende Programm benötigt
## Parameterübergabe bei anderen Prozessoren (CISC)
- ![image_484.png](image_484.png)
- Übergabe in Registern typisch für Load/Store-Architekturen
- vermeidet Zugriffe auf Speicher
- Andere Prozessoren verwenden Stack
- Parameter
- Rücksprungadresse (PC)
- Ergebnis im ACC zurückgeben
## Blatt-Funktionen
- können lokale Variablen in Scratch-Registern speichern
- Rückkehradresse kann im Linkregister bleiben
- ![image_485.png](image_485.png)
## Nicht-Blatt-Funktionen
- Linkregister wird durch neue Rücksprungadresse überschrieben
- vorher auf Stack retten
- Scratchregister dürfen durch neues Unterprogramm frei verwendet werden
- keine lokalen Variablen speichern
- Variablenregister verwenden
- von Anfang an auf Stack
- ![image_486.png](image_486.png)
## Unterprogramm
- Unterprogrammaufruf mit Parameterübergabe
- Dokumentation
- Übergabewerte & lokale Variablen
- Eingangsprüfung Parameter
- ggf. Abbruch
- ggf. Register retten
- Initialisation Rückgabeparameter, lokale Variablen
- Programmkörper beachten
- Anweisungen, Schleifen, Verzweigungen: Grenzfälle der Indizes
- Speicherzugriffe passend zur Datengröße
- ggf. Register restaurieren
- Rückgabewert setzen
- Rücksprung
## Operanden in Ausdrücken
- Argument im Register
- Argument auf dem Stack
- Stackpointer
- Relative Adressierung
- Stackpointer + Offset
- Als Konstante im Literal-Bereich der Prozedur
- PC-relative Adressierung mit Offset
- Als lokale Variable
- liegt im Stack
- Zugriff relativ zum Stack-Pointer / Frame-Pointer mit LDR
- Als globale Variable
- liegt im statischen Datenbereich im Speicher
- Adresse liegt relativ zur statischen Basisadresse
- Zeiger
- Array
- Kurzschreibweise für Zeiger + Offset
## Kontrollfluss
### IF-ELSE
![image_487.png](image_487.png)
### Switch
![image_488.png](image_488.png)
```c++
int testswitch( int a, int* b, int c ) {
switch (a) {
case 0:
*b = 0;
break;
case 1:
if ( c > 100 ) *b = 0;
else *b = 3;
break;
case 2:
*b = 1;
break;
case 3:
break;
case 4:
*b = 2;
break;
}
}
```
### While
![image_489.png](image_489.png)
### Do-While
![image_490.png](image_490.png)
### For
![image_491.png](image_491.png)
```c++
void testfor( int a[]) {
for (int i = 0; i < 10; i++){
a[i] = 0;
}
}
```
## Objekte, (virtuelle) Methoden
### Methodenaufrufe bei Objekten
- Methode bekommt als ersten Parameter immer einen Zeiger auf das betreffende Objekt (this)
- Zugriff auf Daten des Objektes gewährleistet
### Statischer Objektaufruf
- Falls Methoden einer Klasse nicht virtuell
- Compiler kann zur Compile-Zeit schon Klasse bestimmen und Adresse der Methode einsetzen
### Dynamischer Methodenaufruf
- ![image_492.png](image_492.png)
## Beispiele Assemblerprogramme
### my_max
```c++
#include <stdlib.h>
void my_max(int a, int b, int* c) {}
if (a > b)
*c = a;
else
*c = b;
}
```
#### my_max ohne Optimierung
![image_493.png](image_493.png)
#### my_max mit Optimierung
![image_494.png](image_494.png)

View File

@ -0,0 +1,55 @@
# ARM Hochsprache Typen
## Abstraktion
- Assembler
- Programme auf Basis von
- Befehlen, Adressen, Register, Byte, Wort, ...
- Abstraktion
- wird durch Software erreicht
- keine explizite Sprachunterstützung
- Hochsprachen
- unterstützen besser das Denken in abstrakten Begriffen
- CPU-unabhängig
## Datentypen
- Kennzeichnen sich durch
- Anzahl benötigte Bits
- Anordnung der Bits
- Art der Verwendung der Bits
- Datentypen
- Positive/Negative Ganzzahlen
- binär, dezimal, hexadezimal, Wertbereiche
- Gleitkommazahlen
- [Zeichen](#zeichen)
## Zeichen
- Erste Mainframes
- Uneinheitliche Codierung von Buchstaben
- ASCII:
- 7Bit
- diverse ISO
## ANSI C Basisdatentypen
- Char
- Short Integer
- Integer
- Long Integer
- Float
- Double
- Long Double
- Aufzählungstypen
- Bitfelder
### Abgeleitete ANSI C Datentypen
- Arrays
- Funktionen
- Strukturen
- Zeiger/Pointer
- Varianten/Unions
## Gleitkommazahlen
### ISO IEEE754
![image_480.png](image_480.png)
- Beispiele
- ![image_481.png](image_481.png)

View File

@ -0,0 +1,4 @@
# ARM-Referenzen
![armref-1.jpg](armref-1.jpg)
![armref-2.jpg](armref-2.jpg)