Compare commits
4 Commits
870a2efa6e
...
master
| Author | SHA1 | Date | |
|---|---|---|---|
| a4a837cf45 | |||
| 1b7a10d5bd | |||
| 0c9a61e05a | |||
| d10401ed01 |
18
.gitea/PULL_REQUEST_TEMPLATE.md
Normal file
18
.gitea/PULL_REQUEST_TEMPLATE.md
Normal file
@ -0,0 +1,18 @@
|
||||
---
|
||||
|
||||
name: "Билет"
|
||||
about: "Шаблон для билета"
|
||||
title: "XX - Название билета"
|
||||
ref: "main"
|
||||
|
||||
---
|
||||
|
||||
# XX - Название билета
|
||||
|
||||
- [ ] Раздел билета 1
|
||||
- [ ] Раздел билета 2
|
||||
- [ ] Раздел билета 3
|
||||
|
||||
---
|
||||
|
||||
> your joke goes here
|
||||
@ -4,15 +4,92 @@ tags:
|
||||
---
|
||||
# Соглашения о вкладе
|
||||
|
||||
## Стиль билетов
|
||||
|
||||
> [!attention]+ Основное требование к билету
|
||||
>**НЕ ПРОСТО ПЕРЕПИСЫВАЙТЕ МЕТОДИЧКУ СЛОВО В СЛОВО**: старайтесь ужать материал и сделать его как можно понятнее
|
||||
|
||||
*Иначе смысла в написании билетов нет ни для вас, ни для человека, который может их почитать. Разбиение методички на билеты - не самая важная часть нашей деятельности*
|
||||
|
||||
При написании билетов я предполагаю, что пользователь сидит в режиме чтения
|
||||
### Объем билетов
|
||||
|
||||
Довольно очевидно, что билеты должны быть максимально короткими, чтобы человек не учил то, что может не учить, но при этом они не должны быть невнятными. Старайтесь выдерживать золотую середину между читаемостью и объемом
|
||||
|
||||
Периодически в билете требуется пояснить моменты, которые вообще говоря не надо запоминать и они не связаны с ответом, но они помогают пониманию билета. В таком случае я обычно пишу что-то вроде:
|
||||
|
||||
> [!comment]- Примечание билетера о ...
|
||||
> Какое-то пояснение, которое я считаю важным дать, но которое не важно во время ответа
|
||||
|
||||
Оформляется оно при помощи коллаутов примерно так:
|
||||
|
||||
```md
|
||||
> [!comment]- Примечание билетёра о ...
|
||||
> lorem ipsum dolor sit amet
|
||||
```
|
||||
|
||||
Также считаю допустимым использование примечаний^[Это примечание отобразится в конце страницы и не будет так сильно отвлекать от билета]. Они автоматически складываются в конце страницы и при наведении на них всплывает подсказка, что тоже довольно удобно для пояснений
|
||||
|
||||
## Шаблоны
|
||||
|
||||
У нас есть 2 шаблона. Фактически стандартизируют они только подложку заметки:
|
||||
|
||||
- Билет - содержит поля под:
|
||||
- теги
|
||||
- [[#Закон каламбура|каламбур]]
|
||||
- автора (указываете свой ник или как вам удобно представиться)
|
||||
- ревизию (это поле для ElectronixTM, потому что его попросили верифицировать все написанное. Он укажет туда информацию о ревизии)
|
||||
- Заметка - просто любая заметка на ваш вкус, которая может содержать дополнительную информацию, которая не идет в билеты. Для первых 4 билетов в таких написаны конспекты некоторых разделов билетов
|
||||
|
||||
## Дирректории
|
||||
|
||||
В проекте у нас есть главная папка: "Билеты". Пояснять, думаю, не надо, а также папка: "Дополнительно". В папку дополнительно идет все, что только пожелаете. В этой папке есть еще и digital garden - можете погуглить "второй мозг", "zettelkasten" и "commonplace". У меня была идея с этим что-то придумать, но как бы не вышло, но может вы захотите хранить такие вот атомизированные заметки в каком-то месте
|
||||
|
||||
## Именование файлов
|
||||
|
||||
Все названия файлов подчиняются следующему шаблону: `xx - название`. Тут все стандартно как с физикой
|
||||
|
||||
## Ветки
|
||||
|
||||
Так как я больше не один, надо бы по веточкам работать. Именование веток довольно произвольное. Обойдемся стандартным набором, только модифицируем его:
|
||||
|
||||
- `feat` - под всё новое
|
||||
- `feat/tickets/xx` - Написание нового билета должно проходить именно в таких ветках
|
||||
- `fix` - какие-то исправления в уже написанном материале
|
||||
- `other` - все, что не подвязывается к первым двум
|
||||
|
||||
Пул реквесты можете делать, но тогда сразу назначайте человека, который будет вас проверять, а потом желательно сразу же ему писать в личку (благо все свои). Если что, можете сразу мерджить изменения в мастер, тут расчет на вашу адекватность
|
||||
|
||||
## Коммиты
|
||||
|
||||
Тут все по стандарту conventional commits. Все сообщения к коммитам пишутся на русском, с маркерами:
|
||||
|
||||
1. `feat` - сделал что-то новое
|
||||
2. `fix` - починил что-то старое
|
||||
3. `chore` - убирание тегов, изменение названий, в общем всякая мелочь
|
||||
|
||||
### Примеры
|
||||
|
||||
- `feat: написал конспект 3 главы 3.2 раздела`
|
||||
- `chore: удалил тег "в процессе"`
|
||||
|
||||
*Просьба просто в том, чтобы человек не открывая коммит мог получить представление о том, что вы там сделали, так что не надо чего-то вроде: fix, fix, fix, fix*
|
||||
|
||||
## Разрешенные плагины для Obsidian
|
||||
|
||||
В [[README]] я уже говорил, что все билеты пишутся под Obsidian, а поскольку он поддерживает разные плагины, есть соблазн поставить парочку. В связи с этим регулировка такая:
|
||||
|
||||
- Разрешены любые плагины до тех пор, пока все, что вами написано, нормально рендерится в ванильном обсидиане без единого плагина.
|
||||
|
||||
Может закон и не точный, но и мы не на уроке права, поэтому поясню мысль и буду надеяться на благоразумие:
|
||||
|
||||
Мы уже предъявляем определенные требования к пользователю - он должен открывать этот проект непременно в обсидиане. Так давайте же уважим его и не будем заставлять еще и скачивать плагины
|
||||
|
||||
## Использование тегов
|
||||
|
||||
Я отхожу от своей классической практики помечать тегами только служебную информацию о заметках и даю возможность использовать предметные теги на свое усмотрение на следующих условиях:
|
||||
|
||||
- Обязательно проверьте, какие теги уже существуют. Сделать это можно при помощи скрипта, который тут приложен
|
||||
- Обязательно проверьте, какие теги уже существуют
|
||||
- Есть небольшой набор служебных тегов, которые призваны помогать искать недоделки и недоработки
|
||||
|
||||
### Стиль тегов
|
||||
@ -22,15 +99,19 @@ tags:
|
||||
- `#математика`
|
||||
- `#русский_язык`
|
||||
|
||||
Также Obsidian из коробки поддерживает вложенные теги: `#это/пример/вложенного/тега`
|
||||
|
||||
ограничения те же, что и на все остальные теги
|
||||
### Служебные теги
|
||||
|
||||
Все служебные заметки начинаются со специальной комбинации `#служебное/`
|
||||
|
||||
- #служебное/доработать - заметка в целом закончена, но нужно внести некоторые доработки
|
||||
- #служебное/в_процессе - заметка по каким-то причинам отложена и не закончена
|
||||
- #служебное/в_процессе - заметка еще пишется, а это промежуточный результат работы
|
||||
- #служебное/устарело - Препод поменял билеты, поэтому то, что было написано, не совсем актуально. Все, что не актуально, и еще не пересмотрено помечается деприкейтится этой меткой
|
||||
|
||||
Эти теги служат только для передачи служебной информации о состоянии заметки
|
||||
|
||||
## Политика каламбуров
|
||||
## Закон каламбура
|
||||
|
||||
Каждый билет должен сопровождаться каламбуром. Эти каламбуры вставляются в подложку заметки
|
||||
Каждый билет должен сопровождаться каламбуром. Эти каламбуры вставляются в подложку заметки. Тема не важна, но это должен быть обязательно **каламбур**
|
||||
|
||||
@ -36,4 +36,6 @@ pun: "Как называют человека, который пожертво
|
||||
|
||||
# Устройство управления
|
||||
|
||||
![[Глава 3. Процессор#Устройство управления]]
|
||||
^a29a65
|
||||
|
||||
![[Глава 3. Процессор#Устройство управления]] ^522375
|
||||
@ -1,5 +1,92 @@
|
||||
---
|
||||
tags:
|
||||
- служебное/в_процессе
|
||||
- служебное/доработать
|
||||
pun: Пуля, попавшая в школьного учителя, вышла и зашла как положено
|
||||
---
|
||||
## Устройство управления
|
||||
|
||||
Если вы не помните про то, как микропрограммный автомат связан с устройством управления, перечитайте прошлый билет, а точнее его [[03 - Схема процессора (схема). Выполнение команд процессором. Операционные устройства. Типы операционных устройств с магистральной структурой. Устройство управления#^a29a65|последний абзац]]
|
||||
|
||||
## Микропрограммирование команд
|
||||
|
||||
Есть 2 основных вида микропрограммных автоматов, по названиям которых дается название всему УУ.
|
||||
|
||||
![[Глава 3. Процессор#^CU-types-list]]
|
||||
|
||||
Первый один раз и на века спаивается производителем (подробнее можно почитать [[Глава 3. Процессор#^846e1e|тут]]), его, как понимаете, не покодишь, а вот второй вполне можно.
|
||||
|
||||
*Я кратко резюмирую написанное [[Глава 3. Процессор#Микропрограммный автомат с программируемой логикой|тут]]*
|
||||
|
||||
Микрокоманды разбивают большую команду (`add rax, [rbx + 4 * rcx - 40]`) на маленькие шаги, чтобы не приходилось вообще все опкоды реализовывать аппаратно, это позволяло в свое время не слабо экономить на аппаратных частях процессора. Реализация примерно такая:
|
||||
|
||||
![[Глава 3. Процессор#^struct-image]]
|
||||
|
||||
![[Глава 3. Процессор#^f2908e]]
|
||||
|
||||
## Структура процессора с 3 шинами
|
||||
|
||||
*будет еще раз затронута при микропрограммировании, но раз препод расставил вопросы в таком порядке, приведу ее и тут*
|
||||
|
||||
![[Глава 3. Процессор#^b0a065]]
|
||||
|
||||
Запоминать эту радость надо, видимо, наизусть, но попытаюсь облегчить это дело, сдобрив пониманием:
|
||||
|
||||
> [!comment]- Примечение билетёра о том, почему модель такая, какая она есть
|
||||
> **Можете не читать это, а просто заучить, я не заставляю**
|
||||
>
|
||||
> В общем-то здесь просто минимальная модель процессора, какая вообще возможна (и с оговорками). Меньше ее сделать нельзя по двум причинам:
|
||||
>
|
||||
> - На ней будет показываться микропрограммирование, что закрепляет часть элементов
|
||||
> - Без остальных частей не заведется ни один уважающий себя процессор
|
||||
>
|
||||
> Сначала рассмотрим "обрубок АЛУ" как я его называю. Ранее по билетам%%укажи где%% я упоминал, что минимальный процессор должен уметь в операции сложения, сдвига и инверсии. Ну короче вот они все тут и стоят
|
||||
>
|
||||
> Любой процессор должен иметь счетчик команд для того, чтобы хотя бы просто идти вперед по списку команд.
|
||||
>
|
||||
> Регистр адреса нужен банально как дополнение к счетчику команд, чтобы формировать адреса операндов, без него совсем тяжко
|
||||
>
|
||||
> 2 регистра нужны, потому что архитектура у нас регистровая, а не стековая или еще какая, поэтому все операции через регистры, а значит регистров как минимум больше одного. Больше двух для целей демонстрации тоже смысла делать не было, вот препод и не нарисовал
|
||||
>
|
||||
> Буферный регистр придется запомнить, потому что он нужен во операциях сдвига или подобном, чтобы предотвращать гонки (race condition), когда результат операции может меняться из-за того, что в одном месте ток пришел на 3 наносекунды позже
|
||||
>
|
||||
> Константная единица нужна, чтобы можно было при демонстрации прибавить кол к какому-нибудь числу. Теоретически она выплевывает что-то типа $00 \dots 001$
|
||||
>
|
||||
> Память оставлю без комментариев - мы никуда без оперативы
|
||||
|
||||
Касаемо назначения циферок и как это дело микропрограммировать будем рассматривать [[#Пример микропрограммы|дальше]]
|
||||
## Микрокоманды и микропрограмма
|
||||
|
||||
![[Глава 3. Процессор#Микрокоманды и микропрограммы]]
|
||||
|
||||
## Пример микропрограммы
|
||||
|
||||
*Тут обращаемся к нашей схеме*
|
||||
|
||||
![[Глава 3. Процессор#^b0a065]]
|
||||
|
||||
И вставлю сюда же чуть более обстоятельные объяснения:
|
||||
|
||||
![[Глава 3. Процессор#Процессор с тремя внутренними шинами]]
|
||||
|
||||
*Теперь я постараюсь объяснить, зачем тут каждый из шагов*
|
||||
|
||||
Во-первых оставлю отрывок из методички о том, как это объясняет препод:
|
||||
|
||||
![[Pasted image 20250106002341.png]]
|
||||
|
||||
%%*Того, что было написано в методичке маловато для того, чтобы закодить этот алгоритм, поэтому придется реализовать его вам самостоятельно. Ну или пишите - попробую реализовать его, но сейчас как будто бы билетов еще много впереди*%%
|
||||
|
||||
Теперь что касается строк таблицы (вместо "Регистр 1" и "Регистр 2" буду писать R1, R2):
|
||||
|
||||
1. Подать R1 на BB, подать R2 на AB, выполнить суммирование
|
||||
2. Сумму поместить в регистр R1
|
||||
3. Снова сложить R1 и R2 (повторяет шаг 1)
|
||||
4. Поместить результат сложения в R2
|
||||
5. Подать на BB вместо содержимого регистра кучу единиц, а на AB положить R1, инвертировать оба значения и результат сложить
|
||||
6. Результат сложения в R1
|
||||
|
||||
Тут по идее 3 разных программы:
|
||||
|
||||
1. R1 = R1 + R2
|
||||
2. R2 = R1 + R2
|
||||
3. R1 = not R1
|
||||
@ -172,6 +172,8 @@
|
||||
- Микропрограммный автомат с жесткой логикой
|
||||
- Микропрограммный автомат с программируемой логикой
|
||||
|
||||
^CU-types-list
|
||||
|
||||
> [!comment]- Примечание билетёра о различиях
|
||||
> Если не вдаваться в детали, то помогает аналогия из курса схемача. Есть разные виды интегральных схемок.
|
||||
>
|
||||
@ -184,6 +186,8 @@
|
||||
> Вот тут ситуация сходная
|
||||
## Микропрограммный автомат с жесткой логикой
|
||||
|
||||
^846e1e
|
||||
|
||||
Производитель один раз и на века соединил контакты в логической схеме, что на один и тот же вход процессоры этого аппарата, как бы мы с ними не колдовали, будут выдавать одни и те же сигналы управления
|
||||
|
||||
![[Pasted image 20250104190627.png]]
|
||||
@ -207,11 +211,15 @@
|
||||
|
||||
![[Pasted image 20250104194436.png]]
|
||||
|
||||
^struct-image
|
||||
|
||||
*Tут приверду отрывок методички. Он вполне понятно все объясняет*
|
||||
|
||||
"Запуск микропрограммы выполнения операции осуществляется путем передачи кода операции из регистра команды на вход преобразователя, в котором код операции (КОП) преобразуется в начальный адрес микропрограммы. Выбранная по этому адресу из памяти микропрограмм микрокоманда заносится в регистр. Микрокоманда содержит КОП и адресную часть. КОП поступает на дешифратор и формирует управляющие сигналы, адрес передается для формирования адреса следующей микрокоманды. Этот адрес может зависеть от флагов, КОП, внешних устройств"
|
||||
"Запуск микропрограммы выполнения операции осуществляется путем передачи кода операции из регистра команды на вход преобразователя, в котором код операции (КОП) преобразуется в начальный адрес микропрограммы. Выбранная по этому адресу из памяти микропрограмм микрокоманда заносится в регистр. Микрокоманда содержит КОП и адресную часть. КОП поступает на дешифратор и формирует управляющие сигналы, адрес передается для формирования адреса следующей микрокоманды. Этот адрес может зависеть от флагов, КОП, внешних устройств" ^f2908e
|
||||
|
||||
## Пример процессора с 3 шинами и его микропрограммирования
|
||||
# Пример процессора с 3 шинами и его микропрограммирования
|
||||
|
||||
## Микрокоманды и микропрограммы
|
||||
|
||||
Микрокоманд в УУ может быть много, но все они, как правило, принадлежат к одному из двух типов:
|
||||
|
||||
@ -231,7 +239,7 @@
|
||||
### Объем микрокода и размер микрокоманд
|
||||
|
||||
|
||||
Из того, что GATE использует для каждого выхода УУ отдельный бит, можно сделать вывод, что этих битов в этом микропрограммном слове %%термин сам придумал, не используйте%%должно быть никак не меньше, чем количество выходов на процессоре, а также еще один, отведенный под *признак* (синий квадратик на схемах)
|
||||
Из того, что GATE использует для каждого выхода УУ отдельный бит, можно сделать вывод, что этих битов в этом микропрограммном слове %%термин сам придумал, не используйте%%должно быть никак не меньше, чем количество выходов на процессоре, а также еще один, отведенный под *признак* (голубой квадратик на схемах)
|
||||
|
||||
Также необходимо, чтобы в команда TEST могла проверить любой интересующий ее бит в любом регистре. Так что разрядность ограничена снизу еще и этим параметром
|
||||
|
||||
@ -243,15 +251,15 @@
|
||||
|
||||
Суть в том, что микрокоды (те самые наборы битов, которых у нас мало, но которые примерно по 100 бит каждое), мы храним в нанопамяти, а в микропамяти мы храним условно "адреса" нужных намкодов в нанопамяти, при этом каждый адрес у нас совсем небольшой (на схеме 6 бит, потому что 64 микрокода в нанопамяти, а $2^{6} = 64$)
|
||||
|
||||
### Процессор с тремя внутренними шинами
|
||||
## Процессор с тремя внутренними шинами
|
||||
|
||||
*Ну вот и то, ради чего мы работали все это время*
|
||||
|
||||
![[Pasted image 20250105233200.png]]
|
||||
![[Pasted image 20250105233200.png]] ^b0a065
|
||||
|
||||
Вот эту схему надо запомнить наизусть походу (по крайней мере в билете написано "(схема)")
|
||||
|
||||
Вот на этой вот схемке в разных узелочках вы можете видеть стрелочки, над некоторыми даже есть цифры. Так вот, эти стрелочки - проводочки, а эта шняга работает как транзистор - пускает дальше сигнал или не пускает (на уровне модели, что там препод имел в виду - бог его рассудит)
|
||||
Вот на этой вот схемке в разных узелочках вы можете видеть стрелочки, над некоторыми даже есть цифры. Так вот, эти стрелочки - проводочки, а эта шняга работает как транзистор - пускает дальше сигнал или не пускает (это на уровне модели, что там препод имел в виду - бог его рассудит)
|
||||
|
||||
Далее. Магистрали здесь обозначены AB (A BUS), BB (B BUS), CB (C BUS). Вот этот набор в правом нижнем углу предлагаю считать обрубком нормального АЛУ. (в методичке кстати за АЛУ принят только сумматор, но не суть). Как видно к сумматору стрелки не идет, из чего я предположу, что сложим мы 2 числа вообще в любом случае, а вот подавая единицы на другие стробы в АЛУ можно регулировать, будет ли операция. 0 - не будет, 1 будет. При этом проходить сигнал дальше будет независимо от того, какой сигнал мы подали (тут это не транзистор, это какой-то мультиплексор)
|
||||
|
||||
|
||||
BIN
Приложения/Pasted image 20250106002341.png
Normal file
BIN
Приложения/Pasted image 20250106002341.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
@ -1,4 +1,6 @@
|
||||
---
|
||||
tags:
|
||||
pun:
|
||||
pun:
|
||||
author:
|
||||
revised:
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user