Compare commits
3 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| e030a195ab | |||
| d3f4a46acb | |||
| 970aa9b9e2 |
6
.obsidian/plugins/obsidian-git/data.json
vendored
6
.obsidian/plugins/obsidian-git/data.json
vendored
@ -1,5 +1,6 @@
|
||||
{
|
||||
"commitMessage": "vault backup: {{date}}",
|
||||
"autoCommitMessage": "vault backup: {{date}}",
|
||||
"commitDateFormat": "YYYY-MM-DD HH:mm:ss",
|
||||
"autoSaveInterval": 0,
|
||||
"autoPushInterval": 0,
|
||||
@ -8,6 +9,7 @@
|
||||
"disablePush": false,
|
||||
"pullBeforePush": true,
|
||||
"disablePopups": false,
|
||||
"showErrorNotices": true,
|
||||
"disablePopupsForNoChanges": false,
|
||||
"listChangedFilesInMessageBody": false,
|
||||
"showStatusBar": true,
|
||||
@ -29,6 +31,7 @@
|
||||
"showFileMenu": true,
|
||||
"authorInHistoryView": "hide",
|
||||
"dateInHistoryView": false,
|
||||
"diffStyle": "split",
|
||||
"lineAuthor": {
|
||||
"show": false,
|
||||
"followMovement": "inactive",
|
||||
@ -53,6 +56,5 @@
|
||||
"gutterSpacingFallbackLength": 5,
|
||||
"lastShownAuthorDisplay": "initials",
|
||||
"lastShownDateTimeFormatOptions": "date"
|
||||
},
|
||||
"autoCommitMessage": "vault backup: {{date}}"
|
||||
}
|
||||
}
|
||||
45503
.obsidian/plugins/obsidian-git/main.js
vendored
45503
.obsidian/plugins/obsidian-git/main.js
vendored
File diff suppressed because one or more lines are too long
7
.obsidian/plugins/obsidian-git/manifest.json
vendored
7
.obsidian/plugins/obsidian-git/manifest.json
vendored
@ -1,9 +1,10 @@
|
||||
{
|
||||
"author": "Vinzent",
|
||||
"authorUrl": "https://github.com/Vinzent03",
|
||||
"id": "obsidian-git",
|
||||
"name": "Git",
|
||||
"description": "Backup your vault with Git.",
|
||||
"description": "Integrate Git version control with automatic backup and other advanced features.",
|
||||
"isDesktopOnly": false,
|
||||
"fundingUrl": "https://ko-fi.com/vinzent",
|
||||
"js": "main.js",
|
||||
"version": "2.24.2"
|
||||
"version": "2.33.0"
|
||||
}
|
||||
|
||||
49
.obsidian/plugins/obsidian-git/styles.css
vendored
49
.obsidian/plugins/obsidian-git/styles.css
vendored
@ -39,6 +39,10 @@
|
||||
margin-right: auto;
|
||||
}
|
||||
|
||||
.obsidian-git-disabled {
|
||||
opacity: 0.5;
|
||||
}
|
||||
|
||||
.obsidian-git-center-button {
|
||||
display: block;
|
||||
margin: 20px auto;
|
||||
@ -77,6 +81,10 @@
|
||||
height: auto;
|
||||
}
|
||||
|
||||
.is-active .git-tools .buttons > * {
|
||||
color: var(--nav-item-color-active);
|
||||
}
|
||||
|
||||
.git-author {
|
||||
color: var(--text-accent);
|
||||
}
|
||||
@ -550,9 +558,48 @@
|
||||
white-space: pre; /* Keep spaces and do not collapse them. */
|
||||
}
|
||||
|
||||
@media(max-width:800px){
|
||||
@media (max-width: 800px) {
|
||||
/* hide git blame gutter not to superpose text */
|
||||
.cm-gutterElement.obs-git-blame-gutter {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
.git-unified-diff-view,
|
||||
.git-split-diff-view .cm-deletedLine .cm-changedText {
|
||||
background-color: #ee443330;
|
||||
}
|
||||
|
||||
.git-unified-diff-view,
|
||||
.git-split-diff-view .cm-insertedLine .cm-changedText {
|
||||
background-color: #22bb2230;
|
||||
}
|
||||
|
||||
/* Limits the scrollbar to the view body */
|
||||
.git-view {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
position: relative;
|
||||
height: 100%;
|
||||
}
|
||||
|
||||
.git-obscure-prompt[git-is-obscured="true"] #git-show-password:after {
|
||||
-webkit-mask-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="svg-icon lucide-eye"><path d="M2.062 12.348a1 1 0 0 1 0-.696 10.75 10.75 0 0 1 19.876 0 1 1 0 0 1 0 .696 10.75 10.75 0 0 1-19.876 0"></path><circle cx="12" cy="12" r="3"></circle></svg>');
|
||||
}
|
||||
|
||||
.git-obscure-prompt[git-is-obscured="false"] #git-show-password:after {
|
||||
-webkit-mask-image: url('data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="svg-icon lucide-eye-off"><path d="M10.733 5.076a10.744 10.744 0 0 1 11.205 6.575 1 1 0 0 1 0 .696 10.747 10.747 0 0 1-1.444 2.49"></path><path d="M14.084 14.158a3 3 0 0 1-4.242-4.242"></path><path d="M17.479 17.499a10.75 10.75 0 0 1-15.417-5.151 1 1 0 0 1 0-.696 10.75 10.75 0 0 1 4.446-5.143"></path><path d="m2 2 20 20"></path></svg>');
|
||||
}
|
||||
|
||||
/* Override styling of Codemirror merge view "collapsed lines" indicator */
|
||||
.git-split-diff-view .ͼ2 .cm-collapsedLines {
|
||||
background: var(--interactive-normal);
|
||||
border-radius: var(--radius-m);
|
||||
color: var(--text-accent);
|
||||
font-size: var(--font-small);
|
||||
padding: var(--size-4-1) var(--size-4-1);
|
||||
}
|
||||
.git-split-diff-view .ͼ2 .cm-collapsedLines:hover {
|
||||
background: var(--interactive-hover);
|
||||
color: var(--text-accent-hover);
|
||||
}
|
||||
|
||||
9989
.obsidian/plugins/obsidian-style-settings/main.js
vendored
9989
.obsidian/plugins/obsidian-style-settings/main.js
vendored
File diff suppressed because one or more lines are too long
@ -1,7 +1,7 @@
|
||||
{
|
||||
"id": "obsidian-style-settings",
|
||||
"name": "Style Settings",
|
||||
"version": "1.0.8",
|
||||
"version": "1.0.9",
|
||||
"minAppVersion": "0.11.5",
|
||||
"description": "Offers controls for adjusting theme, plugin, and snippet CSS variables.",
|
||||
"author": "mgmeyers",
|
||||
|
||||
File diff suppressed because one or more lines are too long
@ -7,10 +7,11 @@
|
||||
- $j$ зависит по данным от $k$ и $k$ зависит по данным от $i$ (цепочка конфликтов RAW).
|
||||
|
||||
**Пример зависимости по данным:**
|
||||
```assembly
|
||||
Loop: LD [R1], F0
|
||||
```armasm
|
||||
Loop:
|
||||
LD [R1], F0
|
||||
DADD F2, F0, F4
|
||||
ST F4, [R1]
|
||||
ST F4, [R1]
|
||||
```
|
||||
|
||||
**Зависимость по именам** возникает, когда 2 инструкции используют один и тот же регистр или место в памяти, т.е. общее имя места.
|
||||
@ -32,13 +33,13 @@ $i$, $j$ пишут по одинаковому имени. Тогда $j$ за
|
||||
Изменение относительного порядка исполнения $i$, $j$ нарушает эту зависимость по именам и приводит к конфликту WAW и некорректному исполнению.
|
||||
|
||||
**Пример:**
|
||||
```assembly
|
||||
1 LD F0, [R1]
|
||||
2 DADD F2, F0, F4
|
||||
3 ST F4, [R1]
|
||||
4 LD F0, [R1-8]
|
||||
5 DADD F2, F0, F4
|
||||
6 ST F4, [R1-8]
|
||||
```armasm
|
||||
LD F0, [R1] ; 1
|
||||
DADD F2, F0, F4 ; 2
|
||||
ST F4, [R1] ; 3
|
||||
LD F0, [R1-8] ; 4
|
||||
DADD F2, F0, F4 ; 5
|
||||
ST F4, [R1-8] ; 6
|
||||
```
|
||||
|
||||
В графе можем переупорядочивать инструкции только если сохраняется порядок стрелок.
|
||||
|
||||
@ -1,17 +1,22 @@
|
||||
#### Зависимость по управлению.
|
||||
|
||||
Определяют порядок инструкции с учетом инструкций перехода.
|
||||
|
||||
Каждая инструкция в программе кроме тех, которые находятся в самом первом базовом блоке программы, зависима по управлению от некоторого множества переходов.
|
||||
|
||||
Инструкцию, зависимую по управлению от перехода нельзя переместить перед переходом так, что ее исполнение более не будет управляться переходом.
|
||||
|
||||
Инструкцию, не зависимую по управлению от перехода нельзя переместить так, что ее исполнение будет управляться переходом (в часть then).
|
||||
|
||||
В некоторых случаях возможно обойти эти ограничения и сохранить корректное исполнение.
|
||||
|
||||
**Пример зависимости:**
|
||||
```c
|
||||
if p1{
|
||||
s1; s1 зависима по управлению от p1. s2 зависима по управлению от p2, но не от p1.
|
||||
if p1 {
|
||||
s1; // s1 зависима по управлению от p1
|
||||
}
|
||||
if p2{
|
||||
s2;
|
||||
|
||||
if p2 {
|
||||
s2; // s2 зависима по управлению от p2, но не от p1
|
||||
}
|
||||
```
|
||||
@ -1,7 +1,9 @@
|
||||
#### Определения задержки и периода запуска. Конвейеризуемые и неконвейеризуемые функциональные блоки.
|
||||
|
||||
**Задержка функциональных устройств** - количество тактов между инструкцией, производящей результат и инструкцией, которая его использует. Обычно равно числу тактов простоя при использовании пересылки.
|
||||
|
||||
**Период запуска или интервал повтора** - число тактов, которое должно пройти между выдачами инструкции заданного типа на данное функциональное устройство.
|
||||
|
||||
**Конвейеризуемые вещественные блоки** - операции, которые могут быть разбиты на стадии и обслуживаться в виде конвейера. Например: сложение и умножение.
|
||||
|
||||
**Неконвейеризуемые блоки** - операции, которые не могут быть разбиты на стадии. Например: деление.
|
||||
|
||||
@ -1,29 +1,25 @@
|
||||
#### Определение динамического планирования. Принципы реализации динамического планирования.
|
||||
|
||||
**Динамическое планирование** (неупорядоченное исполнение, out-of-order execution) - аппаратный механизм переупорядочивания (изменения порядка исполнения инструкций) во время исполнения.
|
||||
|
||||
Не может преодолеть истинные зависимости данных, но пытается сократить или даже предотвратить простои.
|
||||
Позволяет обрабатывать случаи, когда зависимости между инструкциями неизвестны во время компиляции.
|
||||
- Не может преодолеть истинные зависимости данных, но пытается сократить или даже предотвратить простои.
|
||||
- Позволяет обрабатывать случаи, когда зависимости между инструкциями неизвестны во время компиляции.
|
||||
|
||||
**Концепции:**
|
||||
|
||||
- Инструкциям разрешается исполняться неупорядоченно, как только становятся доступны их операнды.
|
||||
- Разрешение инструкциям неупорядоченно завершаться.
|
||||
|
||||
**Реализация динамического планирования:**
|
||||
|
||||
- Ступень декодирования инструкций ID делится на 2 ступени:
|
||||
|
||||
1. **Выдача** - декодирование инструкций, проверка структурных конфликтов. Всегда выполняется в порядке, указанном в программе.
|
||||
Зависимости под данными записываются по мере того, как инструкции выдаются (динамически создается эквивалент графа зависимостей для множества инструкций, которые находятся в ЦП)
|
||||
2. **Чтение операндов** - ожидание разрешения конфликтов данных, если они есть, и последующее чтение операндов по мере их доступности. Может происходить в порядке, отличном от указанного в программе.
|
||||
|
||||
1. **Выдача** - декодирование инструкций, проверка структурных конфликтов. Всегда выполняется в порядке, указанном в программе.
|
||||
|
||||
Зависимости под данными записываются по мере того, как инструкции выдаются (динамически создается эквивалент графа зависимостей для множества инструкций, которые находятся в ЦП)
|
||||
1. **Чтение операндов** - ожидание разрешения конфликтов данных, если они есть, и последующее чтение операндов по мере их доступности. Может происходить в порядке, отличном от указанного в программе.
|
||||
- На ступени выборки инструкции IF производится выборка дополнительной инструкции в специальный регистр или нескольких инструкций в очередь в каждом такте.
|
||||
- Увеличивается число функциональных устройств для исполнения большего числа инструкций на ступени EX без структурных конфликтов.
|
||||
- Два подхода к реализации:
|
||||
|
||||
1) **Табло (Scoreboard)**, 1963.
|
||||
2) **Алгоритм Томасуло**, 1966.
|
||||
1) **Табло (Scoreboard)**, 1963.
|
||||
2) **Алгоритм Томасуло**, 1966.
|
||||
|
||||
Будем считать, что стадия выборки выполняется на соответствующем для нее такте, что конфликтов управления у нас не возникает, что выборка всегда успевает поставить нам очередную инструкцию.
|
||||
Предполагаем, что может быть реализовано несколько исполняющих блоков на стадии исполнения.
|
||||
|
||||
@ -12,23 +12,19 @@
|
||||
- Табло отслеживает статус зависимостей и аппаратных блоков и решает, когда отложенная инструкция может быть направлена на исполнение.
|
||||
- Табло выдает инструкции разрешение для записи результата в регистры.
|
||||
|
||||
**Контролируемые параметры:**
|
||||
|
||||
- **Статус инструкции:**
|
||||
|
||||
На каком из 4 этапов находится.
|
||||
##### Контролируемые параметры:
|
||||
- **Статус инструкции**:
|
||||
На каком из 4 этапов находится.
|
||||
|
||||
- **Статус функционального устройства (9 полей):**
|
||||
|
||||
**Busy** - занято устройство или нет
|
||||
**Op** - Операция, выполняемая на устройстве
|
||||
$F_i$ - регистр назначения
|
||||
$F_j,F_k$ - регистры - источники операндов
|
||||
$Q_j,Q_k$ - функциональные устройства, заполняющие регистры - источники операндов $F_j,F_k$
|
||||
$R_j,R_k$ - флаги, показывающие готовность $F_j,F_k$ :
|
||||
Устанавливаются в True после того, как операнды стали доступны для чтения, затем оба операнда считываются из регистров одновременно.
|
||||
**Busy** - занято устройство или нет
|
||||
**Op** - Операция, выполняемая на устройстве
|
||||
$F_i$ - регистр назначения
|
||||
$F_j,F_k$ - регистры - источники операндов
|
||||
$Q_j,Q_k$ - функциональные устройства, заполняющие регистры - источники операндов $F_j,F_k$
|
||||
$R_j,R_k$ - флаги, показывающие готовность $F_j,F_k$ :
|
||||
Устанавливаются в True после того, как операнды стали доступны для чтения, затем оба операнда считываются из регистров одновременно.
|
||||
|
||||
- **Статус регистра:**
|
||||
|
||||
Какое функциональное устройство собирается писать в регистр (если такое есть)
|
||||
Пуст, когда никакие незаконченные инструкции не будут писать в указанный регистр.
|
||||
Какое функциональное устройство собирается писать в регистр (если такое есть)
|
||||
Пуст, когда никакие незаконченные инструкции не будут писать в указанный регистр.
|
||||
|
||||
@ -2,18 +2,16 @@
|
||||
|
||||
- **Выборка инструкции (IF)** - последовательна.
|
||||
- **Выдача (ID1).** Инструкция выдается, если:
|
||||
- Функциональное устройство для инструкции доступно (нет структурного конфликта).
|
||||
- Регистр назначения для результата инструкции не помечен для записи другой раннее запущенной инструкцией (нет конфликта WAW).
|
||||
- Функциональное устройство для инструкции доступно (нет структурного конфликта).
|
||||
- Регистр назначения для результата инструкции не помечен для записи другой раннее запущенной инструкцией (нет конфликта WAW).
|
||||
- **Чтение операндов (ID2)**
|
||||
- Табло отслеживает доступность операндов.
|
||||
- Когда все операнды доступны, табло указывает функциональному устройству считать все операнды из регистров (пересылка не поддерживается) и начать исполнение.
|
||||
- Таким образом, конфликты RAW разрешаются динамически.
|
||||
|
||||
Между стадией ID2 и EX не может быть простоев. В табло хранится информация кто от кого зависит, и как только необходимые регистры появились, мы их сразу забираем.
|
||||
|
||||
- Табло отслеживает доступность операндов.
|
||||
- Когда все операнды доступны, табло указывает функциональному устройству считать все операнды из регистров (пересылка не поддерживается) и начать исполнение.
|
||||
- Таким образом, конфликты RAW разрешаются динамически.
|
||||
Между стадией ID2 и EX не может быть простоев. В табло хранится информация кто от кого зависит, и как только необходимые регистры появились, мы их сразу забираем.
|
||||
- **Исполнение (EX).** Заменяет EX+MEM в MIPS.
|
||||
- Функциональное устройство начинает исполнение, как только получит операнды.
|
||||
- Когда результаты готовы, оно уведомляет табло.
|
||||
- Функциональное устройство начинает исполнение, как только получит операнды.
|
||||
- Когда результаты готовы, оно уведомляет табло.
|
||||
- **Запись результата (WB)**
|
||||
- Когда табло уведомляется о том, что функциональный блок завершил исполнение, оно выполняет проверку на конфликты WAR и приостанавливает запись результата, если необходимо.
|
||||
- Функциональное устройство помечается как доступное для других инструкций после того, как ступень WB завершена.
|
||||
- Когда табло уведомляется о том, что функциональный блок завершил исполнение, оно выполняет проверку на конфликты WAR и приостанавливает запись результата, если необходимо.
|
||||
- Функциональное устройство помечается как доступное для других инструкций после того, как ступень WB завершена.
|
||||
|
||||
@ -6,18 +6,14 @@
|
||||
Позволяет обрабатывать случаи, когда зависимости между инструкциями неизвестны во время компиляции.
|
||||
|
||||
**Концепции:**
|
||||
|
||||
- Инструкциям разрешается исполняться неупорядоченно, как только становятся доступны их операнды.
|
||||
- Разрешение инструкциям неупорядоченно завершаться.
|
||||
|
||||
**Реализация динамического планирования:**
|
||||
|
||||
- Ступень декодирования инструкций ID делится на 2 ступени:
|
||||
|
||||
1. **Выдача** - декодирование инструкций, проверка структурных конфликтов. Всегда выполняется в порядке, указанном в программе.
|
||||
Зависимости под данными записываются по мере того, как инструкции выдаются (динамически создается эквивалент графа зависимостей для множества инструкций, которые находятся в ЦП)
|
||||
2. **Чтение операндов** - ожидание разрешения конфликтов данных, если они есть, и последующее чтение операндов по мере их доступности. Может происходить в порядке, отличном от указанного в программе.
|
||||
|
||||
1. **Выдача** - декодирование инструкций, проверка структурных конфликтов. Всегда выполняется в порядке, указанном в программе.
|
||||
Зависимости под данными записываются по мере того, как инструкции выдаются (динамически создается эквивалент графа зависимостей для множества инструкций, которые находятся в ЦП)
|
||||
1. **Чтение операндов** - ожидание разрешения конфликтов данных, если они есть, и последующее чтение операндов по мере их доступности. Может происходить в порядке, отличном от указанного в программе.
|
||||
- На ступени выборки инструкции IF производится выборка дополнительной инструкции в специальный регистр или нескольких инструкций в очередь в каждом такте.
|
||||
- Увеличивается число функциональных устройств для исполнения большего числа инструкций на ступени EX без структурных конфликтов.
|
||||
- Два подхода к реализации:
|
||||
|
||||
@ -1,21 +1,19 @@
|
||||
#### Принципы работы алгоритма Томасуло. "Станции резервации"(reservation stations), переименование регистров, общая шина данных (Common Data Bus, CDB). Поля станций резервации.
|
||||
|
||||
**Управление распределено по функциональным устройствам (в Табло - централизовано).**
|
||||
|
||||
- **FU** имеют специальные буферы - **«станции резервации» (Reservation Station)**, которые содержат:
|
||||
**FU** имеют специальные буферы - **«станции резервации» (Reservation Station)**, которые содержат:
|
||||
- Незавершенные инструкции.
|
||||
- Операнды незавершенных инструкций.
|
||||
- Информацию о статусе инструкций (включая зависимости данных).
|
||||
- Станции резервации иногда называют «физическими регистрами» или «переименованными регистрами» в противоположность регистрам архитектуры, заданным в ISA.
|
||||
Регистры ISA в инструкциях заменяются либо их значениями (если доступны), либо указателями на станции резервации, которые предоставят значение позже.
|
||||
- Этот процесс называется **переименованием регистров**.
|
||||
- Переименование регистров исключает конфликты WAR, WAW (зависимости по именам).
|
||||
- Позволяет использовать аппаратное разворачивание циклов.
|
||||
|
||||
- Станций резервации может быть больше, чем регистров ISA, что ведет к аппаратной оптимизации, которая невозможна для компиляторов, а также предотвращает узкое место из-за количества регистров ISA.
|
||||
Регистры ISA в инструкциях заменяются либо их значениями (если доступны), либо указателями на станции резервации, которые предоставят значение позже.
|
||||
|
||||
Этот процесс называется **переименованием регистров**. Переименование регистров исключает конфликты WAR, WAW (зависимости по именам). Позволяет использовать аппаратное разворачивание циклов.
|
||||
|
||||
Станций резервации может быть больше, чем регистров ISA, что ведет к аппаратной оптимизации, которая невозможна для компиляторов, а также предотвращает узкое место из-за количества регистров ISA.
|
||||
|
||||
**Недостатки:**
|
||||
|
||||
- Сложность реализации.
|
||||
- Требуется большое число высокоскоростных ассоциативных портов чтения результатов с CDB.
|
||||
- Производительность может ограничиваться одной CDB.
|
||||
@ -24,28 +22,24 @@
|
||||
|
||||
**Принцип работы:**
|
||||
|
||||
- **Стадия выдачи**
|
||||
1. **Стадия выдачи**
|
||||
Проверяем ожидает ли регистр какое-то значение от RS. Если ожидает - делаем пометку, что мы тоже ожидаем значение от той же RS, что и регистр. Иначе просто копируем значение регистра в аргумент. По итогу у нас либо есть все аргументы, либо мы знаем, от какой RS мы ожидаем аргументы. Потом помечаем, что наша станция busy. В конце помечаем выходной регистр, что он ожидает значения от нашей станции резервации.
|
||||
|
||||
Проверяем ожидает ли регистр какое-то значение от RS. Если ожидает - делаем пометку, что мы тоже ожидаем значение от той же RS, что и регистр. Иначе просто копируем значение регистра в аргумент. По итогу у нас либо есть все аргументы, либо мы знаем, от какой RS мы ожидаем аргументы. Потом помечаем, что наша станция busy. В конце помечаем выходной регистр, что он ожидает значения от нашей станции резервации.
|
||||
2. **Исполнение**
|
||||
Если готовы оба аргумента - начинаем исполнение.
|
||||
|
||||
- **Исполнение**
|
||||
|
||||
Если готовы оба аргумента - начинаем исполнение.
|
||||
|
||||
- **Запись результата**
|
||||
1) Если какой-то регистр ожидает ответа от нашей станции резервации, то записываем результат и помечаем, что регистр больше не ожидает - свободен.
|
||||
2) Всем станциям, которые в качестве параметра ожидали значение от нашей станции - записываем это значение.
|
||||
3) Если ожидала станция сохранения, то записываем
|
||||
4) Помечаем текущую станцию незанятой.
|
||||
3. **Запись результата**
|
||||
1) Если какой-то регистр ожидает ответа от нашей станции резервации, то записываем результат и помечаем, что регистр больше не ожидает - свободен.
|
||||
2) Всем станциям, которые в качестве параметра ожидали значение от нашей станции - записываем это значение.
|
||||
3) Если ожидала станция сохранения, то записываем
|
||||
4) Помечаем текущую станцию незанятой.
|
||||
|
||||
**Общая шина данных (CDB):** данные + адрес назначения (шина «куда)
|
||||
|
||||
- 64 бит для данных + 4 бита для адреса функционального устройства - источника.
|
||||
- данные записываются в ждущую RS, если адрес источника совпадает с адресом RS, которая производит операнд источник.
|
||||
- передача результата происходит через рассылку ждущим RS, включая регистровый файл.
|
||||
|
||||
**Поля станции резервации:**
|
||||
|
||||
- **Busy** - RS занята.
|
||||
- **Op** - операция, выполняемая в устройстве.
|
||||
- $V_j,V_k$ - значения операндов источников S1, S2.
|
||||
|
||||
@ -2,17 +2,16 @@
|
||||
|
||||
- **Выборка (IF)** - обрабатывается последовательно.
|
||||
- **Выдача (ID)** - обрабатывается последовательно.
|
||||
- Получить инструкцию из очереди выбранных инструкций (IQ).
|
||||
- Выдать инструкцию в свободную RS, если нет структурного конфликта.
|
||||
- Пометить выбранную RS как занятую.
|
||||
- Переслать доступные значения операндов инструкции (из регистров ISA) в выбранную RS.
|
||||
- Переименовать еще не доступные операнды в указатели на RS, которые их произведут (переименование регистров, динамическое построение графа зависимостей данных).
|
||||
- Указать для выходного регистра, что он ожидает значение от используемой RS.
|
||||
- Получить инструкцию из очереди выбранных инструкций (IQ).
|
||||
- Выдать инструкцию в свободную RS, если нет структурного конфликта.
|
||||
- Пометить выбранную RS как занятую.
|
||||
- Переслать доступные значения операндов инструкции (из регистров ISA) в выбранную RS.
|
||||
- Переименовать еще не доступные операнды в указатели на RS, которые их произведут (переименование регистров, динамическое построение графа зависимостей данных).
|
||||
- Указать для выходного регистра, что он ожидает значение от используемой RS.
|
||||
- **Исполнение (EX)**
|
||||
- если оба операнда готовы, начинается исполнение на назначенном FU.
|
||||
|
||||
- если не все операнды готовы, следим за CDB в ожидании требуемого результата (через CDB происходит пересылка).
|
||||
т.е. предотвращаем RAW и соблюдаем зависимости по данным.
|
||||
- если оба операнда готовы, начинается исполнение на назначенном FU.
|
||||
- если не все операнды готовы, следим за CDB в ожидании требуемого результата (через CDB происходит пересылка).
|
||||
т.е. предотвращаем RAW и соблюдаем зависимости по данным.
|
||||
- **Запись результата (WB)**
|
||||
- результат выдается на CDB для всех ожидающих RS, т.е результат рассылается по CDB.
|
||||
- станция резервации помечается как свободная.
|
||||
- результат выдается на CDB для всех ожидающих RS, т.е результат рассылается по CDB.
|
||||
- станция резервации помечается как свободная.
|
||||
|
||||
@ -1,6 +1,10 @@
|
||||
#### Определение динамического предсказания ветвлений.
|
||||
|
||||
**Динамическое предсказание ветвлений** - аппаратные схемы, которые динамически предсказывают переходы на основе поведения программы при исполнении, т.е. информация о предыдущих ветвлениях используется, чтобы динамически предсказать исход текущего перехода. ЦП отслеживает выполнение условных переходов в течение работы программы и куда выполнится переход.
|
||||
**Динамическое предсказание ветвлений** - аппаратные схемы, которые динамически предсказывают переходы на основе поведения программы при исполнении, т.е. информация о предыдущих ветвлениях используется, чтобы динамически предсказать исход текущего перехода.
|
||||
|
||||
ЦП отслеживает выполнение условных переходов в течение работы программы и куда выполнится переход.
|
||||
|
||||
Позволяет сократить время простоя за счёт предварительной загрузки и исполнения инструкций, которые должны выполниться после выполнения инструкции условного перехода.
|
||||
|
||||
Прогнозирование ветвлений играет критическую роль, так в большинстве случаев (точность предсказания переходов $\geq 90\%$) позволяет оптимально использовать вычислительные ресурсы процессора.
|
||||
|
||||
|
||||
@ -1,6 +1,7 @@
|
||||
#### Структура ВТВ.
|
||||
|
||||
Эффективное предсказание переходов требует наличие цели перехода на ранней стадии конвейера, можно использовать доп. сумматоры на стадии ID, чтобы цель могла быть выбрана, но будет 1 такт простоя. Проблему решает буфер целей перехода (ВТВ).
|
||||
Эффективное предсказание переходов требует наличие цели перехода на ранней стадии конвейера, можно использовать доп. сумматоры на стадии ID, чтобы цель могла быть выбрана, но будет 1 такт простоя. Проблему решает буфер целей перехода (Branch Target Buffer - ВТВ).
|
||||
|
||||
**ВТВ** - аппаратный механизм, снижающий число тактов простоя при корректно предсказанном переходе до 0.
|
||||
**ВТВ** - буфер целей перехода, доп. набор логики, который располагается на стадии IF и который помогает предсказывать переходы.
|
||||
Цель: переходы без простоев.
|
||||
|
||||
@ -1,26 +1,16 @@
|
||||
#### Алгоритм заполнения и использования ВТВ.
|
||||
|
||||
- **Адрес есть в ВТВ.**
|
||||
|
||||
Берем адрес перехода из буфера. На следующем такте проверяем, выполнился ли переход.
|
||||
|
||||
- **Угадали.**
|
||||
|
||||
Продолжаем выполнение, убираем запись из буфера.
|
||||
|
||||
- **Не угадали.**
|
||||
|
||||
Очищаем эту запись в ВТВ и отбрасываем результаты выполнения.
|
||||
|
||||
Берем адрес перехода из буфера. На следующем такте проверяем, выполнился ли переход.
|
||||
- **Угадали.**
|
||||
Продолжаем выполнение, убираем запись из буфера.
|
||||
- **Не угадали.**
|
||||
Очищаем эту запись в ВТВ и отбрасываем результаты выполнения.
|
||||
- **В таблице ВТВ не нашли наш адрес.**
|
||||
Пытаемся спекулятивно выполнить со следующего адреса.
|
||||
- **Перехода нет**
|
||||
Продолжаем выполнение и результат сохраняется, запись из буфера убирается.
|
||||
- **Переход есть.**
|
||||
Результат отбрасывается, вычисляем новый адрес и на новом такте считываем новый адрес. Информацию о том, что переход состоялся записываем в ВТВ.
|
||||
|
||||
Пытаемся спекулятивно выполнить со следующего адреса.
|
||||
|
||||
- **Перехода нет**
|
||||
|
||||
Продолжаем выполнение и результат сохраняется, запись из буфера убирается.
|
||||
|
||||
- **Переход есть.**
|
||||
|
||||
Результат отбрасывается, вычисляем новый адрес и на новом такте считываем новый адрес. Информацию о том, что переход состоялся записываем в ВТВ.
|
||||
Получается конструкция с запоминанием последнего результата выполнения перехода. Штраф ветвления - 2 такта.
|
||||
|
||||
@ -1,19 +1,18 @@
|
||||
#### Структура РНТ. Алгоритм изменения и использования. Интерференция адресов. Структура ВНТ.
|
||||
#### Структура BНТ. Алгоритм изменения и использования. Интерференция адресов. Структура ВНТ.
|
||||
|
||||
**ВНТ:** Таблица признаков, происходил переход или нет. Хранится выполнение/невыполнение перехода. Берём какое-то число младших бит адреса инструкции, они являются номером записи в ВНТ. Каждая запись ВНТ содержит бит валидности (выполнялось ли ветвление или нет в прошлый раз). Когда мы проверим, выполняется/не выполняется переход, при необходимости обновим запись в ВНТ.
|
||||
|
||||
**ВНТ:** Таблица признаков, происходил переход или нет. Хранится выполнение/невыполнение перехода. Берем какое-то число младших бит адреса инструкции, они являются номером записи в ВНТ. Каждая запись ВНТ содержит бит, индицирующий, выполнялось ли ветвление или нет в прошлый раз. Когда мы проверим, выполняется/не выполняется переход, при необходимости обновим запись в ВНТ.
|
||||
**Простейший метод (одноуровневый):**
|
||||
|
||||
- ВНТ индексируется младшими битами адреса инструкции ветвления.
|
||||
- Каждая запись ВНТ содержит бит индицирующий выполнялось ли ветвление или нет в прошлый раз. 0 - не выполнялось. 1 - выполнялось.
|
||||
- Используемый счетчик (предсказатель) обновляется после обработки инструкции перехода. Увеличить счетчик, если есть переход, уменьшить - если нет перехода.
|
||||
- Каждая запись ВНТ содержит бит валидности выполнялось ли ветвление или нет в прошлый раз. 0 - не выполнялось. 1 - выполнялось.
|
||||
- Используемый счётчик (предсказатель) обновляется после обработки инструкции перехода. Увеличить счётчик, если есть переход, уменьшить - если нет перехода.
|
||||
- Всегда ошибается на первой и последней итерациях цикла.
|
||||
|
||||
**Интерференция** - возникает, когда разные переходы отображаются на один и тот же счетчик (одни и те же младшие биты адреса).
|
||||
Для улучшения точности предсказания используется 2-битовое предсказание:
|
||||
|
||||
- Прогноз должен промахнуться дважды, прежде чем он изменится.
|
||||
Прогноз должен промахнуться дважды, прежде чем он изменится. Поэтому переход в цикле будет предсказан неверно только 1 раз при повторной встрече, вместо 2 раз при 1-битной схеме.
|
||||
|
||||
Поэтому переход в цикле будет предсказан неверно только 1 раз при повторной встрече, вместо 2 раз при 1-битной схеме.
|
||||
**2-битовое предсказание** - частный случай n-битного счетчика с насыщением наращиваемого при выполнении ветвления и уменьшаемого, когда ветвление не выполняется.
|
||||
|
||||
- 2-битовое предсказание - частный случай n-битного счетчика с насыщением наращиваемого при выполнении ветвления и уменьшаемого, когда ветвление не выполняется.
|
||||
- В большинстве случаев используется 2-битный счетчик предсказаний, поскольку наблюдения показывают, что эффективность предсказания 2-битной ВНТ сравнима с эффективностью n-битной.
|
||||
В большинстве случаев используется 2-битный счетчик предсказаний, поскольку наблюдения показывают, что эффективность предсказания 2-битной ВНТ сравнима с эффективностью n-битной.
|
||||
|
||||
@ -1,20 +1,22 @@
|
||||
#### Описание двухуровневого механизма динамического предсказания ветвлений с учетом корреляции.
|
||||
|
||||
Соседние переходы могут коррелировать: поведение недавно выполненных переходов влияет на предсказание текущего перехода.
|
||||
|
||||
Это имеет место в ветвлениях, использованных для реализации конструкций if-then-else.
|
||||
|
||||
Предполагается, что есть 2 уровня предсказаний:
|
||||
|
||||
1) **Глобальный**
|
||||
|
||||
Запись истории поведения m последних переходов как выполнившихся или нет. Обычно используется m -битный регистр сдвига.
|
||||
Запись истории поведения m последних переходов как выполнившихся или нет. Обычно используется m-битный регистр сдвига.
|
||||
|
||||
2) **На один адрес ветвления**
|
||||
$2^m$ таблиц предсказания, каждая запись таблицы - это n-битный счетчик с насыщением.
|
||||
|
||||
Запись истории $1^{го}$ уровня используется для выбора соответствующей из таблиц предсказания $2^{го}$ уровня. Таким образом каждая с $2^m$ таблиц содержит $2^N$ записей и каждая запись - 2-битный (к примеру счетчик).
|
||||
|
||||
Общее количество необходимых для $2^{го}$ уровня бит: $2^m \times n \times 2^N$. n - количество бит, используемое для предсказания.
|
||||
|
||||
- $2^m$ таблиц предсказания, каждая запись таблицы - это n-битный счетчик с насыщением.
|
||||
- Запись истории $1^{го}$ уровня используется для выбора соответствующей из таблиц предсказания $2^{го}$ уровня. Таким образом каждая с $2^m$ таблиц содержит $2^N$ записей и каждая запись - 2-битный (к примеру счетчик).
|
||||
- Общее количество необходимых для $2^{го}$ уровня бит: $2^m \times n \times 2^N$. n - количество бит, используемое для предсказания.
|
||||
**GAp** - Global Adaptive per address.
|
||||
Используется обозначение GAp $(m,n)$, которое означает:
|
||||
Используется обозначение $GAp(m,n)$, которое означает: ^744f75
|
||||
- Записываются последние $m$ ветвлений для выбора между $2^m$ таблицами истории.
|
||||
- Каждая таблица истории $2^{го}$ уровня использует n-битные счетчики (имеет разрядность n бит).
|
||||
- Одноуровневая схема бимодальной ВНТ с 2-битными счетчиками обозначается как предсказатель $(0,2)$
|
||||
|
||||
@ -1,6 +1,9 @@
|
||||
#### Схема MCFarling'a gshare. Преимущества схемы.
|
||||
|
||||
**gshare** = global history with index sharing
|
||||
McFarling предложил использовать и глобальную историю и адрес ветвления, объединяя их хешированием. Функция хеширования: XOR от регистра глобальной истории ветвлений (BHR) и адреса ветвления. Он ожидал, что такой хеш содержит больше информации, чем каждая из компонент. В результате предложенная схема превзошла GAp при малых размерах таблиц.
|
||||
Новая схема обладает меньшими требованиями к оборудованию для реализации по сравнению с GAp, поскольку использует одну общую таблицу предсказателей.
|
||||
|
||||
McFarling предложил использовать и глобальную историю, и адрес ветвления, объединяя их хешированием. Функция хеширования: XOR от регистра глобальной истории ветвлений (BHR) и адреса ветвления. Он ожидал, что такой хеш содержит больше информации, чем каждая из компонентов. В результате предложенная схема превзошла GAp при малых размерах таблиц.
|
||||
|
||||
Новая схема обладает меньшими требованиями к оборудованию для реализации по сравнению с [[2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/2#^744f75|GAp]], поскольку использует одну общую таблицу предсказателей.
|
||||
|
||||
Требуется на k бит истории $2 \times 2^k$ в таблице 2-битных счетчиков.
|
||||
|
||||
@ -1,10 +1,13 @@
|
||||
#### Определение и принцип работы гибридных/турнирных/комбинированных предсказателей.
|
||||
|
||||
**Гибридные (турнирные, комбинированные) предсказатели** - комбинации 2 или более механизмов предсказания переходов.
|
||||
McFarling заметил, что использование глобальной истории поведения переходов может быть менее эффективно, чем просто использование адреса инструкции перехода, особенно для маленьких таблиц предсказателей. McFarling исследовал несколько различных комбинаций 2-х механизмов предсказания переходов.
|
||||
|
||||
McFarling заметил, что использование глобальной истории поведения переходов может быть менее эффективно, чем просто использование адреса инструкции перехода, особенно для маленьких таблиц предсказателей. McFarling исследовал несколько различных комбинаций 2х механизмов предсказания переходов.
|
||||
|
||||
Он предложил использовать дополнительный массив 2-бит счетчиков как селекторов для выбора более эффективной схемы предсказания для каждого перехода.
|
||||
|
||||
1 схема предсказания соответствует 2 большим значениям селектора, другая $-2^{ом}$ меньшим.
|
||||
|
||||
Если $1^{ый}$ предсказатель ошибся, а $2^{ой}$ - нет, счетчик уменьшается.
|
||||
Если $1^{ый}$ предсказатель прав, а $2^{ой}$ - нет, счетчик увеличивается.
|
||||
|
||||
Никаких изменений, если оба оказались правы или ошиблись.
|
||||
@ -1,13 +1,17 @@
|
||||
#### Определение кэша и кэширования. Уровни иерархии памяти.
|
||||
|
||||
**Кэш** - быстродействующая буферная память между CPU и основной памятью, в которую помещаются фрагменты кода и данные, активно используемые программой в текущий момент времени.
|
||||
|
||||
**Кэширование памяти** - временное хранение в более быстрой памяти данных из более медленной памяти.
|
||||
|
||||
Эффективность кэширования основывается на локальности доступа к памяти. Дополнительно может решаться задача снижения требований к пропускной способности основной памяти.
|
||||
Размер кэша меньше, чем размер основной памяти.
|
||||
Кэширование используется на нескольких разных уровнях. С точки зрения процессора, кэш - это механизм устранения задержек. К памяти обращаться долго, но если использовать кэш, то время обращения будет намного меньше.
|
||||
Часто данные одного уровня иерархии являются подмножеством данных нижележащего уровня: данные дублируются в более медленном нижележащем уровне - инклюзивное кэширование.
|
||||
**Иерархия памяти** состоит из нескольких уровней. Меньший по объему, более скоростной уровень памяти расположен ближе к ЦП:
|
||||
|
||||
Кэширование используется на нескольких разных уровнях. С точки зрения процессора, кэш - это механизм устранения задержек. К памяти обращаться долго, но если использовать кэш, то время обращения будет намного меньше.
|
||||
|
||||
Часто данные одного уровня иерархии являются подмножеством данных нижележащего уровня: данные дублируются в более медленном нижележащем уровне - инклюзивное кэширование.
|
||||
|
||||
**Иерархия памяти** состоит из нескольких уровней. Меньший по объему, более скоростной уровень памяти расположен ближе к ЦП:
|
||||
- регистры
|
||||
- основной кэш $(L_1)$
|
||||
- дополнительные вторичные кэши $(L_2,L_3,...)$
|
||||
@ -15,7 +19,6 @@
|
||||
- устройства массового хранения (виртуальная память)
|
||||
|
||||
Или
|
||||
|
||||
- регистры
|
||||
- кэш-память
|
||||
- оперативная память
|
||||
@ -24,7 +27,6 @@
|
||||
|
||||
Каждый уровень проецирует адреса более емкой памяти на менее емкий уровень, ближе к ЦП.
|
||||
Когда для CPU требуется инструкция или операнд, производится поиск по всем уровням иерархии памяти, начиная с ближайшего с CPU (кэш $1^{го}$ уровня):
|
||||
|
||||
- Если элемент найден, он доставляется в ЦП без поиска по нижележащим уровням. Происходит попадание в кэш (частота попаданий $=H_1$).
|
||||
- Если элемент отсутствует в верхнем уровне, происходит кэш-промах, и поиск продолжается на нижестоящем уровне (частота промахов $=1-H_1$).
|
||||
- Для систем с несколькими уровнями кэша, поиск последовательно продолжается на уровнях 2,3, и тд
|
||||
@ -32,6 +34,7 @@
|
||||
|
||||
Взаимодействие «ЦП» $\Rightarrow$ «КЭШ» $\Rightarrow$ «Память» реализовано аппаратно.
|
||||
|
||||
- Если элемент не найден в основной памяти, происходит обращение к диску (вирт. память). Это называется page fault.
|
||||
Взаимодействие «Память» $\Rightarrow$ «Диск» реализовано в ОС при аппаратной поддержке.
|
||||
|
||||
> [!Note]
|
||||
> Если элемент не найден в основной памяти, происходит обращение к диску (вирт. память)
|
||||
|
||||
Взаимодействие "Память $\Rightarrow$ Диск" реализовано в ОС при аппаратной поддержке.
|
||||
@ -1,28 +1,30 @@
|
||||
#### Кэш прямого отображения(Direct mapped cache). Поля строки/блока кэша. Проецирующая функция.
|
||||
|
||||
**Кэш прямого отображения** - стратегия размещения блока основной памяти в кэше, где блок размещается в одном строго определенном месте, определяемом функцией размещения.
|
||||
|
||||
Существует три стратегии размещения или проецирования блока основной памяти в кэш:
|
||||
1. **Direct mapped cache**
|
||||
Строго в одно определенное место, определяемое функцией проецирования: index = (адрес блока) MOD (число блоков в кэше)
|
||||
2. **Fully associative cache**
|
||||
В любом месте (нет проецирующей функции).
|
||||
3. **Set associative cache:**
|
||||
В ограниченном наборе мест. Набор - группа блоков в кэше. Блок проецируется строго на один набор, но он может размещен в любом месте набора. Функция проецирования:
|
||||
|
||||
index = (адрес блока) MOD (число блоков в кэше)
|
||||
|
||||
1) **Direct mapped cache**
|
||||
|
||||
Строго в одно определенное место, определяемое функцией проецирования: index = (адрес блока) MOD (число блоков в кэше)
|
||||
2) **Fully associative cache**
|
||||
|
||||
В любом месте (нет проецирующей функции).
|
||||
3) **Set associative cache:**
|
||||
|
||||
В ограниченном наборе мест. Набор - группа блоков в кэше. Блок проецируется строго на один набор, но он может размещен в любом месте набора. Функция проецирования:
|
||||
index = (адрес блока) MOD (число блоков в кэше)
|
||||
Кэш, имеющий n блоков в наборе называется $n$-канальным наборно-ассоциативным ($n$-way set-associative).
|
||||
**Функция проецирования** - функция, определяющая место размещения данных из основной памяти в кэше.
|
||||
Для любой строки кэша нужно хранить:
|
||||
1) Кэшированные данные.
|
||||
2) **Tag** - адрес оперативной памяти, из которой данные кэшированы. Если адрес совпадает с адресом, к которому мы обратились, значит там наши данные. В противном случае надо читать данные из памяти.
|
||||
3) Бит валидности - признак того, что содержимое записи кэша актуально, т.е строка действительно содержит закэшированные данные.
|
||||
32-битный адрес разбивается на следующие поля:
|
||||
1) Последние 2 бита - биты смещения.
|
||||
|
||||
Относятся к адресации внутри кэш-блока, т.е это внутри блока байты с номерами 0,1,2,3.
|
||||
2) Предыдущие 3 бита - биты, которые были получены от операции:
|
||||
(адрес блока) MOD (число блоков в кэше)
|
||||
3) Все остальное - тег. Возможные адреса блоков, которые могут храниться в конкретной записи в кэше. Если тэг из кэша равен тэгу из адреса, по которому обратились, и бит валидности установлен, то диагностируем попадание и берем данные из кэша.
|
||||
**Функция проецирования** - функция, определяющая место размещения данных из основной памяти в кэше.
|
||||
|
||||
Для любой строки кэша нужно хранить:
|
||||
1. Кэшированные данные.
|
||||
2. Адрес оперативной памяти, из которой данные кэшированы. Если адрес совпадает с адресом, к которому мы обратились, значит там наши данные. В противном случае надо читать данные из памяти.
|
||||
3. Бит валидности - признак того, что содержимое записи кэша актуально, т.е строка действительно содержит закэшированные данные.
|
||||
|
||||
32-битный адрес разбивается на следующие поля:
|
||||
1. Последние 2 бита - биты смещения.
|
||||
Относятся к адресации внутри кэш-блока, т.е это внутри блока байты с номерами 0,1,2,3.
|
||||
2. Предыдущие 3 бита - биты, которые были получены от операции:
|
||||
(адрес блока) MOD (число блоков в кэше)
|
||||
3. Все остальное - тег.
|
||||
Возможные адреса блоков, которые могут храниться в конкретной записи в кэше. Если тэг из кэша равен тэгу из адреса, по которому обратились, и бит валидности установлен, то диагностируем попадание и берем данные из кэша.
|
||||
|
||||
@ -1,13 +1,10 @@
|
||||
#### Список метрик производительности
|
||||
|
||||
1. **Физические характеристики (тактовая частота)**
|
||||
2. **Теоретически посчитанные характеристики (мегабайты в секунду)**
|
||||
3. **Характеристики, связанные с производительностью (MIPS, GFLOPS)**
|
||||
|
||||
**MIPS (Million Instructions Per Second)**
|
||||
- Миллионы инструкций в секунду.
|
||||
- Оценка MIPS = $\frac{\text{частота}}{\text{CPI} \times 10^6}$.
|
||||
|
||||
**GFLOPS (Billion FLOating-Point operation Per Second)**
|
||||
- Миллиард операций с плавающей точкой.
|
||||
- Оценка $$GFLOPS = \frac{\text{число floating-point операций}}{\text{время выполнения} \times 10^9}$$
|
||||
1. Физические характеристики (тактовая частота)
|
||||
2. Теоретически посчитанные характеристики (мегабайты в секунду)
|
||||
3. Характеристики, связанные с производительностью (MIPS, GFLOPS)
|
||||
- MIPS (Million Instructions Per Second)
|
||||
- Миллионы инструкций в секунду.
|
||||
- Оценка MIPS = $\frac{\text{частота}}{\text{CPI} \times 10^6}$.
|
||||
- GFLOPS (Billion FLOating-Point operation Per Second)
|
||||
- Миллиард операций с плавающей точкой.
|
||||
- Оценка $$GFLOPS = \frac{\text{число floating-point операций}}{\text{время выполнения} \times 10^9}$$
|
||||
@ -20,7 +20,7 @@
|
||||
- ADD R1, [R2+R3], R1.
|
||||
|
||||
7. **Косвенный в памяти**
|
||||
- ADD R1, [[R2]], R1.
|
||||
- ADD R1, \[\[R2\]\], R1.
|
||||
|
||||
8. **Автоинкремент, автодекремент**
|
||||
- ADD R1, [R2++], R1.
|
||||
|
||||
200
2 курс/2 семестр/Операционные системы/Введение.md
Normal file
200
2 курс/2 семестр/Операционные системы/Введение.md
Normal file
@ -0,0 +1,200 @@
|
||||
**Операционная система** - программное обеспечение, управляющее аппаратными ресурсами и предоставляющее прикладным программам удобные абстракции ^bd03ae
|
||||
- Как *менеджер ресурсов* - управляет ресурсами, отслеживая их состояние и планируя их использование.
|
||||
Виды ресурсов:
|
||||
- вычислительные ресурсы (ЦП)
|
||||
- оперативная память и уст-ва долговременного хранения данных (жесткий диск и т.д.)
|
||||
- устройства ввода/вывода
|
||||
- сетевые соединения
|
||||
- Как *виртуальная машина* - выполняет абстрагирование аппаратного обеспечения до уровня логических ресурсов ОС с четко определенными интерфейсами. Поддерживает абстракции, которых не существует на аппаратном уровне.
|
||||
- Аппаратные ресурсы - абстракции ОС
|
||||
- Жёсткий диск - ФС
|
||||
- Принтеры - очередь печати
|
||||
- ЦП - поток
|
||||
- ОЗУ - процесс
|
||||
|
||||
[[#^bd03ae|ОС]] формирует **операционную среду** - среду выполнения ПО
|
||||
Условия выполнения программ: ^ed3cc0
|
||||
- Мн. команд ЦП, доступное ПО
|
||||
- Мн. сис. функ. ОС, доступное ПО
|
||||
- Тип и структура ВАП (Виртуальное Адресное Пространство) ПО, использующей модель адресации
|
||||
|
||||
**Spool** - одновременное выполнение нескольких операций в переферии
|
||||
|
||||
**Многозадачность** - свойство ОС, позволяющее обрабатывать несколько задач параллельно.
|
||||
|
||||
В ОЗУ загружаются несколько процессов. IO одного процесса выполняется параллельно с вычислениями другой
|
||||
Цель - оптимизация пропускной способности системы
|
||||
|
||||
**ОС разделения времени** - подход, который требуется для интерактивной работы, при котором у одной ЭВМ несколько терминалов и каждый пользователь считает, что ему польностью выделена вычислительная система
|
||||
Для её реализации, была создана идея разделения времени - *Timeslicing*. Задачи:
|
||||
- Распределение времени ЦП равномерно между пользователями
|
||||
- Если задача интерактивная, нужно переключаться между пользователями и ПО быстрее, чем пользователи производят ввод
|
||||
- Пользователи могут интерактивно просматривать, редактировать и отдаэивать выполняющиеся программы
|
||||
|
||||
Классификация ОС по назначению:
|
||||
- Системы пакетной обработки (максимальная пропускная способность)
|
||||
- Системы разделения времени (удобство и эффективность работы пользователя)
|
||||
- ОС реального времени (способность выдерживать заданные интервалы времени между возникновением события и завершения его обработки)
|
||||
|
||||
По режиму обработки задач:
|
||||
- По поддержке многозадачности
|
||||
- однозадачные
|
||||
- многозадачные
|
||||
- По поддержке многопоточности
|
||||
- По поддержке многопроцессорной обработки
|
||||
|
||||
По организации пользовательской работы
|
||||
- Однопользовательские и многопользовательские
|
||||
- Односессионные и многосессионные
|
||||
|
||||
**Монолитная архитектура ОС** - система, построенная с помощью монолитного ядра
|
||||
**Монолитное ядро** - множество процедур, которые
|
||||
- выполняются на одном уровне привелегий
|
||||
- используют одно множество данных
|
||||
- вызывают друг друга непосредственно (без спец. механизмов)
|
||||
|
||||
**Многослойная (уровневая) архитектура ОС** - ОС разбивается на несколько компонентов, между которыми выстраивается вертикальная архитектура (каждый компонент может взаимодействовать только со своими соседями)
|
||||
|
||||
**Микроядерная архитектура ОС** - архитектура, основная идея которой минимизация объёма кода, выполняющегося на уровне ядра. На микроядре реализуют минимальный функционал ОС. Всё остальное - прикладные программы
|
||||
*Плюсы*:
|
||||
- понятная архитектура
|
||||
- устойчивая система
|
||||
- возможность скомпоновать ОС под определённые нужны
|
||||
|
||||
*Минусы*:
|
||||
- низкая производительность
|
||||
- медленная работа из-за переходов между компонентами через ядро
|
||||
|
||||
**Архитектура, основанная на ВМ** - архитектура, основная идея которой является то, что ОС поддерживает отдельные копии [[#^ed3cc0|операционных сред]] для разных работающих приложений (для разделение работы)
|
||||
Позже появилась поддержка аппаратного виртуального обеспечения, которое произволится с помощью специального ПО
|
||||
*Плюсы*:
|
||||
- падение одного приложение не повлечёт отказ остальных
|
||||
*Минусы*:
|
||||
- низкая производительность реальной ОС при IO-операциях
|
||||
|
||||
**Паравиртуализация** - идея, суть которой в том, что при выполнении некоторого набора операций ОС, работающая на ВМ, напрямую вызывает хостовую ОС, которая работает с реальным аппаратным обеспечением
|
||||
*Ограничение*: хостовая и гостевая ОС должны быть одинаковыми
|
||||
|
||||
**Расширяемость** - возможность модификации, ничего не сломав (модульность, объектная и микроядерная архитектура)
|
||||
|
||||
**Переносимость** - возможность переноса кода на другую аппаратную платформу. Повысить переносимость можно:
|
||||
- использовав ЯВУ
|
||||
- оптимизировав код
|
||||
- локализировав и изолировав код
|
||||
|
||||
**Совместимость** - способность выполнять программы, написанные для других ОС (или более старых версий себя), а также другой архитектуры
|
||||
|
||||
**Безопасность** - защиты ресурсов пользователей друг от друга. Категории:
|
||||
- D - нет требований
|
||||
- C - наличие подсистемы учёта событий безопасности
|
||||
- C2 = есть средство входа, права к объектам, аудит безопасности, защита памяти
|
||||
- B - использование помеченных данных и распределение пользователей по категориям
|
||||
- A - наличие формального доказательства соответствия системы требованиям безопасности
|
||||
|
||||
**Windows NT**
|
||||
*Уровень аппаратной абстракции* - обеспечивает вышележащим уровням приемлимые абстракции hardware
|
||||
*Ядро* - планирование, обработка прерываний и исключений, многопроцессорность, обработка сбоев
|
||||
*Менеджер объектов* - создаёт, удаляет и управляет объектами (выделение памяти, управление дескрипторами, каталогами объектов)
|
||||
*Монитор безопасности* - устанавливает правила защиты на локальный компьютер
|
||||
*Менеджер процессор* - управляет процессами и потоками
|
||||
*Средства LPC* - оптимизированный вариант более общего средства - удалённого вызова процедур (передача коротких и длинных сообщений)
|
||||
*Менеджер виртуальной памяти* - управление физической памятью, поддержка АП ядра и процессов
|
||||
*Менеджер IO* - представляет средства IO, независимо от их устройств
|
||||
|
||||
**UNIX**
|
||||
*Аппаратный контроль* - обеспечивает вышележащим уровням приемлимые абстракции hardware
|
||||
*Взаимодействие процессов* - реализация механизмов IPC
|
||||
*Планировщик* - управление (распределение) временем ЦП
|
||||
*Управление памятью* - управление физической памятью, поддержка АП ядра и процессов
|
||||
|
||||
**Поток** - абстракция: последовательное выполнение команд программы во времени ^308759
|
||||
|
||||
Совместно используют глобальные и статические переменные, динамическую память и системные ресурсы, выданную [[#^c7de0d|процессу]]
|
||||
Имеет собственные счётчик (IP), значения регистров и локальные переменные
|
||||
|
||||
|
||||
**Процесс** - абстракция: программа во время выполнения; совокупность потоков и ресурсов ^c7de0d
|
||||
|
||||
ОС выделяет процессу ресурсы:
|
||||
- Адресное пространство
|
||||
- Файлы
|
||||
- IO
|
||||
|
||||
**Многопоточные процессы** - процессы с несколькими потоками
|
||||
|
||||
**Контекст** - множество информации, полностью описывающее состояние состояние объекта
|
||||
*Контекст [[#^c7de0d|процесса]]*:
|
||||
- Информация о процессе
|
||||
- АП процесса
|
||||
- Структура и содержимое пользовательской части АП процесса
|
||||
- Множество ресурсов, выделенных процессу, и их состояние
|
||||
|
||||
*Контекст [[#^308759|потока]]*:
|
||||
- Информация о потоке
|
||||
- Множество ресурсов, выделенных потоку, и их состояние
|
||||
- Аппаратные контекст исполнения потока
|
||||
|
||||
**Переключение контекста** происходит при переходе к исполнению другого потока
|
||||
|
||||
При переключении необходимо:
|
||||
1. Сохранить контекст текущего потока
|
||||
2. Если следующий поток принадлежит другому процессу:
|
||||
1. Сохранить контекст текущего процесса
|
||||
2. Загрузить контекст следующего процесса
|
||||
3. Загрузить контекст следующего потока
|
||||
|
||||
**Диаграмма состояний потока в однозадачной среде**
|
||||
*Создание* - ОС обслуживает запрос на создание потока
|
||||
*Завершение* - ОС обслуживает запрос на завершение потока
|
||||
*Выполнение* - состояние работающего потока, выполняющегося на ЦП
|
||||
*Ожидание* - выполнение потока заблокировано до наступление некого внешнего события
|
||||
|
||||
**Диаграмма состояний потока во многозадачной среде**
|
||||
*Выполнение* - состояние работающего потока, обладающими всеми необходимыми ресурсами, в т.ч. возможностью использования ЦП
|
||||
*Готов к выполнению* - поток обладает всеми нелюходимыми для выполнения ресурсами, кроме времени ЦП
|
||||
|
||||
**Дескриптор [[#^c7de0d|процесса]]** - структура данных, которая используется для описания процесса Включает в себя: ^6b0413
|
||||
- Идентификатор процесса
|
||||
- Групповые параметры процесса
|
||||
- Состояние процесса
|
||||
- Статистические данные
|
||||
- Описание АП процесса
|
||||
- Контекст IO
|
||||
- Контекст безопасности
|
||||
- Текущие системные параметры выполнения
|
||||
- Код завершения процесса
|
||||
- Параметры, используемые в случае конкуренции между процессами за ресурс для определения приоритета
|
||||
|
||||
**Дескриптор [[#^308759|потока]]** - структура данных, которая используется для описания процесса. Включает в себя:
|
||||
- Идентификатор потока
|
||||
- Идентификатор владельца - процесса
|
||||
- Параметры, используемые в случае конкуренции между потоками за ресурс для определения приоритета
|
||||
- Статистические данные
|
||||
- Аппаратные контекст выполнения потока
|
||||
- Код завершения потока
|
||||
|
||||
**Создание процесса в Windows**
|
||||
1. Создание и инициализация (всех полей) дескриптора
|
||||
2. Создание и заполнение необходимыми данными ВАП
|
||||
3. Выделение ресурсов, которые он может использовать сразу после создания
|
||||
4. Оповещение подсистем, занимающимися управлением процессов, о создании нового процесса
|
||||
5. Создание первичного потока
|
||||
|
||||
**Завершение процесса в Windows**
|
||||
1. Завершение выполнения всех потоков процесса
|
||||
2. Сохранение статистических данных и кода возврата процессора в дескрипторе
|
||||
3. Перевод всех ресурсов, принадлежащих процессу, в стабильное и непротиворечивое состояние
|
||||
4. Освобождение этих ресурсов
|
||||
5. Освобождение ВАП, а затем его уничтожение
|
||||
6. Оповещение подсистем, занимающимися управлением процессов, о завершении процесса
|
||||
7. Установка состояние процесса `завершён`
|
||||
Остаётся только [[#^6b0413|дескриптор]]. Его уничтожение зависит от реализации
|
||||
|
||||
**Создание потока в Windows**
|
||||
1. Создание и инициализация (всех полей) дескриптора
|
||||
2. Создание структур данных, необходимых потоку
|
||||
3. Инициализация аппаратного контекста
|
||||
4. Оповещение подсистем, занимающимися управлением потоков, о создании нового потока
|
||||
5. Установка состояние потока `готов к исполнению`
|
||||
|
||||
**Завершение потока в Windows**
|
||||
Reference in New Issue
Block a user