Compare commits
23 Commits
9ae3834c41
...
master
Author | SHA1 | Date | |
---|---|---|---|
870d4d7817 | |||
c4c7da5860 | |||
03fc84e1a7 | |||
2918fe7d6e | |||
cf52c25aef | |||
32cda34fcb | |||
f472bfc88b | |||
a31980d41f | |||
5349c17af3 | |||
e1c8429fcd | |||
e20640b0ee | |||
1711349f6d | |||
5d724f868d | |||
87c32f2f3b | |||
9839a21836 | |||
c3b7a95346 | |||
4f9e9f52f4 | |||
b08b0f6a36 | |||
0580f26359 | |||
0c3af947ec | |||
33d63a1a45 | |||
00bf4325b0 | |||
60fd19d5e2 |
2
.obsidian/appearance.json
vendored
2
.obsidian/appearance.json
vendored
@@ -1,4 +1,4 @@
|
||||
{
|
||||
"baseFontSize": 16,
|
||||
"baseFontSize": 18,
|
||||
"translucency": true
|
||||
}
|
22
.obsidian/workspace
vendored
22
.obsidian/workspace
vendored
@@ -9,7 +9,7 @@
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "School/Analyse/Periode 2/Week 1.md",
|
||||
"file": "Arrowhead/Analysis COH 2.md",
|
||||
"mode": "source"
|
||||
}
|
||||
}
|
||||
@@ -68,7 +68,7 @@
|
||||
"state": {
|
||||
"type": "backlink",
|
||||
"state": {
|
||||
"file": "School/Analyse/Periode 2/Week 1.md",
|
||||
"file": "Arrowhead/Analysis COH 2.md",
|
||||
"collapseAll": false,
|
||||
"extraContext": false,
|
||||
"sortOrder": "alphabetical",
|
||||
@@ -87,15 +87,15 @@
|
||||
},
|
||||
"active": "bc6e8ad9aa0f44c3",
|
||||
"lastOpenFiles": [
|
||||
"School/Analyse/Periode 2/Week 1.md",
|
||||
"School/Analyse/Untitled.md",
|
||||
"School/Analyse/Periode 1/ICMP.md",
|
||||
"School/Analyse/Periode 1/Layers/7. Application Layer.md",
|
||||
"School/Analyse/Periode 1/ARP.md",
|
||||
"School/Analyse/Periode 1/OSI Model.md",
|
||||
"School/NMO/Week 5.md",
|
||||
"Arrowhead/Analysis COH 2.md",
|
||||
"README.md",
|
||||
"School/Analyse/Periode 1/NAT.md",
|
||||
"School/Analyse/Periode 1/IPv6.md",
|
||||
"School/Analyse/Periode 1/IPv4.md",
|
||||
"School/Analyse/Periode 1/DHCP.md",
|
||||
"School/Analyse/Periode 1/Computer Networks.md",
|
||||
"School/Analyse/Periode 1/Comminucation Mediums.md",
|
||||
"School/NMO/Week 3.md",
|
||||
"School/NMO/Week 1.md",
|
||||
"School/NMO/Week 7.md"
|
||||
"School/NMO/Week 2.md"
|
||||
]
|
||||
}
|
45
Arrowhead/Analysis COH 2.md
Normal file
45
Arrowhead/Analysis COH 2.md
Normal file
@@ -0,0 +1,45 @@
|
||||
|
||||
## Resources:
|
||||
- Manpower is connected to amount of units deployed.
|
||||
|
||||
- Fuel and Munitions are connected to the amount of capture point in control.
|
||||
|
||||
- Special capture points only yield one type of resource, but in a increased amount.
|
||||
|
||||
- Each units or buildings have a population cost. Together they count towards the population cap. Population cap has a set limit of 100, which is locked.
|
||||
|
||||
- Command points are collected through experience which is gained by units that are in combat and player building special type of buildings. Command points are used to unlock special abilities of different commanders.
|
||||
|
||||
## Units
|
||||
|
||||
### Unit Spawning
|
||||
Units consist of "characters". When all characters are killed the unit itself is removed. Units can be replenished by buildings and or vehicles. Characters individually have HP level which can be healed by other "medic" units or buildings / items.
|
||||
|
||||
Units are "spawned" though command centers in the players base. Units cost resources (manpower, fuel and munitions). Units can also spawned instantly through commander abilities which may also cost resources.
|
||||
|
||||
### Unit movement
|
||||
Units can be selected and controlled by clicking on locations. When hovering on a possible location the position of each individual character will be shown. If applicable, the type of cover that the unit received will be shown (only for infantry units).
|
||||
|
||||
Infantry units can sometimes hop over objects in the map. Vehicles can sometimes break through (destroy) objects in the map. Examples: Fences, small walls, sandbags, etc...
|
||||
|
||||
Normally units cannot traverse through water, however in some cases the water is shallow enough for units to traverse through.
|
||||
|
||||
If the map is cold enough there can be ice which can break by various means. When broken its not traversable anymore.
|
||||
|
||||
Vehicles cannot move through each other, infantry type can.
|
||||
|
||||
Vehicles can also reverse which will prevent the vehicle from turning around. (It will move backwards directly)
|
||||
|
||||
### Unit behavior
|
||||
|
||||
Units automatically attack enemy units when in range (visible). Units (infantry) can be pinned down by heavy fire from enemies, in this state units cannot move and can only escape by completely retreating.
|
||||
|
||||
Units when suppressed can move a small amount and still return fire albeit in a severely reduced amount. Throwing range of unit abilities (grenades) will also be reduced.
|
||||
|
||||
### Unit specialties
|
||||
Units can have different abilities like grenades, healing, building, salvaging, etc...
|
||||
|
||||
Retreating is a ability that only infantry units have, when used the units will retreat to the nearest retreat point. This is a vital game mechanic will allows the player to save units instead of spawning new.
|
||||
|
||||
### Unit veterancy
|
||||
Units collect experience by being in combat and killing other units. Units with higher levels of veterancy will perform better and may have access to better abilities.
|
BIN
Pasted image 20220126150032.png
Normal file
BIN
Pasted image 20220126150032.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 360 KiB |
@@ -4,4 +4,136 @@ Handles devices that allow the computer system to:
|
||||
* Communicate and interact with the outside world
|
||||
- Screen, keyboard, printer
|
||||
|
||||
* Store information
|
||||
* Store information
|
||||
|
||||
![[io-subsystem.png]]
|
||||
|
||||
# The Control unit
|
||||
Program stored in memory. (machine language in binary)
|
||||
|
||||
Task of control unit is to execute programs by:
|
||||
* Fetch: from memory the next instruction
|
||||
* Decode: instruction to determine what to do
|
||||
* Execute: issuing signals to ALU, memory and IO systems.
|
||||
|
||||
Repeats until HALT instruction.
|
||||
|
||||
# Typical Machine Instructions
|
||||
MOV: move data from a to b
|
||||
ADD: add numbers
|
||||
SUB: subtract numbers
|
||||
JMP: transfers program control flow to the indicated instruction
|
||||
|
||||
![[example-machine-lang.png]]
|
||||
|
||||
# CPU Time vs IO Time
|
||||
Total time required to run program is: CPU Time + IO Time
|
||||
|
||||
Typical time to read from IO: 20ms
|
||||
Typical time to run instruction: 20ns
|
||||
CPU can execute up to 200 million instructions while a block is read from a hard disk.
|
||||
|
||||
Conclusion: While I/O is executed, CPU is idling.
|
||||
|
||||
![[cpu-vs-io.png]]
|
||||
|
||||
Were waiting a lot on IO time to finish, very inefficient. We can solve this using multitasking!
|
||||
|
||||
# Multitasking
|
||||
To speed up computers we overlap CPU time and IO Time.
|
||||
|
||||
While a program waits for IO, other programs can use CPU. This solution requires multiple programs to be loaded into memory, hence the name multitasking.
|
||||
|
||||
Multitasking overlaps IO time of a program with CPU time of other program.
|
||||
|
||||
# Multitasking with multiple processors
|
||||
If computer has a single CPU, programs should take turns in using it.
|
||||
[[School/Analyse/Periode 2/Week 1]]
|
||||
If computer has multiple CPUS, each task can be given a different CPU.
|
||||
- If the number of tasks is more than available cpu's, we still take turns.
|
||||
|
||||
when program issues IO command, cpu is granted to the next program.
|
||||
|
||||
# Concurrent vs Parallel
|
||||
**Concurrent**: Fast switching from a program to the next program (context switch) can create the illusion that they are being executed at the same time. -> **Logically Simultaneous**
|
||||
|
||||
**Parallel**: If the computer has multiple CPU's or Cores, the programs run in parallel. -> **Physically simultaneous**
|
||||
|
||||
![[conc-parallel.png]]
|
||||
|
||||
# Sharing Resources
|
||||
Sometimes different programs (or same program) may share resources.
|
||||
|
||||
If data is **sequentially** accessible, programs should take turns accessing resource/data.
|
||||
|
||||
Fast shared resource access can create **concurrent** access.
|
||||
|
||||
# Concurrency
|
||||
Unlike parallelism, concurrency is not always about running faster.
|
||||
- Single cpu/core computers may also use concurrency.
|
||||
|
||||
Useful for:
|
||||
- App responsiveness.
|
||||
- Processor utilization (hide IO time)
|
||||
- Failure isolation (interleaving multiple tasks, a exception on one task will not bring down the rest)
|
||||
|
||||
# Abstraction in Concurrency
|
||||
**Concurrent program** consists of a finite set of (sequential) processes.
|
||||
|
||||
Processes are written using a finite set of **statements**.
|
||||
|
||||
Execution of concurrent program proceeds by executing a sequence of the statements obtained by **arbitrarily interleaving** the statements from the processes.
|
||||
|
||||
![[abstraction-in-conc.png]]
|
||||
|
||||
p1->q2->p2->q1 is not possible. because we are breaking the order of execution of program q. q must execute q1 before q2.
|
||||
|
||||
# Atomic statement
|
||||
Atomic statement model assumes that a statement is executed to completion without the possibility of interleaving statements from other process.
|
||||
|
||||
Main property of atomic statement is: they cant be divided.
|
||||
|
||||
A single machine level instruction is always atomic.
|
||||
|
||||
|
||||
# Tracing & testing
|
||||
|
||||
concurrent programs are hard to develop and test.
|
||||
|
||||
Concurrency bugs:
|
||||
|
||||
- Simultaneous access same db record
|
||||
- Atomicity violatitions
|
||||
- Deadlocks
|
||||
|
||||
These bugs are hard to detect and fix.
|
||||
|
||||
# Correctness
|
||||
Sequetial programs wil always give the same result. Debugging makes sense.
|
||||
|
||||
Concurrent programs do not behave like this. Some instances may give correct output and some not. (Without protections)
|
||||
|
||||
This implies that we cannot debug a concurrent program in the
|
||||
normal way, because each time we run the program, we will likely
|
||||
have a different order of interleaving.
|
||||
|
||||
Correctness of (non-terminating) concurrent programs is defined in
|
||||
terms of properties of computations, rather than a functional result.
|
||||
|
||||
Types:
|
||||
- Safety properties: the property must always be true.
|
||||
Example: Always, mouse cursor is displayed.
|
||||
|
||||
- Liveness properties: The property must become true at some point.
|
||||
Example: Click with a mouse, eventually the mouse cursor changes.
|
||||
|
||||
# Fairness
|
||||
Arbitrary interleaving assumes no order of speed executing statements for diffrent processes/tasks.
|
||||
- However, it does not make sense to assume that statements from any
|
||||
specific process are never selected in the interleaving.
|
||||
|
||||
A scenario of executing statements is (weakly) fair if a statement that
|
||||
is continually enabled, eventually is selected to execute.
|
||||
|
||||
|
||||
|
||||
|
0
School/Analyse/Periode 2/Week 2.md
Normal file
0
School/Analyse/Periode 2/Week 2.md
Normal file
BIN
abstraction-in-conc.png
Normal file
BIN
abstraction-in-conc.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 175 KiB |
BIN
conc-parallel.png
Normal file
BIN
conc-parallel.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 360 KiB |
BIN
cpu-vs-io.png
Normal file
BIN
cpu-vs-io.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 268 KiB |
BIN
example-machine-lang.png
Normal file
BIN
example-machine-lang.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 183 KiB |
BIN
io-subsystem.png
Normal file
BIN
io-subsystem.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 137 KiB |
Reference in New Issue
Block a user