diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Задачи.md b/2 курс/1 семестр/Архитектура ЭВМ/Задачи.md new file mode 100644 index 0000000..a437e17 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Задачи.md @@ -0,0 +1,5 @@ +Задача 1. Напишите на C и псевдоассемблере код, решающий некоторую задачу. +Задача 2. Нарисуйте изменение стека при работе заданной программы. +Задача 3. Для конвейера с указанными характеристиками рассчитайте время выполнения программы. (Возможное доп. задание: предложите более производительный вариант программы). +Задача 4. Сформируйте потактовую диаграмму выполнения заданной программы на конвейере с указанными характеристиками. +Задача 5. Сформируйте потактовую диаграмму выполнения заданной программы на конвейере, использующем Табло или алгоритм Томасуло. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/1.md new file mode 100644 index 0000000..6e5ff08 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/1.md @@ -0,0 +1,30 @@ +# Уровни абстракции электронной вычислительной системы. Фон Неймановская модель компьютера. + +#### Уровни абстракции + +1. **Физика (электроны)** + - Поведение электронов описывается квантовой механикой и системой уравнений Максвелла. + +2. **Полупроводниковые устройства (транзисторы, диоды и т.д.)** + - Каждое устройство имеет четко определенные точки соединения с другими подобными устройствами - контакты. + +3. **Аналоговые схемы** + - Полупроводниковые устройства соединены в функциональные компоненты (усилители и фильтры). Переход на аналоговом уровне занимает время, что сказывается на скорости выполнения вычислений (время такта). + +4. **Цифровые схемы** + - С помощью дополнительного уровня абстракции вводятся новые понятия (хранения бит) и новые операции над ними. + +5. **Логические элементы (сумматоры, арифметико-логические устройства)** + - Предназначены для обработки информации в цифровой форме. Если есть 4 вещи: хранение, конъюнкция, дизъюнкция, отрицание, то можно реализовать компьютер. На практике хватает «не и». + +6. **Микроархитектура** + - Есть требования по ресурсам процессора, командам процессора. Разработчики архитектуры должны собрать процессор под эти требования. Микроархитектура - соединение простейших цифровых элементов в логические блоки, предназначенные для выполнения команд, определенных какой-либо архитектурой. + +7. **Архитектура (инструкции, регистры)** + - Описывает компьютер с точки зрения программиста. В архитектуре описываются модель процессора, его характеристики (сколько регистров, какие операции позволяются, сколько памяти он может адресовать) и функциональные возможности (контракт между разработчиками ПО и разработчиками аппаратного обеспечения). + +8. **Операционная система** + - Управляет операциями нижнего уровня, такими как: доступ к жесткому диску или управление памятью. + +9. **Программное обеспечение** + - Использует ресурсы аппаратуры и ОС для разрешения конкретных задач пользователя. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/2.md new file mode 100644 index 0000000..058708d --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/2.md @@ -0,0 +1,31 @@ +# Фон Неймановская модель компьютера + +**Принципы фон Неймана:** + +1. **Принцип однородности памяти** + - В любой ячейке памяти может храниться как элемент данных, так и элемент программы. Нельзя определить тип данных в ячейке по содержимому. + +2. **Принцип адресности** + - Вся память является адресуемой. Нулевая ячейка имеет уникальный адрес. + +3. **Принцип программного управления** + - Ход вычисления определяется программой, сохраненной в памяти. + +4. **Принцип двоичного кодирования** + - Код программы и данные закодированы в двоичном виде. + +**Фон Неймановская модель компьютера:** + +![Фон Неймановская модель компьютера](../data/1.png) + +**Компоненты:** + +- **Центральный обрабатывающий блок (CPU):** + - **Блок управления (Control Unit):** Декодирование инструкций, порядок операций. + - **Тракт данных (Datapath):** Регистры, арифметико-логическое устройство, шины. + +- **Память (Memory):** Хранение инструкций и их операндов. + +- **Подсистема ввода/вывода (I/O Devices):** Шина I/O, интерфейсы, устройства. + +**Концепция хранения программ:** Инструкции из набора команд выбираются из общей памяти и исполняются последовательно. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/3.md new file mode 100644 index 0000000..56da605 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/3.md @@ -0,0 +1,18 @@ +# Шаги обработки инструкций в CPU + +1. **Выборка инструкции** + - Выбрать инструкцию программы из памяти. Программный счетчик (Program Counter, PC / Instruction Pointer, IP) указывает на следующую для обработки инструкцию. + +2. **Декодирование инструкции** + - Определить требуемые действия и размер инструкции. + +3. **Выборка операндов** + - Найти и получить данные операндов. + +4. **Исполнение** + - Вычислить значение результата или статус. + +5. **Сохранение результата** + - Записать результаты в запоминающее устройство для последующего использования. + +![Шаги обработки инструкций в CPU](../data/2.png) diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/1.md new file mode 100644 index 0000000..38d1bf5 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/1.md @@ -0,0 +1,12 @@ +#### Определение параллелизма уровня инструкций (ILP). Определение базового блока инструкций. + +**Параллелизм уровня инструкций (ILP)** - возможность одновременного выполнения нескольких инструкций в конвейере ЦП. + +ILP существует, когда инструкции в последовательности независимы и поэтому могут исполняться параллельно (с перекрытием). Конвейеры с большим ILP (меньшим числом зависимостей) показывают лучшую производительность на CPU с конвейером. +**Базовый блок инструкций** - линейная последовательность инструкций без переходов внутрь, за исключением точки входа, и без переходов наружу, за исключением точки выхода из последовательности. Пример: тело цикла. + +- ILP в базовом блоке определяется имеющимися зависимостями между инструкциями и размером блока. +- В типичном целочисленном коде частота условных переходов около $15\%$, что дает средний размер базового блока - 7 инструкций. +- Любой статический метод, увеличивающий размер базового блока, расширяет блок инструкций для оптимального статического планирования конвейера компилятором и увеличивает ILP. +Один из таких методов - разворачивание цикла. +**Статический метод** - метод, который не имеет доступа к полям объекта, и для вызова такого метода не нужно создавать экземпляр класса, в котором он объявлен. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/2.md new file mode 100644 index 0000000..176ed18 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/2.md @@ -0,0 +1,20 @@ +#### Статическая оптимизация с разворачиванием циклов. Требования к разворачиванию циклов. + +**Стандартный способ увеличения ILP** состоит в использовании параллелизма между итерациями цикла, т.е параллелизма уровня цикла (Loop Level Parallelism, LLP) +Достигается путем разворачивания цикла, либо статически компилятором, либо динамически аппаратурой, чтобы увеличить размер имеющегося базового блока; +Больший размер базового блока позволяет удалить больше тактов простоя, тк больше инструкций могут переупорядочиваться. + +- **Статическая оптимизация с разворачиванием цикла.** + +Реализуется компилятором, но приводит к изменению кода на языке высокого уровня. +Пример: был цикл от 1 до 100 с шагом 1. Теперь делаем цикл от 1 до 100 с шагом 4 и на каждой итерации выполняем последовательно 4 тела цикла. Увеличивается размер базового блока, что позволяет удалить больше тактов простоя, тк инструкции могут переупорядочиваться. + +- **Разворачивание циклов.** + +Больший размер базового блока - больше инструкций для перепланирования. +Исполняется меньше инструкций переходов и инструкций для поддержки циклов. +Разворачивание циклов еще эффективнее при реализации векторных команд. +**Необходимые требования для разворачивания цикла:** + +- Независимость итераций цикла. +- Большое количество регистров для предотвращения конфликтов по именам регистров (WAR, WAW). \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/3.md new file mode 100644 index 0000000..743911f --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/3.md @@ -0,0 +1,43 @@ +#### Пример разворачивания цикла. + +```assembly +for (i = 1000; i>0; i = i-1) + x[i]= x[i] + s; +Без оптимизации: +Loop: LD [R1], F0 1 + простой 2 + ADD F2, F0, F4 3 + простой 4 + простой 5 + ST F4, [R1] 6 + ADD R1, R3, R1 7 + простой 8 + BNE R1, R2, Loop 9 + простой 10 +``` + +- 4 копии цикла развернуты без повторного использования регистров. +- Размер базового блока увеличен с 5 до 14 инструкций. +- 3 перехода и 3 уменьшения R1 удалены. +- Адреса загрузки и сохранения изменены. +- 7 тактов для исходной итерации. + +Разворачивание цикла сразу с оптимизацией: + +| Loop: | LD [R1], F0 | 1 | +| :--: | :--: | :--: | +| | LD [R1-8], F6 | 2 | +| | LD [R1-16], F10 | 3 | +| | LD [R1-24], F14 | 4 | +| | ADD F2, F0, F4 | 5 | +| | ADD F2, F6, F8 | 6 | +| | ADD F2, F10, F12 | 7 | +| | ADD F2, F14, F16 | 8 | +| | ST F4, [R1] | 9 | +| | ST F8, [R1-8] | 10 | +| | ADD R1, R3, R1; | R3 -=32; 11 | +| | ST F12, [R1+16] | 12 | +| | BNE R1, R2, Loop | 13 | +| | ST F16, [R1+8]; | 8-32 = -24 | + +Время итерации цикла сократилось до 14 тактов или $\frac{14}{4}=3.5$ для исходной итерации; Ускорение $\frac{6}{3.5}=1.7$ \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/1.md new file mode 100644 index 0000000..23f1d20 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/1.md @@ -0,0 +1,4 @@ +#### Классификация зависимостей между инструкциями (по данным, по именам, по управлению). + +Зависимые инструкции не являются параллельными и не могут быть переупорядочены ни компилятором, ни аппаратурой. +Зависимости между инструкциями классифицируются как: зависимости по данным, зависимости по именам, зависимости по управлению. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/2.md new file mode 100644 index 0000000..a309da2 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/2.md @@ -0,0 +1,44 @@ +#### Истинная зависимость по данным, антизависимость, выходная зависимость. Граф зависимостей. + +Пусть есть 2 инструкции $i$, $j$. где $i$ предшествует $j$ в программе. + +- **Инструкция $j$ зависит по данным от инструкции $i$, если:** +- $i$ выдает результат, используемый $j$ (конфликт RAW), если порядок выполнения не сохраняется. +- $j$ зависит по данным от $k$ и $k$ зависит по данным от $i$ (цепочка конфликтов RAW). + +**Пример зависимости по данным:** +```assembly +Loop: LD [R1], F0 +DADD F2, F0, F4 +ST F4, [R1] +``` + +**Зависимость по именам** возникает, когда 2 инструкции используют один и тот же регистр или место в памяти, т.е. общее имя места. +Между инструкциями, имеющими зависимость по именам, нет потока данных (нет отношения выдает/использует). +Может существовать два типа зависимостей по именам: + +- **Антизависимость.** +- Существует, когда $j$ пишет в тот же регистр или место в памяти, которое $i$ читает. + +Нарушение антизависимости (относительный порядок чтения/записи изменен): приводит к конфликту WAR и потому относительный порядок чтения/записи и исполнения должен сохраняться. +$i$ считывает значение по имени, $j$ записывает значение по тому же имени. $j$ антизависима от $i$. +Изменение относительного порядка исполнения $i$, $j$ нарушает эту зависимость по именам и приводит к конфликту WAR и некорректному исполнению. + +- **Выходная зависимость (зависимость записи).** +- Существует, когда $i$ и $j$ пишут в один и тот же регистр или место в памяти. + +Нарушение выходной зависимости (относительный порядок записи изменен): приводит к конфликту WAW и потому порядок записи и исполнения должен сохраняться. +$i$, $j$ пишут по одинаковому имени. Тогда $j$ зависима по выходу от $i$. +Изменение относительного порядка исполнения $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] +``` + +В графе можем переупорядочивать инструкции только если сохраняется порядок стрелок. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/3.md new file mode 100644 index 0000000..9cb2af3 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/3.md @@ -0,0 +1,17 @@ +#### Зависимость по управлению. + +Определяют порядок инструкции с учетом инструкций перехода. +Каждая инструкция в программе кроме тех, которые находятся в самом первом базовом блоке программы, зависима по управлению от некоторого множества переходов. +Инструкцию, зависимую по управлению от перехода нельзя переместить перед переходом так, что ее исполнение более не будет управляться переходом. +Инструкцию, не зависимую по управлению от перехода нельзя переместить так, что ее исполнение будет управляться переходом (в часть then). +В некоторых случаях возможно обойти эти ограничения и сохранить корректное исполнение. + +**Пример зависимости:** +```c +if p1{ +s1; s1 зависима по управлению от p1. s2 зависима по управлению от p2, но не от p1. +} +if p2{ +s2; +} +``` \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/1.md new file mode 100644 index 0000000..e1f98d7 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/1.md @@ -0,0 +1,7 @@ +#### Отличия от конвейера без обработки вещественных операций. + +Инструкции с плавающей точкой выполняются на том же конвейере, что и целочисленные со следующими отличиями: + +- стадия EX может повторяться столько раз, сколько потребуется. +- может быть несколько FP функциональных устройств. +- простои возникают, если выпускаемая инструкция вызывает структурный конфликт в функциональном устройстве или конфликт данных. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/2.md new file mode 100644 index 0000000..37d5905 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/2.md @@ -0,0 +1,7 @@ +#### Определения задержки и периода запуска. Конвейеризуемые и неконвейеризуемые функциональные блоки. + +**Задержка функциональных устройств** - количество тактов между инструкцией, производящей результат и инструкцией, которая его использует. Обычно равно числу тактов простоя при использовании пересылки. +**Период запуска или интервал повтора** - число тактов, которое должно пройти между выдачами инструкции заданного типа на данное функциональное устройство. + +**Конвейеризуемые вещественные блоки** - операции, которые могут быть разбиты на стадии и обслуживаться в виде конвейера. Например: сложение и умножение. +**Неконвейеризуемые блоки** - операции, которые не могут быть разбиты на стадии. Например: деление. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/3.md new file mode 100644 index 0000000..5efa6bb --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/3.md @@ -0,0 +1,9 @@ +#### Характеристики конвейера с поддержкой вещественных операций. + +- Инструкции обрабатываются упорядоченно на стадиях IF, ID, EX - одна инструкция за такт. +- Простои из-за конфликта RAW растут (в тактах) в силу более долгих FP задержек. +- Структурные конфликты возможны в силу различного времени выполнения инструкций и FP задержек. Блок FP может быть занят (блок деления). +Ступени MEM, WB достигаются несколькими инструкциями одновременно. +- Могут возникать конфликты WAW, так как инструкции могут достичь WB в порядке, отличном от исходного. +- Конфликты WAR невозможны, так как чтение регистров происходит упорядоченно на стадии ID. +- Внеочередное завершение инструкций требует специальных мер для обеспечения точных исключений. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/1.md new file mode 100644 index 0000000..aafa433 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/1.md @@ -0,0 +1,29 @@ +#### Определение динамического планирования. Принципы реализации динамического планирования. + +**Динамическое планирование** (неупорядоченное исполнение, out-of-order execution) - аппаратный механизм переупорядочивания (изменения порядка исполнения инструкций) во время исполнения. + +Не может преодолеть истинные зависимости данных, но пытается сократить или даже предотвратить простои. +Позволяет обрабатывать случаи, когда зависимости между инструкциями неизвестны во время компиляции. + +**Концепции:** + +- Инструкциям разрешается исполняться неупорядоченно, как только становятся доступны их операнды. +- Разрешение инструкциям неупорядоченно завершаться. + +**Реализация динамического планирования:** + +- Ступень декодирования инструкций ID делится на 2 ступени: + +1. **Выдача** - декодирование инструкций, проверка структурных конфликтов. Всегда выполняется в порядке, указанном в программе. +Зависимости под данными записываются по мере того, как инструкции выдаются (динамически создается эквивалент графа зависимостей для множества инструкций, которые находятся в ЦП) +2. **Чтение операндов** - ожидание разрешения конфликтов данных, если они есть, и последующее чтение операндов по мере их доступности. Может происходить в порядке, отличном от указанного в программе. + +- На ступени выборки инструкции IF производится выборка дополнительной инструкции в специальный регистр или нескольких инструкций в очередь в каждом такте. +- Увеличивается число функциональных устройств для исполнения большего числа инструкций на ступени EX без структурных конфликтов. +- Два подхода к реализации: + +1) **Табло (Scoreboard)**, 1963. +2) **Алгоритм Томасуло**, 1966. + +Будем считать, что стадия выборки выполняется на соответствующем для нее такте, что конфликтов управления у нас не возникает, что выборка всегда успевает поставить нам очередную инструкцию. +Предполагаем, что может быть реализовано несколько исполняющих блоков на стадии исполнения. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/2.md new file mode 100644 index 0000000..dcb9345 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/2.md @@ -0,0 +1,34 @@ +#### Определение табло. Структура табло и контролируемые параметры. + +**Табло** - централизованный аппаратный механизм, поддерживающий скорость выдачи инструкций на исполнение не более 1 за такт, за счет выдачи инструкции, как только ее операнды доступны и нет блокирующих ее конфликтов. + +- Ступень ID заменяется на ID1, ID2. +- Однопортовый (1 инструкция - 1 такт) неупорядоченный конвейер без изменений на ступени выборки инструкции (IF). +- Смысл алгоритма Табло в том, что внутри ЦП есть отдельный блок, который хранит информацию о всех текущих выполняющихся инструкциях и текущем состоянии ресурсов. +- Реализация: +- ЦП имеет несколько функциональных устройств, которые сообщают табло информацию о своем состоянии. +- Каждая инструкция проходит сквозь табло, где строится запись о ее зависимостях по данным. +- Если табло определяет, что инструкция не может быть выдана на исполнение немедленно, ее исполнение откладывается. +- Табло отслеживает статус зависимостей и аппаратных блоков и решает, когда отложенная инструкция может быть направлена на исполнение. +- Табло выдает инструкции разрешение для записи результата в регистры. + +**Контролируемые параметры:** + +- **Статус инструкции:** + +На каком из 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 после того, как операнды стали доступны для чтения, затем оба операнда считываются из регистров одновременно. + +- **Статус регистра:** + +Какое функциональное устройство собирается писать в регистр (если такое есть) +Пуст, когда никакие незаконченные инструкции не будут писать в указанный регистр. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/3.md new file mode 100644 index 0000000..813c5cd --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/3.md @@ -0,0 +1,19 @@ +#### Ступени конвейера, использующего табло. Обработка инструкции на различных ступенях. + +- **Выборка инструкции (IF)** - последовательна. +- **Выдача (ID1).** Инструкция выдается, если: +- Функциональное устройство для инструкции доступно (нет структурного конфликта). +- Регистр назначения для результата инструкции не помечен для записи другой раннее запущенной инструкцией (нет конфликта WAW). +- **Чтение операндов (ID2)** +- Табло отслеживает доступность операндов. +- Когда все операнды доступны, табло указывает функциональному устройству считать все операнды из регистров (пересылка не поддерживается) и начать исполнение. +- Таким образом, конфликты RAW разрешаются динамически. + +Между стадией ID2 и EX не может быть простоев. В табло хранится информация кто от кого зависит, и как только необходимые регистры появились, мы их сразу забираем. + +- **Исполнение (EX).** Заменяет EX+MEM в MIPS. +- Функциональное устройство начинает исполнение, как только получит операнды. +- Когда результаты готовы, оно уведомляет табло. +- **Запись результата (WB)** +- Когда табло уведомляется о том, что функциональный блок завершил исполнение, оно выполняет проверку на конфликты WAR и приостанавливает запись результата, если необходимо. +- Функциональное устройство помечается как доступное для других инструкций после того, как ступень WB завершена. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/4.md new file mode 100644 index 0000000..6095032 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/4.md @@ -0,0 +1,2 @@ +#### Пример обработки участка кода. +??? \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/1.md new file mode 100644 index 0000000..71e6598 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/1.md @@ -0,0 +1,29 @@ +#### Определение динамического планирования. Принципы реализации динамического планирования. + +**Динамическое планирование** (неупорядоченное исполнение, out-of-order execution) - аппаратный механизм переупорядочивания (изменения порядка исполнения инструкций) во время исполнения. + +Не может преодолеть истинные зависимости данных, но пытается сократить или даже предотвратить простои. +Позволяет обрабатывать случаи, когда зависимости между инструкциями неизвестны во время компиляции. + +**Концепции:** + +- Инструкциям разрешается исполняться неупорядоченно, как только становятся доступны их операнды. +- Разрешение инструкциям неупорядоченно завершаться. + +**Реализация динамического планирования:** + +- Ступень декодирования инструкций ID делится на 2 ступени: + +1. **Выдача** - декодирование инструкций, проверка структурных конфликтов. Всегда выполняется в порядке, указанном в программе. +Зависимости под данными записываются по мере того, как инструкции выдаются (динамически создается эквивалент графа зависимостей для множества инструкций, которые находятся в ЦП) +2. **Чтение операндов** - ожидание разрешения конфликтов данных, если они есть, и последующее чтение операндов по мере их доступности. Может происходить в порядке, отличном от указанного в программе. + +- На ступени выборки инструкции IF производится выборка дополнительной инструкции в специальный регистр или нескольких инструкций в очередь в каждом такте. +- Увеличивается число функциональных устройств для исполнения большего числа инструкций на ступени EX без структурных конфликтов. +- Два подхода к реализации: + +1) **Табло (Scoreboard)**, 1963. +2) **Алгоритм Томасуло**, 1966. + +Будем считать, что стадия выборки выполняется на соответствующем для нее такте, что конфликтов управления у нас не возникает, что выборка всегда успевает поставить нам очередную инструкцию. +Предполагаем, что может быть реализовано несколько исполняющих блоков на стадии исполнения. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/2.md new file mode 100644 index 0000000..1501c8d --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/2.md @@ -0,0 +1,67 @@ +#### Принципы работы алгоритма Томасуло. "Станции резервации"(reservation stations), переименование регистров, общая шина данных (Common Data Bus, CDB). Поля станций резервации. + +**Управление распределено по функциональным устройствам (в Табло - централизовано).** + +- **FU** имеют специальные буферы - **«станции резервации» (Reservation Station)**, которые содержат: +- Незавершенные инструкции. +- Операнды незавершенных инструкций. +- Информацию о статусе инструкций (включая зависимости данных). +- Станции резервации иногда называют «физическими регистрами» или «переименованными регистрами» в противоположность регистрам архитектуры, заданным в ISA. +Регистры ISA в инструкциях заменяются либо их значениями (если доступны), либо указателями на станции резервации, которые предоставят значение позже. +- Этот процесс называется **переименованием регистров**. +- Переименование регистров исключает конфликты WAR, WAW (зависимости по именам). +- Позволяет использовать аппаратное разворачивание циклов. + +- Станций резервации может быть больше, чем регистров ISA, что ведет к аппаратной оптимизации, которая невозможна для компиляторов, а также предотвращает узкое место из-за количества регистров ISA. + +**Недостатки:** + +- Сложность реализации. +- Требуется большое число высокоскоростных ассоциативных портов чтения результатов с CDB. +- Производительность может ограничиваться одной CDB. + +Возможное решение - несколько CDBs. + +**Принцип работы:** + +- **Стадия выдачи** + +Проверяем ожидает ли регистр какое-то значение от RS. Если ожидает - делаем пометку, что мы тоже ожидаем значение от той же RS, что и регистр. Иначе просто копируем значение регистра в аргумент. По итогу у нас либо есть все аргументы, либо мы знаем, от какой RS мы ожидаем аргументы. Потом помечаем, что наша станция busy. В конце помечаем выходной регистр, что он ожидает значения от нашей станции резервации. + +- **Исполнение** + +Если готовы оба аргумента - начинаем исполнение. + +- **Запись результата** +1) Если какой-то регистр ожидает ответа от нашей станции резервации, то записываем результат и помечаем, что регистр больше не ожидает - свободен. +2) Всем станциям, которые в качестве параметра ожидали значение от нашей станции - записываем это значение. +3) Если ожидала станция сохранения, то записываем +4) Помечаем текущую станцию незанятой. + +**Общая шина данных (CDB):** данные + адрес назначения (шина «куда) + +- 64 бит для данных + 4 бита для адреса функционального устройства - источника. +- данные записываются в ждущую RS, если адрес источника совпадает с адресом RS, которая производит операнд источник. +- передача результата происходит через рассылку ждущим RS, включая регистровый файл. + +**Поля станции резервации:** + +- **Busy** - RS занята. +- **Op** - операция, выполняемая в устройстве. +- $V_j,V_k$ - значения операндов источников S1, S2. + +Буферы записи имеют одно V поле, показывающее результат, который надо сохранить. + +- $Q_j,Q_k$ - RS, производящие операнды - источники. + +Нет флагов готовности, как в Табло: $Q_j,Q_k=0=>$ операнды готовы. +Буферы сохранения имеют только Q, для RS, производящей результат. + +- **A** - информация об адресах для операций load/store. + +Сначала поле прямого адреса инструкции, потом реальный адрес, когда он вычислен. + +- $Q_i$ - показывает, какая RS будет записывать в регистр, если такая есть. + +Пустой (или 0), когда нет незаконченных инструкций (где-то в RS), которые будут записывать в тот регистр. +Регистровый файл ведет себя как RS. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/3.md new file mode 100644 index 0000000..b496ad1 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/3.md @@ -0,0 +1,18 @@ +#### Ступени конвейера, использующего алгоритм Томасуло. Обработка инструкции на различных ступенях. + +- **Выборка (IF)** - обрабатывается последовательно. +- **Выдача (ID)** - обрабатывается последовательно. +- Получить инструкцию из очереди выбранных инструкций (IQ). +- Выдать инструкцию в свободную RS, если нет структурного конфликта. +- Пометить выбранную RS как занятую. +- Переслать доступные значения операндов инструкции (из регистров ISA) в выбранную RS. +- Переименовать еще не доступные операнды в указатели на RS, которые их произведут (переименование регистров, динамическое построение графа зависимостей данных). +- Указать для выходного регистра, что он ожидает значение от используемой RS. +- **Исполнение (EX)** +- если оба операнда готовы, начинается исполнение на назначенном FU. + +- если не все операнды готовы, следим за CDB в ожидании требуемого результата (через CDB происходит пересылка). +т.е. предотвращаем RAW и соблюдаем зависимости по данным. +- **Запись результата (WB)** +- результат выдается на CDB для всех ожидающих RS, т.е результат рассылается по CDB. +- станция резервации помечается как свободная. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/4.md new file mode 100644 index 0000000..67be9f3 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/4.md @@ -0,0 +1,3 @@ + +#### Пример обработки участка кода. +??? \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/1.md new file mode 100644 index 0000000..f30c1c3 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/1.md @@ -0,0 +1,13 @@ +#### Принцип и цель суперскалярности. Характерные особенности применения. + +**Суперскалярность** - выдача более одной команды в такте. + +- Различные CPU могут выдавать от 2-х до 8-ми инструкций за такт. +- В простейшем случае за эффективную загрузку CPU отвечает оптимизирующий компилятор. +- Все современные суперскалярные микропроцессоры используют аппаратную логику анализа ILP перед выдачей инструкций. +- Компилятор + аппаратная логика не могут полностью обойти все конфликты RAW, задержки доступа к памяти и обеспечить 100% нагрузку CPU. +- Следствие: фактическое число выданных в такте инструкций колеблется от 0 до макс. возможного для данного CPU. +CPI может быть <1 (самое лучшее CPI = 0.125). +ILP является мерой того, какое множество операций в компьютерной программе может выполняться одновременно. + +**Первичное представление суперскалярной архитектуры:** есть память, кэш инструкций, декодер, умеющий выдавать N инструкций за такт, есть функциональные устройства и станции резервации, которые могут выдавать задания на вычислительные устройства. Может быть несколько RS и они могут выдавать задания на несколько устройств. Из регистрового файла можем брать значения для RS. Есть буфер переупорядочивания. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/2.md new file mode 100644 index 0000000..6944104 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/2.md @@ -0,0 +1,34 @@ +#### Простейшая реализация суперскалярности (x2). Пример. + +**Суперскалярный конвейер:** 2 инструкции, 1 FP +1 не только FP +**Требования:** + +- Выборка 64-бит/такт +- Декодирование 2-х инструкций/такт +- Много портов для FP регистров, чтобы загружать FP в паре с FP обработкой + +| Тип | Стадии конвейера | | | | | | | | +| :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | +| Int instruct | IF | ID | EX | MEM | WB | | | | +| FP instruct | IF | ID | EX | EX | EX | WB | | | +| Int instruct | | IF | ID | EX | MEM | WB | | | +| FP instruct | | IF | ID | EX | EX | EX | WB | | +| Int instruct | | | IF | ID | EX | MEM | WB | | +| FP instruct | | | IF | ID | EX | EX | EX | WB | + +**Сложности аппаратной реализации:** + +- Следствие ограничений ILP: сложные механизмы предсказания ветвлений и высокий уровень спекулятивности. +- Задержки блоков, планирующих и обрабатывающих множество операций в такте. +- Большое количество портов к регистровому файлу (пропускная способность внутренних шин). +- Обслуживание частого непоследовательного доступа к памяти. + +| | 1 | 2 | 3 | 4 | 5 | 6 | 7 | +| :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | +| LD F6, [R2] | IF | EX | WB | | | | | +| LD F2, [R3] | IF | EX | WB | | | | | +| DMUL F2, F4, F0 | | IF | EX | EX | EX | EX | WB | +| DSUB F6, F2, F8 | | IF | EX | EX | WB | | | +| DDIV F0, F6, F10 | | | IF | | | | EX | +| DADD F8, F2, F6 | | | IF | | EX | EX | WB | +| DMUL F2, F4, F12 | | | | | IF | | ... | diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/3.md new file mode 100644 index 0000000..2758103 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/3.md @@ -0,0 +1,4 @@ +#### Динамическое планирование при суперскалярности. + +Есть зависимости между инструкциями, их надо соблюдать. +Когда вы компилируете программу, если вы используете оптимизацию, то выполняете оптимизацию для конкретной модели ЦП. При использовании ДП программа запустится эффективно на разных моделях ЦП. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/4.md new file mode 100644 index 0000000..67b9d93 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/4.md @@ -0,0 +1,2 @@ +#### Масштабируемость и перспективы суперскалярности. +??? \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/1.md new file mode 100644 index 0000000..57657fa --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/1.md @@ -0,0 +1,6 @@ +#### Определение динамического предсказания ветвлений. + +**Динамическое предсказание ветвлений** - аппаратные схемы, которые динамически предсказывают переходы на основе поведения программы при исполнении, т.е. информация о предыдущих ветвлениях используется, чтобы динамически предсказать исход текущего перехода. ЦП отслеживает выполнение условных переходов в течение работы программы и куда выполнится переход. +Позволяет сократить время простоя за счёт предварительной загрузки и исполнения инструкций, которые должны выполниться после выполнения инструкции условного перехода. +Прогнозирование ветвлений играет критическую роль, так в большинстве случаев (точность предсказания переходов $\geq 90\%$) позволяет оптимально использовать вычислительные ресурсы процессора. + diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/2.md new file mode 100644 index 0000000..15302fd --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/2.md @@ -0,0 +1,16 @@ +#### Структура ВТВ. + +Эффективное предсказание переходов требует наличие цели перехода на ранней стадии конвейера, можно использовать доп. сумматоры на стадии ID, чтобы цель могла быть выбрана, но будет 1 такт простоя. Проблему решает буфер целей перехода (ВТВ). +**ВТВ** - аппаратный механизм, снижающий число тактов простоя при корректно предсказанном переходе до 0. +**ВТВ** - буфер целей перехода, доп. набор логики, который располагается на стадии IF и который помогает предсказывать переходы. +Цель: переходы без простоев. +Если мы угадали с помощью ВТВ, значит после выполнения IF мы знаем адрес следующей инструкции. + +**Простейший вариант** - когда в ВТВ хранится целевой адрес. Вид ВТВ: + +| Адрес перехода | Цель перехода, если он предсказан выполняющимся. | Бит валидности | +| :-- | :-- | :-- | +| ... | ... | ... | + +Бит валидности - признак актуальности строки. +Кэш полностью ассоциативный. Адрес текущей инструкции ищется в первом столбце. Если он там есть, тогда текущая инструкция - условный переход, причем выполняющийся. Тогда считываем адрес из второго столбца. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/3.md new file mode 100644 index 0000000..9085f8c --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/3.md @@ -0,0 +1,26 @@ +#### Алгоритм заполнения и использования ВТВ. + +- **Адрес есть в ВТВ.** + +Берем адрес перехода из буфера. На следующем такте проверяем, выполнился ли переход. + +- **Угадали.** + +Продолжаем выполнение, убираем запись из буфера. + +- **Не угадали.** + +Очищаем эту запись в ВТВ и отбрасываем результаты выполнения. + +- **В таблице ВТВ не нашли наш адрес.** + +Пытаемся спекулятивно выполнить со следующего адреса. + +- **Перехода нет** + +Продолжаем выполнение и результат сохраняется, запись из буфера убирается. + +- **Переход есть.** + +Результат отбрасывается, вычисляем новый адрес и на новом такте считываем новый адрес. Информацию о том, что переход состоялся записываем в ВТВ. +Получается конструкция с запоминанием последнего результата выполнения перехода. Штраф ветвления - 2 такта. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/4.md new file mode 100644 index 0000000..849107a --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/4.md @@ -0,0 +1,19 @@ +#### Структура РНТ. Алгоритм изменения и использования. Интерференция адресов. Структура ВНТ. + +**ВНТ:** Таблица признаков, происходил переход или нет. Хранится выполнение/невыполнение перехода. Берем какое-то число младших бит адреса инструкции, они являются номером записи в ВНТ. Каждая запись ВНТ содержит бит, индицирующий, выполнялось ли ветвление или нет в прошлый раз. Когда мы проверим, выполняется/не выполняется переход, при необходимости обновим запись в ВНТ. +**Простейший метод (одноуровневый):** + +- ВНТ индексируется младшими битами адреса инструкции ветвления. +- Каждая запись ВНТ содержит бит индицирующий выполнялось ли ветвление или нет в прошлый раз. 0 - не выполнялось. 1 - выполнялось. +- Используемый счетчик (предсказатель) обновляется после обработки инструкции перехода. Увеличить счетчик, если есть переход, уменьшить - если нет перехода. +- Всегда ошибается на первой и последней итерациях цикла. + +**Интерференция** - возникает, когда разные переходы отображаются на один и тот же счетчик (одни и те же младшие биты адреса). +Для улучшения точности предсказания используется 2-битовое предсказание: + +- Прогноз должен промахнуться дважды, прежде чем он изменится. + +Поэтому переход в цикле будет предсказан неверно только 1 раз при повторной встрече, вместо 2 раз при 1-битной схеме. + +- 2-битовое предсказание - частный случай n-битного счетчика с насыщением наращиваемого при выполнении ветвления и уменьшаемого, когда ветвление не выполняется. +- В большинстве случаев используется 2-битный счетчик предсказаний, поскольку наблюдения показывают, что эффективность предсказания 2-битной ВНТ сравнима с эффективностью n-битной. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/1.md new file mode 100644 index 0000000..4e53ef8 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/1.md @@ -0,0 +1,5 @@ +#### Определение динамического предсказания ветвлений. + +**Динамическое предсказание ветвлений** - аппаратные схемы, которые динамически предсказывают переходы на основе поведения программы при исполнении, т.е. информация о предыдущих ветвлениях используется, чтобы динамически предсказать исход текущего перехода. ЦП отслеживает выполнение условных переходов в течение работы программы и куда выполнится переход. +Позволяет сократить время простоя за счёт предварительной загрузки и исполнения инструкций, которые должны выполниться после выполнения инструкции условного перехода. +Прогнозирование ветвлений играет критическую роль, так в большинстве случаев (точность предсказания переходов $\geq 90\%$) позволяет оптимально использовать вычислительные ресурсы процессора. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/2.md new file mode 100644 index 0000000..08a497b --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/2.md @@ -0,0 +1,21 @@ +#### Описание двухуровневого механизма динамического предсказания ветвлений с учетом корреляции. + +Соседние переходы могут коррелировать: поведение недавно выполненных переходов влияет на предсказание текущего перехода. +Это имеет место в ветвлениях, использованных для реализации конструкций if-then-else. +Предполагается, что есть 2 уровня предсказаний: + +1) **Глобальный** + +Запись истории поведения m последних переходов как выполнившихся или нет. Обычно используется m -битный регистр сдвига. + +2) **На один адрес ветвления** + +- $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)$, которое означает: +- Записываются последние $m$ ветвлений для выбора между $2^m$ таблицами истории. +- Каждая таблица истории $2^{го}$ уровня использует n-битные счетчики (имеет разрядность n бит). +- Одноуровневая схема бимодальной ВНТ с 2-битными счетчиками обозначается как предсказатель $(0,2)$ + diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/3.md new file mode 100644 index 0000000..9ce1163 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/3.md @@ -0,0 +1,6 @@ +#### Схема MCFarling'a gshare. Преимущества схемы. + +**gshare** = global history with index sharing +McFarling предложил использовать и глобальную историю и адрес ветвления, объединяя их хешированием. Функция хеширования: XOR от регистра глобальной истории ветвлений (BHR) и адреса ветвления. Он ожидал, что такой хеш содержит больше информации, чем каждая из компонент. В результате предложенная схема превзошла GAp при малых размерах таблиц. +Новая схема обладает меньшими требованиями к оборудованию для реализации по сравнению с GAp, поскольку использует одну общую таблицу предсказателей. +Требуется на k бит истории $2 \times 2^k$ в таблице 2-битных счетчиков. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/4.md new file mode 100644 index 0000000..e646681 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/4.md @@ -0,0 +1,10 @@ +#### Определение и принцип работы гибридных/турнирных/комбинированных предсказателей. + +**Гибридные (турнирные, комбинированные) предсказатели** - комбинации 2 или более механизмов предсказания переходов. +McFarling заметил, что использование глобальной истории поведения переходов может быть менее эффективно, чем просто использование адреса инструкции перехода, особенно для маленьких таблиц предсказателей. McFarling исследовал несколько различных комбинаций 2-х механизмов предсказания переходов. +Он предложил использовать дополнительный массив 2-бит счетчиков как селекторов для выбора более эффективной схемы предсказания для каждого перехода. +1 схема предсказания соответствует 2 большим значениям селектора, другая $-2^{ом}$ меньшим. +Если $1^{ый}$ предсказатель ошибся, а $2^{ой}$ - нет, счетчик уменьшается. +Если $1^{ый}$ предсказатель прав, а $2^{ой}$ - нет, счетчик увеличивается. + +Никаких изменений, если оба оказались правы или ошиблись. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/1.md new file mode 100644 index 0000000..f0b546f --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/1.md @@ -0,0 +1,37 @@ +#### Определение кэша и кэширования. Уровни иерархии памяти. + +**Кэш** - быстродействующая буферная память между CPU и основной памятью, в которую помещаются фрагменты кода и данные, активно используемые программой в текущий момент времени. +**Кэширование памяти** - временное хранение в более быстрой памяти данных из более медленной памяти. +Эффективность кэширования основывается на локальности доступа к памяти. Дополнительно может решаться задача снижения требований к пропускной способности основной памяти. +Размер кэша меньше, чем размер основной памяти. +Кэширование используется на нескольких разных уровнях. С точки зрения процессора, кэш - это механизм устранения задержек. К памяти обращаться долго, но если использовать кэш, то время обращения будет намного меньше. +Часто данные одного уровня иерархии являются подмножеством данных нижележащего уровня: данные дублируются в более медленном нижележащем уровне - инклюзивное кэширование. +**Иерархия памяти** состоит из нескольких уровней. Меньший по объему, более скоростной уровень памяти расположен ближе к ЦП: + +- регистры +- основной кэш $(L_1)$ +- дополнительные вторичные кэши $(L_2,L_3,...)$ +- основная память +- устройства массового хранения (виртуальная память) + +Или + +- регистры +- кэш-память +- оперативная память +- долговременная память +- сторонние устройства + +Каждый уровень проецирует адреса более емкой памяти на менее емкий уровень, ближе к ЦП. +Когда для CPU требуется инструкция или операнд, производится поиск по всем уровням иерархии памяти, начиная с ближайшего с CPU (кэш $1^{го}$ уровня): + +- Если элемент найден, он доставляется в ЦП без поиска по нижележащим уровням. Происходит попадание в кэш (частота попаданий $=H_1$). +- Если элемент отсутствует в верхнем уровне, происходит кэш-промах, и поиск продолжается на нижестоящем уровне (частота промахов $=1-H_1$). +- Для систем с несколькими уровнями кэша, поиск последовательно продолжается на уровнях 2,3, и тд +- Если поиск в кэшах завершился промахами, запрашиваются данные из основной памяти. + +Взаимодействие «ЦП» $\Rightarrow$ «КЭШ» $\Rightarrow$ «Память» реализовано аппаратно. + +- Если элемент не найден в основной памяти, происходит обращение к диску (вирт. память). Это называется page fault. +Взаимодействие «Память» $\Rightarrow$ «Диск» реализовано в ОС при аппаратной поддержке. + diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/2.md new file mode 100644 index 0000000..119cb71 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/2.md @@ -0,0 +1,10 @@ +#### Определения: блок, попадание, частота попаданий, время попадания, промах, частота промахов, штраф за промах. + +**Блок (cache block/cache line)** - наименьшая единица информации, передаваемая между уровнями. Обычно размер блока - размер самого большого регистра. +**Попадание** - элемент найден в кэше верхнего уровня. +**Частота попаданий ($H_1$)** - доля обращений к памяти с попаданием в кэш. +**Время попадания** - время обращения к верхнему уровню, которое зависит от времени доступа к (S)RAM + время на определение попадание/промах. В идеале - 1 такт. +**Промах** - элемент должен быть получен из блока с нижнего уровня. +**Частота промахов** $=1-$ «частота попаданий» $=1-H_1$ +**Штраф за промах** - время на замену блока в верхнем уровне + время на доставку отсутствующего блока в ЦП + diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/3.md new file mode 100644 index 0000000..d73ccc9 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/3.md @@ -0,0 +1,16 @@ +#### Принцип локальности. Два вида локальности. + +Программы обычно обращаются к относительно небольшой области адресного пространства (инструкции и данных) в любой момент времени - к рабочему набору (working set) +**Working set** - набор адресов, с которыми программа работала в течение небольшого интервала времени. +Два вида локальности доступа: + +- **Временная** + +Обращение к элементу (инструкции или данным) имеет тенденцию повторяться. +Пример: инструкции во вложенном цикле. + +- **Пространственная** + +После обращения к некоторому элементу скорее всего вскоре произойдет обращение к другим элементам с близкими адресами. +Примеры: последовательное выполнение инструкций, последовательный доступ к элементам массива. +Пример программы, где нет временной локальности: поиск максимума в несортированном массиве, так как нам в любом случае придется просматривать содержимое массива от начала и до конца. Кэширование в этом случае практически бесполезно. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/19 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/19 билет/1.md new file mode 100644 index 0000000..ee6be76 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/19 билет/1.md @@ -0,0 +1,28 @@ +#### Кэш прямого отображения(Direct mapped cache). Поля строки/блока кэша. Проецирующая функция. + +**Кэш прямого отображения** - стратегия размещения блока основной памяти в кэше, где блок размещается в одном строго определенном месте, определяемом функцией размещения. +Существует три стратегии размещения или проецирования блока основной памяти в кэш: + +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) Все остальное - тег. Возможные адреса блоков, которые могут храниться в конкретной записи в кэше. Если тэг из кэша равен тэгу из адреса, по которому обратились, и бит валидности установлен, то диагностируем попадание и берем данные из кэша. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/19 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/19 билет/2.md new file mode 100644 index 0000000..6c4ce9d --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/19 билет/2.md @@ -0,0 +1,5 @@ +#### Наборно-ассоциативный кэш (Set associative cache), полностью ассоциативный кэш (Fully associative cache). + +**Наборно-ассоциативный кэш** требует параллельного сравнения тегов и более сложную логику проверки попадания, что может увеличить задержку доступа. +В наборно-ассоциативном кэше меньше промахов в результате уменьшения числа конфликтов между блоками, которые были бы спроецированы в одну и ту же строку в кэше прямого отображения. +У **полностью ассоциативного кэша** никакого разбиения адреса нет, адрес блока является тэгом. В полностью ассоциативном кэше преимущество: высокая скорость считывания. Недостаток: сложность аппаратной реализации. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/1.md new file mode 100644 index 0000000..77a7aaf --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/1.md @@ -0,0 +1,20 @@ +# Определение микрооперации. Определение "среднее CPI программы" + +**Микрооперация** +- Элементарное аппаратное действие, которое может быть произведено за 1 такт CPU. +- Микрооперация соответствует одной микроинструкции в микропрограммируемых CPU. + +**Набор RISC команд** +- Множество микроопераций, которые выполняет процессор. + +**Набор CISC команд** +- Множество микроопераций, получаемых при декодировании процессором CISC команд. + +**CPI (Cycles Per Instruction)** +- Такт на инструкцию. + +**Среднее CPI программы** +- CPI, усредненное для всех инструкций, выполненных в программе на CPU с заданным дизайном. + +**IPC (Instruction Per Cycle)** +- Число инструкций за такт, $$ IPC = 1/CPI. $$ diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/2.md new file mode 100644 index 0000000..742a289 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/2.md @@ -0,0 +1,10 @@ +#### Уравнение производительности CPU + +**Формула:** + +$$ T = I \times CPI \times C $$ + +**Где:** +- $I$ - число исполняемых инструкций программы. +- $CPI$ - число тактов на инструкцию. +- $C$ - фиксированное время такта, $C = \frac{1}{\text{тактовая частота}}$. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/3.md new file mode 100644 index 0000000..1d3a828 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/3.md @@ -0,0 +1,10 @@ +**Факторы, влияющие на производительность CPU:** + +- **Число исполняемых инструкций \( I \):** + - Зависит от используемой программы, компилятора, ISA. + +- **Среднее CPI:** + - Зависит от используемой программы, компилятора, ISA, организации CPU. + +- **Время такта \( C \):** + - Зависит от организации CPU и технологии (СБИС). \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/1.md new file mode 100644 index 0000000..39d3953 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/1.md @@ -0,0 +1,17 @@ +#### Политики замещения Random, LRU, FIFO. + +Когда происходит промах, контроллер кэша должен выбрать блок данных кэша для удаления из строки и замещения запрошенными данными. Выбор блока производится $1^{ным}$ из $3^{a}$ методов: + +- **Произвольно:** + +Блок для замещения выбирается случайным образом. +Простая реализация. Наиболее широко используемая политика. + +- **Наиболее давно востребованный (LRU):** + +Все обращения к блокам записываются и замещаются те блоки, к которым не было обращения в течение длительного времени. +Метод LRU быстро усложняется в реализации при увеличении числа блоков. Поэтому часто используется приближение, при котором биты использования периодически сбрасываются. + +- **Первый вошел - первый вышел (FIFO):** + +Так как LRU и является сложен в реализации, этот подход является приближением к LRU в определении наиболее старого блока. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/2.md new file mode 100644 index 0000000..04967f8 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/2.md @@ -0,0 +1,41 @@ +#### Причины кэш-промахов. Уменьшение частоты промахов: дополнительный кэш «жертв», разделение кэша прямого доступа на 2 части, программная предвыборка данных, аппаратная предвыборка команд и данных. + +**Причины кэш промахов:** + +1) **Вынужденный** + +При первом обращении к блоку. Блок должен быть помещен в кэш. Также называется промах холодного старта или промах первого обращения. При запуске программы miss rate $~ 100\%$. +Решаются увеличением объема блока и предвыборкой. +2) **Ограниченная емкость** + +В случае, когда кэш не может вместить все блоки, востребованные кодом, и возникает «перетасовка» блоков (рабочий набор много больше емкости кэша). +Решается увеличением объема кэша. +3) **Конфликты** + +В наборно-ассоциативном или кэше с прямым отображением стратегия размещения блоков вызывает конкуренцию нескольких блоков за одну строку кэша; +Также называется промахом из-за коллизий или интерференции. +**Способ совместить низкое время доступа кэша с прямым отображением и низкую частоту промахов из-за конфликтов 2-х канального наборно-ассоциативного кэша:** + +- Разделим кэш. При промахе проверяем вторую половину кэша, если теперь происходит попадание, то это - «псевдо-попадание» (медленнее нормального). +- Недостаток: согласование конвейера CPU с переменной задержкой доступа в кэш ( 1 или 2 такта)Лучше для кэша, не связанного непосредственно с CPU (L2). +- Процессор может анализировать шаблон обращения к памяти и может пытаться предсказать адреса, по которым будет обращение к памяти в ближайшее время. Процессор сам инициирует доп. обращение к памяти, выполняя спекулятивную загрузку данных. +**Уменьшаем частоту промахов с помощью программной предвыборки данных:** +- Загрузка данных в регистры. +- Предвыборка в кэш. +- Спец. команды предвыборки, не вызывающие сбоев; разновидность спекулятивности. +- Обработка команд отнимает время. + +Время на обработку команд предвыборки должно оправдываться сокращением промахов. + +- Высокий уровень суперскалярности снижает «цену» выдачи доп. команд и одновременно повышает «цену» промахов кэша. +**Уменьшаем частоту промахов с помощью программной оптимизации компилятором:** +**Инструкции:** +- Расположение процедур в памяти так, чтобы сократить промахи из-за конфликтов. +- Профилирование для обнаружения конфликтов (используя собственное ПО). + +**Данные:** + +- Слияние массивов: увеличение пространственной локальности объединением нескольких массивов в 1 +- Согласование вложенности циклов: согласование уровня вложенности циклов для обработки в соответствии с порядком хранения данных в памяти +- Слияние циклов: составление из независимых циклов, обрабатывающих одни данные, общего. +- Поблочная обработка массивов: улучшение временной локальности за счет повторной обработки блоков данных вместо полного обхода по строкам и столбцам. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/3.md new file mode 100644 index 0000000..899fe53 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/3.md @@ -0,0 +1,15 @@ +#### Описание стратегий записи в кэш Write Through и Write Back + +По способу синхронизации содержимого кэша с основной памятью можно разделить кэш на: + +1) **Write Through.** Данные записываются одновременно в кэш и в основную память. + +- Нижние уровни всегда содержат обновленные данные; важная особенность для I/O и многопроцессорности. +- Проще в реализации, чем Write Back. +- Часто используется буфер записи для уменьшения простоя CPU, пока данные пишутся в основную память. + +2) **Write Back.** Данные обновляются только в кэше. Модифицированный блок из кэша записывается в основную память, когда он замещается в кэше. + +- Запись данных CPU происходит на скорости кэша. +- Бит статуса, называемый dirty bit или modified bit показывает, что блок был изменен; иначе блок не записывается обратно в основную память. +- Преимущество: требует меньшей пропускной способности памяти, чем стратегия Write Through. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/21.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/21.md new file mode 100644 index 0000000..a4e66c9 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/21.md @@ -0,0 +1,12 @@ +#### Понятие вектора и векторных операций. Способы использования векторных операций. + +**Вектор** - набор однотипных данных. Длина вектора определяется архитектурой. +Позволяют за одну инструкцию выполнить арифметическую операцию над несколькими парами операндов. Имеются унарные, бинарные и тернарные операции. +**Использование векторизации:** + +- Спец директивы или intrinsic +- Автоматическая векторизация компилятором + +**Векторизация компилятора** - компилятор сам может оптимизировать программу, представляя что-то через вектор. +**Спец директивы** - программист сам может напрямую сказать, что можно векторизовать. +**Intrinsic** - явный набор действий, которые надо сделать над векторами. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/3 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/3 билет/1.md new file mode 100644 index 0000000..e9f7aed --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/3 билет/1.md @@ -0,0 +1,13 @@ +#### Список метрик производительности + +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}$$ \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/3 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/3 билет/2.md new file mode 100644 index 0000000..9a7b2a3 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/3 билет/2.md @@ -0,0 +1,13 @@ +#### Типы программ для оценки производительности + +1. **Целевая нагрузка** + - Полноценные приложения. Дают правильное представление о работе системы, но очень специфичны, непереносимы и сложны. + +2. **Бенчмарки** + - Основаны на реальных полноценных приложениях. Обеспечивают типовые варианты нагрузки на подсистемы компьютера. Переносимы, измерения полезны в реальности, но менее представительны, чем реальная нагрузка. + +3. **Небольшие тестовые «ядра»** + - Типовые фрагменты реальных программ. Лучше всего подходят для тестирования специфических аспектов машины. Легко использовать на ранних стадиях разработки приложений, но легко одурачить с помощью проектирования под них hardware. + +4. **Микро-бенчмарки** + - Пытаются оценить отдельный тип производительности. Используется один тип операций. Идентифицируют пиковую производительность и потенциальные узкие места, но пиковые цифры производительности могут быть далеки от производительности в реальных приложениях. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/1.md new file mode 100644 index 0000000..2b75d78 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/1.md @@ -0,0 +1,11 @@ +#### Определение ISA + +ISA определяет вычислительную систему с точки зрения программиста, т.е. функциональную структуру и принципиальное поведение, независимо от организации потоков данных, схем управляющей логики и физической реализации. + +**К ISA относятся:** +1. Тип данных, способ кодирования. +2. Организация программируемых мест хранения. +3. Набор допустимых инструкций. +4. Режимы адресации и доступ к элементам данных и инструкциям. +5. Формат инструкций. +6. Условия возникновения исключений. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/2.md new file mode 100644 index 0000000..72ad063 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/2.md @@ -0,0 +1,14 @@ +#### Архитектуры, использующие различные программируемые места хранения + +1. **Машины Memory-To-Memory** + - Операнды выбираются из памяти и результат сохраняется в памяти для любой инструкции, требующей операнды. + - В тракте данных CPU (datapath) регистры не используются. + +2. **1-адресные машины (аккумулятор)** + - Один локальный регистр CPU (аккумулятор) используется как источник одного из операндов и приемник результата. + +3. **0-адресные машины** + - Внутри CPU стек регистров. + +4. **Машины с регистрами общего назначения (General Purpose Register, GPR)** + - Тракт данных CPU содержит несколько регистров общего назначения, которые можно использовать как место хранения операндов или результата. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/3.md new file mode 100644 index 0000000..9683bb6 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/3.md @@ -0,0 +1,30 @@ +#### Режимы адресации + +1. **Регистровый** + - ADD R1, R2, R1. + +2. **Прямой** + - MOV 15, R1. + - ADD R1, #3, R1. + +3. **Абсолютный** + - ADD R1, [1001], R1. + +4. **Косвенный** + - ADD R1, [R2], R1. + +5. **Со смещением** + - ADD R1, [10+R2], R1. + +6. **Индексный** + - ADD R1, [R2+R3], R1. + +7. **Косвенный в памяти** + - ADD R1, [[R2]], R1. + +8. **Автоинкремент, автодекремент** + - ADD R1, [R2++], R1. + - ADD R1, [R2--], R1. + +9. **С масштабированием** + - ADD R1, [8+R2(R3)], R1. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/4.md new file mode 100644 index 0000000..d9a70f2 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/4.md @@ -0,0 +1,7 @@ +#### Архитектуры Load-Store/Register-To-Register + +**Системы Load-Store/Register-To-Register** +- Машины с GPR, в которых только инструкции перемещения данных (load, store) могут получать операнды из памяти и сохранять в нее результаты. +- Упрощает архитектуру CPU. +- Регистры быстрее, чем память. +- Компилятору проще использовать регистры. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/1.md new file mode 100644 index 0000000..4e74e73 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/1.md @@ -0,0 +1,16 @@ +#### Перечисление типов команд + +1. **Перемещение данных** + - Сохранить в регистре заданное константное значение: MOV 123, R0. + - Скопировать значения из памяти в регистр, или из регистра в память, или из регистра в регистр: LD [Addr], R0; ST R0, [Addr]; MOV R0, R1. + - Чтение и запись данных с/на устройство ввода-вывода: OUT R0, IOPort1; IN IOPort2, R1. + +2. **Арифметико-логические операции** + - Сложить, вычесть, умножить, разделить: ADD R0, R1, R2; SUB, MUL, DIV, FADD, FSUB, FMUL, FDIV. + - Побитовые операции: AND R0, R1, R2; NOT, OR, XOR, SHL, SHR, SAR, ROL, ROR, BT. + - Сравнение двух значений: CMP R0, R1. + +3. **Управление порядком выполнения программы** + - Безусловный переход: JMP [Addr]. + - Условный переход: JE [Addr]; JE (Equal), JNE (Not Equal), JG (Greater), JGE (Greater Equal), JL (Less), JLE (Less Equal), JZ (Zero). + - Вызов функции: PUSH R0; CALL [AddrFunc]; POP R0; RET. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/2.md new file mode 100644 index 0000000..9975c59 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/2.md @@ -0,0 +1,10 @@ +#### Кодирование инструкций + +**Кодирование инструкций** +- Представление инструкции в двоичном виде и хранение в оперативной памяти. ЦП считывает и интерпретирует ее. +- Желательно иметь как можно больше регистров и режимов адресации (CISC - подход). +- Размер регистрового файла и размер поля режима адресации влияют на размер средней инструкции и на размер средней программы в целом. +- Желательно ограничить длину кода инструкции ради эффективной обработки при реализации (как минимум должна быть целым числом байт). +- Фиксированная длина - работает быстрее и проще реализовывается аппаратно. +- Переменная длина - позволяет уменьшить средний размер инструкции. +- Гибридная. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/3.md new file mode 100644 index 0000000..db66266 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/3.md @@ -0,0 +1,18 @@ +#### Определение и особенности CISC и RISC + +**Сложная система команд (CISC)** +- Нефиксированное значение длины команды. +- Арифметические действия кодируются в одной команде. +- Небольшое число регистров, каждый из которых выполняет строго определенную функцию. +- Акцент: больше работы на каждую команду. +- Мотив: высокая цена оперативной и дисковой памяти в то время, когда CISC возникли (1980). + +**Сокращенный набор команд (RISC)** +- Фокусируется на уменьшении числа и сложности инструкций ISA. +- Уменьшенное CPI (Цель: 1 инструкция за такт). +- Разработан с учетом конвейерности процессора. +- Фиксированная длина кода инструкций. +- Только инструкции load и store обращаются к памяти. +- Ограничены количеством и сложностью режимов адресации. +- Задержанные загрузки и ветвления. +- Упреждающая выборка инструкций и спекулятивное исполнение. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5.5 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5.5 билет/1.md new file mode 100644 index 0000000..ca13dc4 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5.5 билет/1.md @@ -0,0 +1,59 @@ +Конечно! Вот билеты с 5.5 по 10, написанные слово в слово, как в файле, для использования в Obsidian: + +--- + +### Билет 5.5: Архитектура RISC-V + +#### Набор инструкций RISC-V (базовые наборы, расширения, профили) + +Беда старых архитектур: было введено огромное множество команд и инструкций, которые не могут быть удалены из-за большого количества программ, использующих их. + +- **Базовый целочисленный набор команд:** + +Обязательная часть архитектуры, на выбор: + +- **RV32I** - 35 инструкций для работы с 32-бит. целыми и 32-бит. адресами +- **RV32E** - вариация RV32I с урезанным количеством регистров общего назначения +- **RV64I** - набор команд для поддержки 64-бит. целых и 64-бит. адресов +- **RV64E** - вариация RV64I с урезанным количеством регистров общего назначения +- **RV128I** - набор команд для поддержки расширенных целых и 128-бит. адресов. Доп. набор, для которого нет окончательного стандарта, есть только предварительный стандарт для 128-бит. адресов. + +- **Расширения:** + +В архитектуру заложена возможность реализации собственных расширений и встраивания их. Проработана на уровне архитектуры, ОС и стандартной библиотеки. Можно реализовать собственное расширение, встроить в железо и применять в своих приложениях на linux. +Самые важные имеют кодировку одной буквой: + +- **М** - умножение и деление целых чисел +- **А** - атомарные инструкции, требуются для работы в concurrent системах, где реализована многопоточность или многоядерность/многопроцессорность. +- **F, D, Q** - инструкции для работы с FP числами одинарной, двойной и учетверенной точности. +- **C** - «сжатые» инструкции (весят 2 байта вместо 4). +- **V** - векторные инструкции (сильно повышают количество операций в секунду). +- **В** - битовые манипуляции. + +Стандартизированные расширения начинаются с "Z": + +- **Zicsr** - Control and Status Register (CSR) Instructions. +- **Zifencei** - инструкция FENCE.I (Instruction-Fetch Fence). +- **Zam** - атомарные операции с невыровненными адресами. Обращение по невыровненным адресам медленнее, чем по выровненным. +- **Ztso** - глобальное упорядочивание сохранения в память + +Расширения уровня супервизора начинаются с "S": + +- **Svinval** - Fast TLB invalidation. + +Нестандартные (пользовательские) расширения начинаются с "X" +"General-Purpose" ISA: base ISA (RV32I or RV64I) + IMAFD + Zicsr + Zifencei + +- **Профили:** + +Профиль - стандартизированный набор основной архитектуры расширений, который рекомендуется для реализации и поддержки. +Профиль: стандартная базовая ISA + набор обязательных расширений + небольшой набор стандартных опций для расширения обязательных компонентов. + +Определяют гораздо меньший общий набор вариантов ISA, которые приносят наибольшую пользу большинству пользователей. +Состав профиля: + +- **Profile Family** +- **Profile Privilege Mode** +- **Profile ISA Features** + +Пример: RVA22U64 = base RV64I + Mandatory MAFDC, Zicsr, Zifencei, Zihpm, ... + Optional Zfh, V, Zkn, Zks. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5.5 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5.5 билет/2.md new file mode 100644 index 0000000..35b654f --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/5.5 билет/2.md @@ -0,0 +1,26 @@ +#### Программируемые места хранения + +**Типы регистров:** + +1) **Целочисленные регистры** +x0 - константа 0; x1 - return address; x2 - stack pointer; x3 - global pointer; +x4-thread pointer ; x5-x7, x28-x31 - временные; x8-x9, x18-x27 - сохраняемые при вызове; +$x10-x17$ - argument registers; +2) **Вещественные регистры** +f0-f7, f28-f31 - временные; f8-f9, f18-f27 - сохраняемые при вызове; f10-f17 - параметры и возвращаемые значения; +3) **Векторные регистры** +v0-v31- временные; vl - vector length; vtype - vector datatype register; vxrm - vector fixed-point rounding mode register; vxsat - vector fixed-piont saturation flag register; vcsr - vector control and status register; vlenb - vector register length in bytes; vstart- vector start position; +**Особенности использования векторных регистров:** + +- Векторные регистры появятся дополнительно при использовании векторных инструкций. +- Длина зависит от инструкции (умолч. 128 бит) +- Можно выполнять работы как над вектором, так и над какой-то из частей. +- Вектора могут объединяться для формирования более длинных векторов. + +**Формат представления команд:** + +- **R (Register)** - «регистр-регистр-регистр» +- **I (Immediate)** - «непосредственное значение - регистр - регистр» +- **S (Store)** - «регистр-регистр-непосредственное значение». $1^{й}$ регистр - источник, который сохраняется в память, $2^{й}$ регистр и непосредств. значение используют для формирования адреса. +- **U (Upper)** - «непосредственное значение - регистр». Используется, когда возможно взять адрес следующей выполняемой инструкции. +Стадия декодирования облегчена максимально: анализируем битовые поля и отправляем в известные позиции на промежуточном регистре перед след. стадией. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/1.md new file mode 100644 index 0000000..40e44b4 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/1.md @@ -0,0 +1,21 @@ +#### Принцип конвейерной обработки инструкций. Определение ступени/стадии конвейера. Ступени конвейера MIPS (пример-иллюстрация). + +Конвейерная обработка инструкций - метод реализации CPU, при котором множество операции над несколькими инструкциями перекрываются. + +- Конвейер, исполняющий инструкцию, состоит из множества шагов, где на каждом завершается этап обработки инструкции. Каждый шаг называется ступенью конвейера или стадией конвейера. +- Ступени и стадии конвейера соединены линейным образом: инструкции входят с одного конца, проходят по ступеням и выходят на другом конце. +- Конвейеризация не сокращает время выполнения отдельной инструкции. + +- **Ступени конвейера MIPS:** + +**IF (Instruction Fetch)** - выборка инструкций. +**ID (Instruction Decode)** - декодирование инструкции +**EX (Execution)** - исполнение. +**MEM (MEMory Access)** - обращение к памяти. +**WB (Write Back)** - запись рез-та. Имеется в виду запись в регистр. +![](../data/4.png) +![Ступени конвейера MIPS](../data/3.png) + +Число тактов до заполнения = время разгона = число ступеней -1 +Время разгона $=4$ такта $\mathrm{CPI}=\frac{9}{5}=1.8$ +Идеальное CPI $=1$. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/2.md new file mode 100644 index 0000000..262d1b8 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/2.md @@ -0,0 +1,7 @@ +#### Латентность и пропускная способность (+определение). + +**Латентность** - время, требуемое для завершения всех шагов по обработке инструкции (время задержки завершения инструкции). + +Мин. время задержки завершения инструкции равно числу ступеней конвейера. +Конвейеризация увеличивает пропускную способность CPU. +**Пропускная способность** - среднее число инструкций, завершенных за такт. Величина, обратная СРІ. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/3.md new file mode 100644 index 0000000..7ea9bc3 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/3.md @@ -0,0 +1,8 @@ +#### Упорядоченный конвейер команд (+определение). + +Вышеописанный конвейер - упорядоченный. + +**Упорядоченный конвейер** - конвейер, где инструкции выполняются в порядке, указанном в исходной программе. + +Время перемещения инструкции на один шаг дальше по конвейеру равно 1 такту. +Длительность такта определяется ступенью с наиб. временем обработки. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/4.md new file mode 100644 index 0000000..637e208 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/4.md @@ -0,0 +1,17 @@ +#### Производительность CPU с конвейером по сравнению с CPU без конвейера. + +В идеальном случае (без тактов простоя) происходит завершение $1^{nd}$ инструкции за машинный такт, т.е. идеальное $\mathrm{CPI}=1$. + +- **CPU без конвейера:** + +Время такта $=1$ нс +4 такта для ALU и переходов. 5 тактов для операций с памятью. +Соотношение ALU:переходы:память $=40: 20: 40$ +Среднее время выполнения инструкции без конвейера = время такта $\times$ среднее CPI $=$ $=1 \mathrm{нc} \times((0.4+0.2) \times 4+0.4 \times 5)=1 \mathrm{нc} \times 4.4=4.4 \mathrm{нc}$. + +- **СRU с конвейером:** + +Время такта $=1$ нс +0.2 нс (за счет конвейеризации) +5 ступеней используются со средним временем выполнения 1.2 нс. +$\mathrm{CPI}=1$ +Ускорение $=\frac{\text { время без конвейера }}{\text { время с конвейером }}=\frac{4.4 \mathrm{нc}}{1.2 \mathrm{нc}}=3.7$ раз \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/1.md new file mode 100644 index 0000000..d525878 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/1.md @@ -0,0 +1,7 @@ +#### Определение конфликта. + +**Конфликт** - такая ситуация в конвейерной обработке, которая препятствует выполнению очередной команды в предназначенном для нее такте. + +Конфликт может привести к $\geq 1$ тактам простоя или ожидания (stalls). +Конфликты уменьшают идеальное время конвейера, повышая CPI (CPI $>1$ ). +Приводят к необходимости приостановки выполнения команд. Обычно в простейших конвейерах, если приостанавливается какая-либо команда, то все след. за ней тоже приостанавливаются, не выбирается ни одна новая команда. Команды, предшествующие приостановленной, могут продолжать выполнение. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/2.md new file mode 100644 index 0000000..10dd30e --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/2.md @@ -0,0 +1,11 @@ +#### Классификация конфликтов (определения: структурные конфликты, конфликты данных, конфликты управления). Обработка конфликтов. + +1) **Структурные конфликты (IF/MEM)** + +Возникают из-за недостатка аппаратных ресурсов, когда доступное аппаратное обеспечение не в состоянии поддерживать исполнение всех возможных комбинаций инструкций. +2) **Конфликты данных (RAW, WAW, WAR, RAR)** + +Возникают, когда инструкция зависит от рез-та выполнения предыдущей инструкции таким образом, что это проявляется при перекрытии инструкций в конвейере. +3) **Конфликты управления (JMP, J??, CALL, RET)** + +Возникают при конвейеризации условных переходов и др. инструкций, которые изменяют IP/PC. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/3.md new file mode 100644 index 0000000..942be96 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/3.md @@ -0,0 +1,19 @@ +#### Причина возникновения структурных конфликтов. Изменение СРІ из-за структурных конфликтов. + +Причиной возникновения структурного конфликта может быть: +a. **Не полностью конвейеризованная структура процессора.** + +Некоторые стадии отдельных команд могут выполняться более $1^{го}$ такта. В этом случае последовательные команды, которые используют данное функц. устройство, не могут поступать в него в каждом такте. +b. **Недостаточное дублирование некоторых ресурсов.** + +Препятствует выполнению произвольной последовательности команд в конвейере без его приостановки. Например, машина может иметь только 1 порт записи в регистровый файл, но конвейеру может потребоваться выполнить 2 записи в регистровый файл в $1^{ом}$ такте. +с. **Общая память для инструкций и данных, и единственный порт памяти.** + +Когда одна команда содержит обращение к памяти за данными, оно будет конфликтовать с выборкой более поздней команды из памяти. Чтобы разрешить эту ситуацию, можно просто приостановить конвейер на 1 такт, когда происходит обращение к памяти за данными. Это конвейерный пузырь. + +CPI = идеальное CPI + средн. число тактов простоя на инструкцию. +Но простои из-за разных конфликтов могут накладываться. +В случае с структурным конфликтом при обращении к памяти (простой 1 такт), если обращение к памяти составит 40\% для некоторой программы, то без учета других потерь производительности: + +CPI $=(1+0.4) \times$ CPI идеальное +Т.е. CPU без структурного конфликта в 1.4 раза быстрее. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/1.md new file mode 100644 index 0000000..2310426 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/1.md @@ -0,0 +1,9 @@ +#### Определение и причина возникновения конфликтов данных. Определение параллелизма на уровне инструкций (ILP). + +**Конфликты данных** возникают, когда инструкция зависит от рез-та выполнения предыдущей инструкции таким образом, что это проявляется при перекрытии инструкций в конвейере. +Происходят, когда рез-тат предыдущей инструкции, от которой зависит данная, неизвестен вовремя, или когда в конвейере меняется порядок чтения/записи операндов так, что результирующий порядок доступа отличается от исходного порядка доступа к операндам на машине без конвейера, что может привести к некорректному рез-ту выполнения программы. +ADD R1, R2, R1; +SUB зависит от ADD. +SUB R3, R1, R3; +**Распараллеливаемые (независимые)** - инструкции, не имеющие между собой зависимостей. +**Высокая степень параллелизма на уровне инструкций (Instruction Level Parallelism, ILP)** - присутствует в заданной последовательности команд, если она имеет большое число распараллеливаемых инструкций. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/2.md new file mode 100644 index 0000000..16db55c --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/2.md @@ -0,0 +1,7 @@ +#### Пересылка данных (Forwarding). + +**Пересылка данных (Forwarding)** - аппаратный метод, также называемый обходом регистров (register bypassing) или закорачиванием (short-circuiting), используемый для исключения или минимизации простоев изза конфликтов данных. + +- Рез-тат выполнения инструкции пересылывается напрямую из места, где он был получен, туда, где он нужен последующим инструкциям. +- Рез-тат ALU из буферного регистра EX/MEM может перенаправлен к входным триггерам ALU вместо записи и последующего чтения операнда из регистра на ступени ID. +- Рез-тат чтения данных из памяти из буферного регистра MEM/WB может перенаправлен на входные триггеры ALU. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/3.md new file mode 100644 index 0000000..1c5b84d --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/3.md @@ -0,0 +1,26 @@ +#### Классификация конфликтов данных (RAW/WAW/WAR/RAR). + +Пусть А стоит раньше В в потоке инструкций. + +- **RAW (Read After Write)** - истинная зависимость по данным. +![WAW](../data/5.png) + +В пытается читать операнд-источник данных прежде, чем А туда пишет, поэтому В получает неправильное значение (старое). +A (Write) +Data +B (Read) $\star$ + +- **WAW (Write After Write)** - зависимость по именам регистров. + +В пытается записать операнд прежде, чем он записан A, т.е запись происходит в неправильном порядке. + +![WAW](../data/6.png) + +- **WAR (Write After Read)** - зависимость по именам регистров. +![WAW](../data/7.png) + +В пытается записать результат в приемник прежде, чем он считывается A, поэтому А получает неправильное значение (новое). +A (Read) $\qquad$ +B (Write) $\qquad$ Data + +- **RAR (Read After Read)** - нет конфликта. diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/4.md new file mode 100644 index 0000000..56bcb7f --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/4.md @@ -0,0 +1,3 @@ +#### Обработка конфликтов данных в конвейере. + +??? \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/5.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/5.md new file mode 100644 index 0000000..68a1198 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/5.md @@ -0,0 +1,6 @@ +#### Статическое планирование инструкций. + +**Цель:** избегание или сокращение числа тактов простоя. +**Метод:** переупорядочивание или планирование инструкций - изменение последовательности исполнения инструкций с целью избегания или сокращения числа тактов простоя. +**Статическое планирование** - производится компилятором во время компиляции программы. +**Динамическое планирование** - производится CPU во время исполнения программы. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/1.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/1.md new file mode 100644 index 0000000..8fc2f12 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/1.md @@ -0,0 +1,9 @@ + +#### Определение и причина возникновения конфликтов управления. + +**Конфликты управления** возникают, когда неизвестен вовремя адрес след. исполняемой инструкции. Конфликт имеет место при выполнении любой управляющей инструкции. + +- При выполнении условного перехода может измениться Instruction Pointer. + +Для корректной обработки требуется остановить конвейер на много тактов, пока не будет вычислено условие перехода и определится направление перехода, иначе IP может неверным, когда потребуется на ступени IF. + diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/2.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/2.md new file mode 100644 index 0000000..15f4bf6 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/2.md @@ -0,0 +1,16 @@ +#### Аппаратные способы сокращения числа тактов простоя (+пример). + +1) Как можно раньше выяснить, выполняется ли переход +2) Как можно раньше вычислить адрес следующей исполняемой инструкции. + +**Пример.** В рассматриваемом примере (MIPS): + +- Инструкции условного перехода проверяют значение регистра на равенство 0. + +Это действие можно завершить в такте ID, перемещая проверку на этот такт. + +- Оба IP (выбранный и невыбранный) должны быть вычислены заранее. + +Требуется доп. сумматор, тк имеющееся ALU не может использовано до такта EX +В таком случае будет только 1 такт простоя при переходах. + diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/3.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/3.md new file mode 100644 index 0000000..8c8a0d8 --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/3.md @@ -0,0 +1,33 @@ + +#### Статические методы обработки условных переходов. + +**Задержанный/отложенный переход** - инструкция, след. после перехода (из слота задержки перехода) исполняется независимо от того, произошел переход или нет (введена частью ISA). + +- **Предположение, что переход никогда не происходит.** + +Продолжается выполнение инструкций, начиная с инструкции, след. за инструкцией перехода, но состояние машины не меняется до тех пор, пока рез-тат перехода точно не определен. Если переход не произошел - состояние сохраняется, если произошел - рез-таты отбрасываются, фактически произошел простой. + +- **Предположение, что переход всегда происходит.** + +Продолжается выполнение инструкций, начиная с места перехода, ... +Труднее реализовать, чем предыдущий вариант. + +**Пример: схема предсказания «переход не произойдет»:** + +**Переход не произошел, нет простоя:** + +| I (untaken branch instruction) | IF | ID | EX | MEM | WB | | | | | +| :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | +| I+1 | | IF | ID | EX | MEM | WB | | | | +| I+2 | | | IF | ID | EX | MEM | WB | | | +| I+3 | | | | IF | ID | EX | MEM | WB | | +| I+4 | | | | | IF | ID | EX | MEM | WB | + +**Переход произошел, простой:** + +| I (taken branch instruction) | IF | ID | EX | MEM | WB | | | | | +| :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | :-- | +| I+1 | | IF | Idle | Idle | Idle | idle | | | | +| Branch target | | | IF | ID | EX | MEM | WB | | | +| Branch target +1 | | | | IF | ID | EX | MEM | WB | | +| Branch target +2 | | | | | IF | ID | EX | MEM | WB | diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/4.md b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/4.md new file mode 100644 index 0000000..adaf24d --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/4.md @@ -0,0 +1,16 @@ +#### Статическое предсказание переходов. + +- Выполняется компилятором. +- Кодируется в инструкциях условного перехода, используя один бит предсказания. + +Например: 0 - переход обычно не происходит, 1 - происходит. + +- Требует поддержки на уровне ISA. + +**Два основных метода статич. предсказания переходов на этапе компиляции:** + +- **Сбор информации о поведении программы при ее запусках и ее использование при перекомпиляции (профилирование).** +Например: профиль программы может показать, что большинство условных переходов вперед и назад (часто вызвано циклами) происходят. В данном случае нужно всегда предсказывать, что переход происходит. +- **Эвристическое предсказания переходов на основе направления перехода.** + +Например: помечая переходы назад как происходящие и переходы вперед как не происходящие. \ No newline at end of file diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/1.png b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/1.png new file mode 100644 index 0000000..44e8f5d Binary files /dev/null and b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/1.png differ diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/2.png b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/2.png new file mode 100644 index 0000000..7aa6557 Binary files /dev/null and b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/2.png differ diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/3.png b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/3.png new file mode 100644 index 0000000..2a5b536 Binary files /dev/null and b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/3.png differ diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/4.png b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/4.png new file mode 100644 index 0000000..90a5f9e Binary files /dev/null and b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/4.png differ diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/5.png b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/5.png new file mode 100644 index 0000000..398bc9a Binary files /dev/null and b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/5.png differ diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/6.png b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/6.png new file mode 100644 index 0000000..c3e1b4f Binary files /dev/null and b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/6.png differ diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/7.png b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/7.png new file mode 100644 index 0000000..ed1becc Binary files /dev/null and b/2 курс/1 семестр/Архитектура ЭВМ/Лекции/data/7.png differ diff --git a/2 курс/1 семестр/Архитектура ЭВМ/Темы.md b/2 курс/1 семестр/Архитектура ЭВМ/Темы.md new file mode 100644 index 0000000..0c0f44d --- /dev/null +++ b/2 курс/1 семестр/Архитектура ЭВМ/Темы.md @@ -0,0 +1,92 @@ +1. Уровни абстракции электронной вычислительной системы. Фон Неймановская модель компьютера. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/1|– Перечисление уровней с указанием формируемых абстракций. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/2|– Фон Неймановская модель компьютера (4 идеи, диаграмма). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/1 билет/3|– Шаги обработки инструкций в CPU. ]] +2. Оценка производительности CPU +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/1|– Определение микрооперации. Определение "среднее CPI программы". ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/2|– Уравнение производительности CPU. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/2 билет/3|– Факторы, влияющие на производительность CPU (описание влияния на параметры уравнения). ]] +3. Оценка производительности вычислительной системы +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/3 билет/1|– Список метрик производительности. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/3 билет/2|– Типы программ для оценки производительности. Применимость каждого типа. ]] +4. Классификация архитектур систем команд (Instruction Set Architecture, ISA) по способу адресации операндов. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/1|– Определение ISA. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/2|– Описание архитектур, использующих различные программируемые места хранения: Memory-To-Memory; 0- адресная; 1-адресная; с регистрами общего назначения. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/3|– Режимы адресации. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/4 билет/4|– Архитектуры Load-Store/Register-To-Register. ]] +5. Набор инструкций Архитектуры системы команд (Instruction Set Architecture, ISA). +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/1|– Перечисление типов команд с кратким описанием и примерами: команды перемещения данных, арифметико-логических операций, управления порядком выполнения программы и т.д. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/2|– Кодирование инструкций. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/5 билет/3|– Определение и особенности CISC и RISC. ]] + 5.5 Архитектура RISC-V +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/5.5 билет/1|– Набор инструкций RISC-V (базовые наборы, расширения, профили). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/5.5 билет/2|– Программируемые места хранения (типы регистров, особенности использования векторных регистров, способы формирования адреса). ]] +6. Однопортовый упорядоченный конвейер команд (in-order pipeline) +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/1|– Принцип конвейерной обработки инструкций. Определение ступени/стадии конвейера. Ступени конвейера MIPS (пример-иллюстрация).]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/2|– Латентность и пропускная способность (+определение). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/3|– Упорядоченный конвейер команд (+определение). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/6 билет/4|– Производительность CPU c конвейером по сравнению с CPU без конвейера. ]] +7. Конфликты в конвейере. Структурные конфликты. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/1|– Определение конфликта. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/2|– Классификация конфликтов (определения: структурные конфликты, конфликты данных, конфликты управления). Обработка конфликтов. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/7 билет/3|– Причина возникновения структурных конфликтов. Изменение CPI из-за структурных конфликтов. ]] +8. Конфликты данных в конвейере. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/1|– Определение и причина возникновения конфликтов данных. Определение параллелизма на уровне инструкций (ILP). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/2|– Пересылка данных (Forwarding). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/3|– Классификация конфликтов данных (RAW/WAW/WAR/RAR). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/4|– Обработка конфликтов данных в конвейере. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/8 билет/5|– Статическое планирование инструкций. ]] +9. Конфликты управления в конвейере. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/1|– Определение и причина возникновения конфликтов управления. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/2|– Аппаратные способы сокращения числа тактов простоя (+пример). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/3|– Статические методы обработки условных переходов. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/9 билет/4|– Статическое предсказание переходов. ]] +10. Использование параллелизма уровня инструкций (Instruction-Level Parallelism, ILP). +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/1|– Определение параллелизма уровня инструкций (ILP). Определение базового блока инструкций. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/2|– Статическая оптимизация с разворачиванием циклов. Требования к разворачиванию циклов. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/10 билет/3|– Пример разворачивания цикла. ]] +11. Взаимозависимости между инструкциями +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/1|– Классификация зависимостей между инструкциями (по данным, по именам, по управлению). ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/2|– Истинная зависимость по данным, антизависимость, выходная зависимость. Граф зависимостей.]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/11 билет/3|– Зависимость по управлению. ]] +12. Расширение конвейера для обработки вещественных операций. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/1|– Отличия от конвейера без обработки вещественных операций. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/2|– Определения задержки и периода запуска. Конвейеризуемые и неконвейеризуемые функциональные блоки. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/12 билет/3|– Характеристики конвейера с поддержкой вещественных операций.]] +13. Динамическое планирование с помощью Табло. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/1|– Определение динамического планирования. Принципы реализации динамического планирования. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/2|– Определение табло. Структура табло и контролируемые параметры. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/3|– Ступени конвейера, использующего табло. Обработка инструкции на различных ступенях. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/13 билет/4|– Пример обработки участка кода. ]] +14. Динамическое планирование с использованием алгоритма Томасуло. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/1|– Определение динамического планирования. Принципы реализации динамического планирования. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/2|– Принципы работы алгоритма Томасуло. “Станции резервации”(reservation stations), переименование регистров, общая шина данных (Common Data Bus, CDB). Поля станций резервации. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/3|– Ступени конвейера, использующего алгоритм Томасуло. Обработка инструкции на различных ступенях. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/14 билет/4|– Пример обработки участка кода. ]] +15. Суперскалярность. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/1|– Принцип и цель суперскалярности. Характерные особенности применения. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/2|– Простейшая реализация суперскалярности (x2). Пример.]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/3|– Динамическое планирование при суперскалярности. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/15 билет/4|– Масштабируемость и перспективы суперскалярности. ]] +16. Динамическое предсказание ветвлений микропроцессором. Буфер целей переходов (Branch Target Buffer, BTB). Буфер предсказания ветвлений (Branch History Table, BHT или Pattern History Table, PHT). Алгоритм Смита. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/1|– Определение динамического предсказания ветвлений. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/2|– Структура BTB. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/3|– Алгоритм заполнения и использования BTB. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/16 билет/4|– Структура PHT. Алгоритм изменения и использования. Интерференция адресов. Структура BHT. ]] +17. Динамическое предсказание ветвлений микропроцессором. Двухуровневый механизм динамического предсказания ветвлений с учетом корреляции (GAp). Схема MCFarling’а gshare. Гибридные предсказатели. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/1|– Определение динамического предсказания ветвлений. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/2|– Описание двухуровневого механизма динамического предсказания ветвлений с учетом корреляции. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/3|– Схема MCFarling’а gshare. Преимущества схемы. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/17 билет/4|– Определение и принцип работы гибридных/турнирных/комбинированных предсказателей. ]] +18. Кэш. Основные понятия и определения. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/1|– Определение кэша и кэширования. Уровни иерархии памяти. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/2|– Определения: блок, попадание, частота попаданий, время попадания, промах, частота промахов, штраф за промах. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/18 билет/3|– Принцип локальности. Два вида локальности. ]] +19. Организация кэша. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/19 билет/1|– Кэш прямого отображения(Direct mapped cache). Поля строки/блока кэша. Проецирующая функция. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/19 билет/2|– Наборно-ассоциативный кэш (Set associative cache), полностью ассоциативный кэш (Fully associative cache). ]] +20. Политика замещения в кэше. Уменьшение кэш-промахов. Стратегии записи в кэш. +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/1|– Политики замещения Random, LRU, FIFO. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/2|– Причины кэш-промахов. Уменьшение частоты промахов: дополнительный кэш «жертв», разделение кэша прямого доступа на 2 части, программная предвыборка данных, аппаратная предвыборка команд и данных. ]] +[[2 курс/1 семестр/Архитектура ЭВМ/Лекции/20 билет/3|– Описание стратегий записи в кэш Write Through и Write Back. ]] +21. [[2 курс/1 семестр/Архитектура ЭВМ/Лекции/21|Векторные инструкции. Понятие вектора и векторных операций. Способы использования векторных операций. ]] \ No newline at end of file