The post has been translated automatically. Original language: Russian
The MIX of Donald Knuth and Memora8 is hard to confuse. They have different machine words, different registers, different ways of working with memory, and completely different hardware environments.
MIX was created as an educational computing machine for describing algorithms. Memora8 is a real 32-bit processor that must run in programmable logic.
Therefore, the most interesting similarity between them is not in the command table.
It's in the very way you design a car.
First you need to determine what is part of the processor.
When developing an architecture, it is very easy to gradually add features.
A certain operation is needed — a new command appears. Another addressing option was required — a new mode is being added. A new flag appears for the convenience of the transition. Then there are exceptions to the existing rules.
Each decision individually may look reasonable.
The problem becomes noticeable later, when the processor has to be considered as a whole.
MIX is interesting because Knut built a complete model of the machine. It has a clear representation of data, memory, registers, operations, and program management rules. You can track the execution of the instruction and understand which parts of the state it changes.
This visibility proved to be important for Memora8 as well.
The specific mechanisms have changed, but the requirement has remained: the architecture must remain such that it can be mentally captured in its entirety.
Simplicity is not a minimum number of details.
A small processor can easily be confused with a primitive one.
If you just remove commands, registers, and features, the machine will really get smaller. But programming it can become much more difficult, and some of the saved hardware will have to be compensated with long sequences of instructions.
Therefore, the design of Memora8 was not limited to constant reduction.
The processor has 32 general-purpose registers, working with bytes and half words, immediate values, conditional and unconditional jumps, loading the high-order part of a number, and other mechanisms that could theoretically be expressed in longer sequences.
They are abandoned because they solve common problems in a fairly direct way.
This is an important boundary.
A simple architecture is not one in which there are as few possibilities as possible. Rather, she tries to get as much useful behavior as possible from a small number of general rules.
Sometimes it's more useful to remove the special case.
When comparing MIX and Memora8, this is repeated in many places.
There are specialized registers in MIX. Memora8 basically uses the same general purpose registers.
In MIX, the comparison result is stored in a separate machine state. Memora8 writes it to a regular register.
MIX is able to select fields inside a machine word directly by means of instructions. Memora8 uses more conventional read, shift, and logical processing operations.
In MIX, indexing is part of the team's architecture. In Memora8, the address is constructed from a regular register and an offset.
Each such transition removes a specific specialized feature.
But the task itself does not disappear.
It begins to be solved by a combination of more general mechanisms.
This is one of the most useful principles when designing a processor: before adding a special mechanism, it is worth checking how well the existing ones are coping with the same task.
Hardware reuse is more important than the beauty of the command table
The command system is often perceived by the programmer.
I want a common action to be expressed in a single instruction, so that the name of the command corresponds exactly to the operation and so that the machine code looks compact.
This is not enough for a hardware project.
You need to look at what's going on inside the processor.
If two different instructions use the same registers, the same computing unit, and the same result recording path, it can be relatively cheap to distinguish them.
If one new instruction requires an additional data source, a new connection between the stages, and a special completion rule, its cost is significantly higher.
Therefore, it is not only the simplicity of individual commands that is important in Memora8.
It is important that different instructions use the same hardware whenever possible.
This is no longer a question of the external beauty of architecture, but of its internal regularity.
Real hardware gives the answer faster than theory
When designing an abstract machine, you can discuss for a long time how successful a particular solution looks.
The FPGA quickly translates such a dispute into a practical plane.
After synthesis, you can see how many resources the schema takes up. After placing and tracing, it turns out which connections turned out to be long. Time analysis shows whether the processor fits into the required clock cycle.
Sometimes a solution that looks very elegant at the architecture level creates an inconvenient hardware structure.
The opposite also happens: the simpler option from the point of view of the command system fits well on the FPGA device and allows you to get a predictable data path.
For Memora8, this feedback is part of the design process.
The architecture does not end after writing a description of the command system. It is checked by the actual implementation.
Clarity is useful not only for humans
When architecture is simple, it is usually said that it is easier to learn.
There are several other advantages for a small processor.
It is easier to write a behavior model and compare the hardware implementation with it. It is easier to determine which state should change after the command. It's easier to check the transitions between the stages. It is easier to find the error location if the result of the hardware execution differs from the expected one.
Regularity also helps software tools.
It is easier for the compiler to work with the same general-purpose registers than to constantly take into account many special roles. It is easier for the emulator to implement commands if they form several stable groups. It is easier for a debugger to explain the state of a machine when it consists of a small number of clearly defined elements.
It turns out that architectural simplicity extends to several levels of the system at once.
The boundary between hardware and software is constantly being redefined
MIX was created in an era when many actions were naturally expressed directly through the machine architecture.
Memora8 exists in a different environment.
A programming language, compiler, and other tools are usually located between the source program and the processor. Therefore, some of the work that was previously convenient to fix in hardware can now be left to the software layer.
For example, the processor itself does not need to know which register is used as a stack pointer. It is not necessary to have a separate register of the return address. It is not necessary to provide a command for each comparison condition.
These conventions may exist above the machine architecture.
But transferring work to the program should also not become an end in itself.
If the operation is performed continuously and hardware support significantly simplifies it, such support makes sense.
Therefore, the boundary has to be searched for separately for each case.
Good architecture doesn't have to anticipate everything.
There is another temptation — to put possibilities in the processor for the future.
You may need a certain operation, so you should add it now. Perhaps a new way of working with memory will arise — it is better to provide a separate mode. There are still free command codes.
This way, the system quickly begins to support tasks that do not yet exist.
In Memora8, a different approach turned out to be more useful: to leave the architecture limited until the need for expansion becomes clear.
The mere fact of having a free opcode is not a reason to create a new team.
The new opportunity must have a task.
This is especially important for hardware, because the added complexity always has to be maintained, even if a particular program does not use it.
MIX is useful precisely because it is not modern.
It may seem strange to use Knuth's architecture as a starting point for a modern project.
But the age of MIX is more of an advantage here.
The difference between Through epochs, it forces us to separate a fundamental task from a specific historical solution.
Why do we need index registers? To conveniently navigate through the data.
Why do I need a battery? To store operands and calculation results.
Why do we need word fields? To extract and modify parts of the data.
Why is there a comparison indicator? So that the result of the calculation can influence the further execution of the program.
If you look only at modern architecture, many of its decisions are easy to take for granted.
MIX forces you to ask the question: what initial problem does this mechanism solve?
After that, it is already possible to decide whether the same mechanism is needed in Memora8 or whether it is better to solve this problem differently today.
There are still questions about Knuth's architecture
Memora8 is not a modern implementation of MIX.
It does not aim to maintain compatibility with Knuth's machine or replicate its command system.
But the MIX experience proved useful as a way of reasoning.
What should a processor really be able to do? What operations should exist in hardware? What can be expressed through existing mechanisms? What special cases justify the additional complexity? Is it possible to understand the entire state of the machine?
These questions are not outdated along with the five-byte word MIX.
On the contrary, when implementing a processor in an FPGA, they become even more specific.
Any decision can be brought to the scheme and its consequences can be seen.
Therefore, the main connection between MIX and Memora8 is not in separate commands, registers, or formats.
She's in the architectural discipline.
First, identify a small number of understandable mechanisms. Then try to solve real problems with their help. And only after that, expand the car where existing funds are really insufficient.
Decades later, this approach still works.
MIX Дональда Кнута и Memora8 трудно спутать. У них разные машинные слова, разные регистры, разные способы работы с памятью и совершенно разная аппаратная среда.
MIX создавался как учебная вычислительная машина для описания алгоритмов. Memora8 — реальный 32-битный процессор, который должен работать в программируемой логике.
Поэтому наиболее интересное сходство между ними находится не в таблице команд.
Оно находится в самом способе проектировать машину.
Сначала нужно определить, что является частью процессора
При разработке архитектуры очень легко постепенно добавлять возможности.
Нужна определённая операция — появляется новая команда. Потребовался ещё один вариант адресации — добавляется новый режим. Для удобства перехода возникает новый флаг. Затем появляются исключения из уже существующих правил.
Каждое решение по отдельности может выглядеть разумным.
Проблема становится заметна позже, когда процессор приходится рассматривать целиком.
MIX интересен тем, что Кнут построил законченную модель машины. У неё есть понятное представление данных, память, регистры, операции и правила управления программой. Можно проследить выполнение инструкции и понять, какие части состояния она изменяет.
Именно эта обозримость оказалась важной и для Memora8.
Конкретные механизмы изменились, но сохранилось требование: архитектура должна оставаться такой, чтобы её можно было мысленно охватить целиком.
Простота — это не минимальное число деталей
Небольшой процессор легко спутать с примитивным.
Если просто убрать команды, регистры и возможности, машина действительно станет меньше. Но программировать её может стать значительно сложнее, а часть сэкономленной аппаратуры придётся компенсировать длинными последовательностями инструкций.
Поэтому проектирование Memora8 не сводилось к постоянному уменьшению.
В процессоре есть 32 регистра общего назначения, работа с байтами и половинами слов, непосредственные значения, условные и безусловные переходы, загрузка старшей части числа и другие механизмы, которые теоретически можно было бы выразить более длинными последовательностями.
Они оставлены потому, что решают распространённые задачи достаточно прямым способом.
Это важная граница.
Простая архитектура — не та, в которой возможностей как можно меньше. Она скорее старается получить как можно больше полезного поведения из небольшого числа общих правил.
Иногда полезнее убрать специальный случай
При сравнении MIX и Memora8 это повторяется во многих местах.
В MIX существуют специализированные регистры. Memora8 в основном использует одинаковые регистры общего назначения.
В MIX результат сравнения хранится в отдельном состоянии машины. Memora8 записывает его в обычный регистр.
MIX умеет выбирать поля внутри машинного слова непосредственно средствами инструкции. Memora8 использует более обычные операции чтения, сдвига и логической обработки.
В MIX индексирование является частью архитектуры команды. В Memora8 адрес строится из обычного регистра и смещения.
Каждый такой переход убирает определённую специализированную возможность.
Но сама задача не исчезает.
Она начинает решаться комбинацией более общих механизмов.
Это один из наиболее полезных принципов при проектировании процессора: прежде чем добавлять специальный механизм, стоит проверить, насколько хорошо с той же задачей справляются уже существующие.
Повторное использование аппаратуры важнее красоты таблицы команд
Система команд часто воспринимается со стороны программиста.
Хочется, чтобы распространённое действие выражалось одной инструкцией, чтобы название команды точно соответствовало операции и чтобы машинный код выглядел компактно.
Для аппаратного проекта этого недостаточно.
Нужно смотреть, что происходит внутри процессора.
Если две разные команды используют одни и те же регистры, тот же вычислительный блок и один путь записи результата, их различие может быть сравнительно дешёвым.
Если же одна новая инструкция требует дополнительного источника данных, нового соединения между стадиями и особого правила завершения, её стоимость значительно выше.
Поэтому в Memora8 важна не только простота отдельных команд.
Важно, чтобы разные инструкции по возможности использовали одну и ту же аппаратуру.
Это уже не вопрос внешней красоты архитектуры, а вопрос её внутренней регулярности.
Реальное железо даёт ответ быстрее теории
При проектировании абстрактной машины можно долго обсуждать, насколько удачно выглядит то или иное решение.
FPGA довольно быстро переводит такой спор в практическую плоскость.
После синтеза становится видно, сколько ресурсов занимает схема. После размещения и трассировки выясняется, какие соединения оказались длинными. Временной анализ показывает, укладывается ли процессор в требуемый такт.
Иногда решение, которое выглядит очень изящно на уровне архитектуры, создаёт неудобную аппаратную структуру.
Бывает и обратное: более простой с точки зрения системы команд вариант хорошо ложится на устройство FPGA и позволяет получить предсказуемый тракт данных.
Для Memora8 такая обратная связь является частью проектирования.
Архитектура не заканчивается после написания описания системы команд. Она проверяется реальной реализацией.
Понятность полезна не только человеку
Когда архитектура проста, обычно говорят, что её легче изучать.
Для небольшого процессора есть ещё несколько преимуществ.
Проще написать модель поведения и сравнивать с ней аппаратную реализацию. Проще определить, какое состояние должно измениться после команды. Проще проверить переходы между стадиями. Проще найти место ошибки, если результат аппаратного исполнения отличается от ожидаемого.
Регулярность помогает и программным средствам.
Компилятору легче работать с одинаковыми регистрами общего назначения, чем постоянно учитывать множество специальных ролей. Эмулятору проще реализовать команды, если они образуют несколько устойчивых групп. Отладчику легче объяснить состояние машины, когда оно состоит из небольшого числа явно определённых элементов.
Получается, что архитектурная простота распространяется сразу на несколько уровней системы.
Граница между аппаратурой и программой постоянно пересматривается
MIX создавался в эпоху, когда многие действия было естественно выражать непосредственно через машинную архитектуру.
Memora8 существует в другой среде.
Между исходной программой и процессором обычно находятся язык программирования, компилятор и другие средства. Поэтому часть работы, которую раньше было удобно закреплять в аппаратуре, теперь можно оставить программному уровню.
Например, самому процессору необязательно знать, какой регистр используется как указатель стека. Необязательно иметь отдельный регистр адреса возврата. Необязательно предоставлять команду для каждого условия сравнения.
Эти соглашения могут существовать выше машинной архитектуры.
Но перенос работы в программу тоже не должен становиться самоцелью.
Если операция выполняется постоянно и аппаратная поддержка заметно упрощает её, такая поддержка имеет смысл.
Поэтому границу приходится искать для каждого случая отдельно.
Хорошая архитектура не обязана предугадывать всё
Есть ещё одно искушение — заложить в процессор возможности на будущее.
Может понадобиться определённая операция, значит стоит добавить её сейчас. Возможно, возникнет новый способ работы с памятью — лучше предусмотреть отдельный режим. Свободные коды команд всё равно есть.
Так система быстро начинает поддерживать задачи, которых пока не существует.
В Memora8 более полезным оказался другой подход: оставлять архитектуру ограниченной до тех пор, пока необходимость расширения не становится понятной.
Сам факт наличия свободного кода операции не является причиной создавать новую команду.
У новой возможности должна быть задача.
Это особенно важно для аппаратуры, потому что добавленную сложность потом приходится поддерживать всегда, даже если конкретная программа ею не пользуется.
MIX полезен именно потому, что он не современный
Может показаться странным использовать архитектуру Кнута как отправную точку для современного проекта.
Но возраст MIX здесь скорее преимущество.
Разница между эпохами заставляет отделять фундаментальную задачу от конкретного исторического решения.
Зачем нужны индексные регистры? Чтобы удобно перемещаться по данным.
Зачем нужен аккумулятор? Чтобы хранить операнды и результаты вычислений.
Зачем нужны поля слова? Чтобы извлекать и изменять части данных.
Зачем существует индикатор сравнения? Чтобы результат вычисления мог влиять на дальнейшее выполнение программы.
Если смотреть только на современную архитектуру, многие её решения легко принять как данность.
MIX заставляет задавать вопрос: какую исходную проблему решает этот механизм?
После этого уже можно решить, нужен ли тот же механизм в Memora8 или сегодня эту задачу лучше решать иначе.
От архитектуры Кнута остались вопросы
Memora8 не является современной реализацией MIX.
В нём нет цели сохранить совместимость с машиной Кнута или повторить её систему команд.
Но опыт MIX оказался полезен как способ рассуждения.
Что действительно должен уметь процессор? Какие операции должны существовать аппаратно? Что можно выразить через уже имеющиеся механизмы? Какие специальные случаи оправдывают дополнительную сложность? Можно ли понять состояние машины целиком?
Эти вопросы не устарели вместе с пятибайтовым словом MIX.
Напротив, при реализации процессора в FPGA они становятся ещё более конкретными.
Любое решение можно довести до схемы и увидеть его последствия.
Поэтому основная связь между MIX и Memora8 находится не в отдельных командах, регистрах или форматах.
Она в архитектурной дисциплине.
Сначала определить небольшое число понятных механизмов. Затем попытаться решить с их помощью реальные задачи. И только после этого расширять машину там, где существующих средств действительно недостаточно.
Спустя десятилетия этот подход по-прежнему работает.