update
This commit is contained in:
David Schirrmeister
@ -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
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Energieeffizienz
|
||||
# Energieeffizienz [-]
|
||||
## Energieverwaltung
|
||||
- Frequenzskalierung der CPU
|
||||
- Spannungs- und Frequenzanpassung
|
||||
|
||||
@ -51,7 +51,7 @@
|
||||
- sehr ineffizient
|
||||
|
||||
|
||||
## Dynamische Partitionierung
|
||||
### Dynamische Partitionierung
|
||||
- BS weist jedem Prozess eine zusammenhängende Partition zu
|
||||
- mit exakt benötigter Größe
|
||||
- dabei auch Fragmentierung
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Dateisysteme
|
||||
# Dateisysteme [-]
|
||||
## Warum Dateisysteme
|
||||
- Neben Verwaltung des Hauptspeichers und Cache
|
||||
- Verwaltung des Massenspeichers (bspw. SSD, Festplatte)
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Plattenspeicherverwaltung
|
||||
# Plattenspeicherverwaltung [-]
|
||||
## Mögliche Strategien
|
||||
**Speicherung von einer Datei mit n Byte**
|
||||
- n aufeinanderfolgende Byte auf der Platte reservieren
|
||||
|
||||
@ -33,6 +33,9 @@
|
||||
- Energieeffizienz
|
||||
- Dateisysteme
|
||||
- Plattenspeicherverwaltung
|
||||
- Historie
|
||||
- Formeln / Mathe-Shit
|
||||
- POSIX-API Befehle
|
||||
- Und alles was da oben nicht steht :)
|
||||
|
||||
|
||||
|
||||
@ -250,7 +250,7 @@
|
||||
## Composite Pattern
|
||||
- Baumartige Objektstruktur
|
||||
### Structure Composite Pattern
|
||||
|
||||
|
||||
|
||||
#### Component (Abstract Class)
|
||||
- Deklariert Interface für Objekte in der Komposition
|
||||
@ -270,7 +270,7 @@
|
||||
|
||||
|
||||
## Strategy Pattern
|
||||
|
||||
|
||||
|
||||
## State Pattern
|
||||
|
||||
|
||||
@ -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)
|
||||
7
Writerside/topics/02/RA/ARM_Befehlsübersicht.md
Normal file
7
Writerside/topics/02/RA/ARM_Befehlsübersicht.md
Normal file
@ -0,0 +1,7 @@
|
||||
# ARM-Befehlsübersicht
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
227
Writerside/topics/02/RA/Caches.md
Normal file
227
Writerside/topics/02/RA/Caches.md
Normal file
@ -0,0 +1,227 @@
|
||||
# Caches
|
||||
## Cache-Speicher
|
||||
|
||||
- Deutlich schneller als Zugriff auf Hauptspeicher
|
||||
- viel kleiner als Hauptspeicher
|
||||
|
||||
## Grundprinzipien
|
||||
|
||||
|
||||
## 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
|
||||
|
||||
- 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
|
||||
|
||||
|
||||
|
||||
### Index: Cache Adressierung
|
||||
|
||||
- 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
|
||||
- 
|
||||
|
||||
### Assoziativität: Cache-Zeilen mit gleichem Index
|
||||
|
||||
- Durch weiteren Satz von Cache-Lines
|
||||
- Daten mit gleichem Index aber unterschiedlichen Tags speichern
|
||||
- 
|
||||
|
||||
#### 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
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Zusammenfassung Adressierung
|
||||
|
||||
|
||||
## Cache Organisation (Assoziativität)
|
||||
- [Direkt abgebildet (direct mapped)](#direkt-abbildender-cache)
|
||||
- ein Datenwort kann in einem Eintrag abgelegt sein
|
||||
- 
|
||||
- [Voll assoziativ (fully associative)](#voll-assoziativer-cache)
|
||||
- ein Datenwort kann in einem beliebigen Cache-Eintrag abgelegt sein
|
||||
- 
|
||||
- [Satz assoziativ (set associative)](#n-fach-satzassoziativer-cache)
|
||||
- ein Datenwort kann in wenigen Cache-Einträgen (_typischerweise 2-8_) abgelegt sein
|
||||
- 
|
||||
|
||||
### Direkt abbildender Cache
|
||||
|
||||
|
||||
### Voll assoziativer Cache
|
||||
|
||||
|
||||
### N-Fach satzassoziativer Cache
|
||||
|
||||
|
||||
## 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
|
||||
- 
|
||||
|
||||
|
||||
## 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
|
||||
- 
|
||||
- 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
|
||||
|
||||
|
||||
## Cache-Leistung
|
||||
|
||||
|
||||
### Beispiel Cache Leistung
|
||||
|
||||
|
||||
|
||||
## Multilevel Cache Organisation
|
||||
|
||||
- Level 1
|
||||
- Cache für Instruktionen und Daten
|
||||
- Level 2
|
||||
- vereint für Instruktionen und Daten
|
||||
- Level 3
|
||||
- auf Board-Ebene (Static RAM)
|
||||
|
||||
@ -86,4 +86,56 @@ stateDiagram
|
||||
|
||||
|
||||
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
## Z3
|
||||
- von Konrad Zuse
|
||||
- auf Basis von Telefonrelais
|
||||
- Elemente
|
||||
- 
|
||||
- | | 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
|
||||
134
Writerside/topics/02/RA/Multicore.md
Normal file
134
Writerside/topics/02/RA/Multicore.md
Normal 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
|
||||
|
||||
- **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)**
|
||||
- 
|
||||
- **Reihenfolge mit Pipelining (3 Befehle)**
|
||||
- 
|
||||
- 
|
||||
|
||||
## Pipeline-Konflikte
|
||||
### Strukturelle Konflikte (structural hazards)
|
||||
- resultieren aus Ressourcenkonflikten
|
||||
- überlappende Instruktionen, die gleiche Ressource benutzen
|
||||
|
||||
#### Beispiel strukturelle Konflikte
|
||||
- 
|
||||
- 
|
||||
- Alternative Darstellung:
|
||||
- 
|
||||
|
||||
### 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
|
||||
- 
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
### 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)**
|
||||
- 
|
||||
- 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)**
|
||||
- 
|
||||
- Erfolgt in IF-Phase
|
||||
- Verhalten ähnlich eines Caches
|
||||
- adressiert mit Sprungbefehlsadresse
|
||||
- BTB liefer vorhergesagte Adresse als Ergebnis
|
||||
- Keine Verzögerung
|
||||
- WENN KORREKT
|
||||
|
||||
|
||||
96
Writerside/topics/02/RA/Rechnersysteme_Intro.md
Normal file
96
Writerside/topics/02/RA/Rechnersysteme_Intro.md
Normal file
@ -0,0 +1,96 @@
|
||||
# Rechnersysteme Intro
|
||||
## Rechnerarchitektur
|
||||
|
||||
- **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
|
||||
|
||||
- Grundprinzipien:
|
||||
- Minimaler Hardware-Aufwand
|
||||
- Höhere Dichte
|
||||
- Höhere Frequenz
|
||||
|
||||
### Out-of-Order superskalare CPU mit vielfältigen Optimierungen
|
||||
|
||||
- Grundprinzipien:
|
||||
- Pipelining (Fließband)
|
||||
- Parallelisierung
|
||||
- Prinzip der Lokalität
|
||||
|
||||
### Erhöhung der Performance durch Superskalarität
|
||||
|
||||
|
||||
|
||||
## Speicherhierarchie
|
||||
|
||||
### 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
|
||||
- 
|
||||
|
||||
|
||||
### Performance-Vergleich & Speedup
|
||||
- Vergleich
|
||||
- $\frac{performance_A}{performance_B}=\frac{t_{cpuA}}{t_{cpu_B}}$
|
||||
- Speedup
|
||||
- $\frac{t_{cpuOrig}}{t_{cpuEnhanced}}
|
||||
|
||||
#### Speedup durch Multicore
|
||||
|
||||
|
||||
@ -127,4 +127,32 @@
|
||||
## Beispiel Kopieren indiziert
|
||||
- 
|
||||
- 
|
||||
-
|
||||
|
||||
|
||||
## Load/Store - Befehlsformat
|
||||
|
||||
|
||||
## 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
|
||||
|
||||
- Register mit niedrigster Nummer wird geladen von/gespeichert nach der niedrigsten Adresse
|
||||
- Reihenfolge der angegebenen Register im Befehl spielt keine Rolle
|
||||
|
||||
### Beispiel
|
||||
|
||||
|
||||
## Stacks
|
||||
- push {}
|
||||
- pop {}
|
||||
170
Writerside/topics/02/RA/arm_hochsprache_strukturen.md
Normal file
170
Writerside/topics/02/RA/arm_hochsprache_strukturen.md
Normal 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
|
||||
|
||||
|
||||
## 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
|
||||
- 
|
||||
- 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)
|
||||
- 
|
||||
- Ü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
|
||||
- 
|
||||
|
||||
## 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
|
||||
- 
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
### Switch
|
||||
|
||||
```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
|
||||
|
||||
|
||||
### Do-While
|
||||
|
||||
|
||||
### For
|
||||
|
||||
```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
|
||||
- 
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
#### my_max mit Optimierung
|
||||
|
||||
|
||||
55
Writerside/topics/02/RA/arm_hochsprache_typen.md
Normal file
55
Writerside/topics/02/RA/arm_hochsprache_typen.md
Normal 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
|
||||
|
||||
|
||||
- Beispiele
|
||||
- 
|
||||
|
||||
4
Writerside/topics/02/RA/armref.md
Normal file
4
Writerside/topics/02/RA/armref.md
Normal file
@ -0,0 +1,4 @@
|
||||
# ARM-Referenzen
|
||||
|
||||
|
||||
|
||||
@ -0,0 +1,59 @@
|
||||
# Integrierte Informationsverarbeitung
|
||||
## Lernziele
|
||||
- [Kategorien von Anwendungssystemen](#haupttypen-betrieblicher-anwendungssysteme)
|
||||
- erkennen, wesentliche Eigenschaften nennen, unterscheiden
|
||||
- [betriebliche Anwendungssystempyramide skizzieren](#haupttypen-betrieblicher-anwendungssysteme)
|
||||
- Architektur eines DWH skizzieren
|
||||
- horizontale und vertikale Integration
|
||||
- ERP-, CRM-, SCM- Systeme
|
||||
- Eigenschaften, Vorteile, Herausforderungen
|
||||
|
||||
## Haupttypen betrieblicher Anwendungssysteme
|
||||
|
||||
### FUS bzw. FUS
|
||||
> Unterstützungssysteme für die Führungsebene
|
||||
|
||||
### MIS
|
||||
> Managementinformationssysteme
|
||||
|
||||
### DSS bzw. EUS
|
||||
> Entscheidungsunterstützungssysteme
|
||||
|
||||
### OSS
|
||||
> Operative Systeme
|
||||
|
||||
|
||||
## MIS vs. EUS/DSS
|
||||
### Verbindung der einzelnen Arten von Anwendungssystemen
|
||||
|
||||
|
||||
### Integration
|
||||
> Verknüpfung von Menschen, Aufgaben und Technik zu einem einheitlichen Ganzen
|
||||
>
|
||||
> Um den Funktions- / Prozess- / Abteilungsgrenzen entgegenzuwirken
|
||||
|
||||
### Integrationsaspekte betrieblicher AWS
|
||||
|
||||
#### Integrationsgegenstand: Daten
|
||||
- Gemeinsame Nutzung derselben Daten durch mehrere Funktionen
|
||||
- **Ziel**
|
||||
- Redundanzarme Speicherung von Daten
|
||||
- Dateninkonsistenzen vermeiden
|
||||
- **Mittelpunkt**
|
||||
- Logische Integrität von Datenbanksystemen
|
||||
- Einfachste Form der Kupplung von Anwendungssystemen
|
||||
|
||||
#### Integrationsgegenstand: (Unternehmens-)Funktion
|
||||
- **Voraussetzung**
|
||||
- Auf Datenebene durchgeführte Integration
|
||||
- Unterscheidung zwischen Ausrichtung
|
||||
- nach Aufgabenträger
|
||||
- nach Datenfluss
|
||||
- Nimmt Einfluss auf organisatorische Gestaltung des Unternehmens
|
||||
|
||||
#### Integrationsgegenstand: Objekt
|
||||
- Vereinigt Aspekte der vorherigen Integrationen
|
||||
- Kommunikation zwischen Objekten über Nachrichten
|
||||
- Formen
|
||||
- Intra-Objektorganisation
|
||||
- Inter-Objektorganisation
|
||||
173
Writerside/topics/06/EWI/9_Internetökonomie.md
Normal file
173
Writerside/topics/06/EWI/9_Internetökonomie.md
Normal file
@ -0,0 +1,173 @@
|
||||
# Internet-Ökonomie, digitale Geschäftsmodelle, Plattformen
|
||||
## Lernziele
|
||||
- Zentrale Eigenschaften [digitaler Güter](#digitale-g-ter) und [Märkte](#digitale-m-rkte)
|
||||
- [fundamentale Prinzipien der Internet-Ökonomie](#grundlagen-der-internet-konomie)
|
||||
- [Mechanismen von Netzwerkgütern und Netzwerkeffekten](#konomie-der-netzwerkeffekte)
|
||||
- wesentliche Merkmale von [digitalen Plattformen](#digitale-plattformen)
|
||||
|
||||
## Grundlagen der Internetökonomie
|
||||
### Digitale Güter
|
||||
- immaterielle Mittel zur Bedürfnisbefriedigung
|
||||
- bestehen aus Binärdaten
|
||||
- lassen sich mithilfe von IKT(_Anwendungsbereich für Informations- und Kommunikationstechnologien_) entwickeln/vertreiben/anwenden
|
||||
- Beispiele
|
||||
- Digitalisierbare Produkte
|
||||
- _Nachrichten, Zeitschriften, Software_
|
||||
- Digitale Duplikate physischer Produkte
|
||||
- _Bankschecks, Konzertkarten, Fotos_
|
||||
- Digitale Dienstleistungen
|
||||
- _Cloud Computing, Kommunikations-/Entwicklungsleistungen_
|
||||
|
||||
#### Unterschied Digitale / Traditionelle Güter
|
||||
| | Materielle Güter | Digitale Güter |
|
||||
|-------------------------|--------------------------------------|-----------------------------------|
|
||||
| Vervielfältigungskosten | hoch | niedrig |
|
||||
| Wertstabilität | Verlust durch Gebrauch | Gewinn durch Verbrauch |
|
||||
| Besitz | Individuell | Vielfach (möglich) |
|
||||
| Datenschutz | Identifikations-/Schutzmöglichkeiten | Probleme |
|
||||
| Verbreitung | schwierig (Logistik) | einfach |
|
||||
| Preis/Wert | leicht identifizierbar | nur subjektiv |
|
||||
| Kosten | leicht identifizierbar | [schwer identifizierbar](#kosten) |
|
||||
| Bestandsbewertung | möglich | problematisch |
|
||||
| Verbreitung | physisch | über netzbasierte Medien |
|
||||
|
||||
|
||||
#### Kosten
|
||||
- Teuer in Produktion
|
||||
- Günstig in Verteilung/Reproduktion
|
||||
- erste digitale Kopie hat einmaligen Aufwand an Fixkosten
|
||||
- **First Copy Costs**
|
||||
- Stückkostendegression
|
||||
- "The Winner takes it all!"
|
||||
- 
|
||||
- 
|
||||
- 
|
||||
|
||||
#### Nutzen
|
||||
- Verbreitung hat hohen Einfluss
|
||||
- 
|
||||
- Netzwerkgüter
|
||||
- zur vollen Nutzenentfaltung benötigen sie komplementäre Produkte
|
||||
- Beispiel Facebook:
|
||||
- Wert steigt für jeden Benutzer, je mehr Benutzer verbunden sind
|
||||
- 
|
||||
|
||||
|
||||
### Digitale Märkte
|
||||
- vollständige Informationen erreichbar
|
||||
- Produkte, Unternehmen, Kunden
|
||||
- erhöht Markttransparenz
|
||||
- räumliche Unabhängigkeit
|
||||
- zeitliche Unabhängigkeit
|
||||
- kurze Reaktionszeiten
|
||||
- ineffiziente Marktteilnehmer überleben nicht
|
||||
|
||||
|
||||
## Ökonomie der Netzwerkeffekte
|
||||
### Direkte Netzwerkeffekte
|
||||
- Netzwerkvergrößerung wirkt sich unmittelbar für alle bisherigen Teilnehmer aus
|
||||
- 
|
||||
|
||||
### Indirekte Netzwerkeffekte
|
||||
- Folgeeffekte (_bspw. Angebot von Komplementärgütern_)
|
||||
- ergeben sich mittelbar durch höhere Nutzerzahl eines Gutes
|
||||
- 
|
||||
|
||||
#### Beispiel indirekte Netzwerkeffekte
|
||||
- 
|
||||
- 
|
||||
|
||||
## Plattformen und Plattform-Ökonomie
|
||||
### Was ist eine Plattform
|
||||
- Online-Umgebung
|
||||
- nutzt wirtschaftliche Vorteile "**kostenlos, perfekt, sofort**"
|
||||
- Geschäftsmodell
|
||||
- wertschöpfende Interaktion zwischen Anbieter und Kunde ermöglichen
|
||||
- offene Infrastruktur
|
||||
- Rahmenbedingungen und Regeln dafür festlegen
|
||||
|
||||
### Plattformen stellen Unternehmen auf den Kopf
|
||||
|
||||
|
||||
### 4C-Business-Net-Typologie
|
||||
| | Content | Commerce | Context | Connection |
|
||||
|--------|-----------------------------------------------------------------------------|---------------------------------------------------------------|-------------------------------------------------------------------|-------------------------------------------------------------|
|
||||
| Inhalt | Sammlung, Selektion, Systematisierung, Kompilierung, | Anbahnung, Aushandlung/Abwicklung von Informationen | Klassifikation und Systematisierung von verfügbaren Informationen | Herstellung eines Informationsaustausches in Netzen |
|
||||
| Ziel | Online-Bereitstellung von Konsumentenzentrierten, personalisierten Inhalten | Ergänzung bzw. Substitution traditioneller Transaktionsphasen | Komplexitätsreduktion, Navigation | Kommerzielle oder rein kommunikative Verbindungen in Netzen |
|
||||
| Erlöse | Indirekte Erlösmodelle (vor allem Werbemärkte) | Transaktionsabhängige, direkte/indirekte Erlösmodelle | Indirekte Erlösmodelle | Direkte/Indirekte Erlösmodelle |
|
||||
|
||||
### Plattformen sind besser als Pipelines
|
||||
|
||||
|
||||
### 4 Arten von Plattformen
|
||||
|
||||
|
||||
|
||||
## Netzwerkeffekte
|
||||
### auf mehrseitigen Plattformen
|
||||
|
||||
|
||||
### auf bestehenden Plattformen
|
||||
|
||||
|
||||
### Wirkungen
|
||||
|
||||
|
||||
#### Beispiel Airbnb
|
||||
|
||||
|
||||
|
||||
## Effekt der Komplemente
|
||||
### Nachfragekurve
|
||||
|
||||
|
||||
### Angebotskurve
|
||||
|
||||
|
||||
### Matching Angebot und Nachfrage
|
||||
|
||||
|
||||
### Komplemente verschieben Nachfragekurven nach innen/außen
|
||||
|
||||
|
||||
### Komplemente (kostenlos, perfekt, sofort)
|
||||
- Beschleuniger einer Plattform
|
||||
|
||||
|
||||
### Online-to-Offline (O2O) Plattformen
|
||||
- Falls "kostenlos, perfekt, sofort" nicht gilt
|
||||
- Ökonomie der Bits auf profitabler Weise mit Ökonomie der Atome zusammenbringen
|
||||
- Verbesserung der Ressourceneffizienz
|
||||
|
||||
|
||||
## Digitale Plattformen
|
||||
### Erfolgsfaktoren
|
||||
- zeitig im Markt
|
||||
- Effekte der Komplementärgüter nutzen
|
||||
- Plattform für andere Akteure öffnen
|
||||
- Spielraum für Eintritt glücklicher Zufälle lassen
|
||||
- Plattform pflegen
|
||||
- Dinge so einfach wie möglich machen
|
||||
- Schöne, einfache UI
|
||||
- minimierte Informationsasymmetrie
|
||||
- Managen der Spannungen und Dilemmata
|
||||
|
||||
### Transformation zu mehrseitigen Plattformen (MSP)
|
||||
| Strategie | Voraussetzungen | Maßnahme | Zeichnung |
|
||||
|-------------------------------------------|----------------------------------------------------------------------------------|---------------------------------------------------------------------------------|---------------------------------|
|
||||
| 3rd Party erlauben | großer Kundenstamm, den Dritte mit eigenen Angeboten erreichen wollen | Dritten Möglichkeit geben mit Kunden in Kontakt zu treten |  |
|
||||
| Kunden verbinden | versch. Kundensegmente, die außerhalb des Angebots miteinander interagieren | Angebot modifizieren, sodass ein Teil der Interaktion im Produkt liegt |  |
|
||||
| Produkte verbinden um Kunden zu verbinden | Pro Kundenstamm ein Produkt<br/>Kundenstämme interagieren unabhängig vom Angebot | Produkte verbinden und so Interaktion in Produkt integrieren |  |
|
||||
| Verkauf an MSP | großer Kundenstamm, Kunden der Kunden Mehrwert bieten | Angebot für Kunden der Kunden erstellen<br/>erhöht Wert des Produkts vom Kunden |  |
|
||||
|
||||
|
||||
### Kritik an Plattformen
|
||||
- Monopolisierung
|
||||
- Entwicklung attraktiv, nur für wenige Firmen realistisch
|
||||
- geografische Konzentration in den USA/China
|
||||
- Datenschutz der Nutzungs-/Transaktionsdaten
|
||||
- Unternehmen definieren "Spielregeln"
|
||||
- Reduktion der User auf Rolle der Marktteilnehmer vs. Menschen
|
||||
- Fokus Kaufkraft, Aufmerksamkeit, Verweildauer
|
||||
- Risiko Manipulation
|
||||
|
||||
8
Writerside/topics/06/EWI/Uebung_1.md
Normal file
8
Writerside/topics/06/EWI/Uebung_1.md
Normal file
@ -0,0 +1,8 @@
|
||||
# Übung 1
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -8,9 +8,8 @@
|
||||
- Task 1 → Task 2
|
||||
|
||||
### b) Berechnen Sie die durchschnittliche DLZ
|
||||
$$
|
||||
DLZ = 5min + 0,2*[70min + 0,3*(15min)+0,7*(30min+10min)]+0,8*(10min) = 33,5min
|
||||
$$
|
||||
$DLZ = 5min + 0,2*[70min + 0,3*(15min)+0,7*(30min+10min)]$
|
||||
$+0,8*(10min) = 33,5min$
|
||||
|
||||
## Aufgabe 2: Prozesszeit/-kostenrechnung
|
||||
**Berechnen Sie die durchschnittliche Durchlaufzeit eines Supportfalls gemäss den Angaben
|
||||
|
||||
3
Writerside/topics/StartPage.md
Normal file
3
Writerside/topics/StartPage.md
Normal file
@ -0,0 +1,3 @@
|
||||
# Startseite
|
||||
|
||||
#### Für sämtliche Informationen übernehme ich keine Haftung!
|
||||
Reference in New Issue
Block a user