Arch: chore
This commit is contained in:
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}}"
|
||||
}
|
||||
}
|
45501
.obsidian/plugins/obsidian-git/main.js
vendored
45501
.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);
|
||||
}
|
||||
|
9997
.obsidian/plugins/obsidian-style-settings/main.js
vendored
9997
.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. **Выдача** - декодирование инструкций, проверка структурных конфликтов. Всегда выполняется в порядке, указанном в программе.
|
||||
|
||||
1. **Выдача** - декодирование инструкций, проверка структурных конфликтов. Всегда выполняется в порядке, указанном в программе.
|
||||
Зависимости под данными записываются по мере того, как инструкции выдаются (динамически создается эквивалент графа зависимостей для множества инструкций, которые находятся в ЦП)
|
||||
2. **Чтение операндов** - ожидание разрешения конфликтов данных, если они есть, и последующее чтение операндов по мере их доступности. Может происходить в порядке, отличном от указанного в программе.
|
||||
|
||||
Зависимости под данными записываются по мере того, как инструкции выдаются (динамически создается эквивалент графа зависимостей для множества инструкций, которые находятся в ЦП)
|
||||
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:**
|
||||
В ограниченном наборе мест. Набор - группа блоков в кэше. Блок проецируется строго на один набор, но он может размещен в любом месте набора. Функция проецирования:
|
||||
|
||||
1) **Direct mapped cache**
|
||||
index = (адрес блока) MOD (число блоков в кэше)
|
||||
|
||||
Строго в одно определенное место, определяемое функцией проецирования: 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.
|
||||
|
Reference in New Issue
Block a user