Как создавался ассемблер?

Приветствую!

Каким образом был создан ассемблер? Меня заинтересовал вопрос, как от машинных слов (микрокоманд процессора) разработчики пришли к мнемоникам (мнемокоду)? Каким образом создавался первый ассемблер; на чистом машинном коде?

Далее уже понятно, что как только готов транслятор (или макропроцессор, в тонкостях пока мало разбираюсь), то можно разрабатывать ассемблеры на самом ассемблере, но вот первично, не очень понятно.

Буду рад любой информации!
С уважением,
Сергей.

 

Exilibris

Разумеется на си++ .

 

Exilibris

В начале была клавиатура, и клавиатура была у программиста. Программист на одной клавише написал слово "mov", на другой написал "xor" и так далее. Нажал программист клавишу "mov" - опа, и в память записался байт опкода, потом нажал клавишу "eax" - и в следующий байт записался номер регистра и маска режима адресации, ещё там была цифровая клавиатура для набора адресов памяти и непосредственных операндов.

 

Как ни странно, вначале был Конрад Цузе, а не клавиатура. И сказал он, да будет Z1, первый в мире программируемый вычислитель. Но неточным и ненадёжным оказался полностью механический Z1. Тогда решил Цузе, что должен быть Z2, и будет он частично электронным на реле (которыми можно было по дешёвке затариваться у местных телефонных компаний). Не сильно надёжными оказались сбагреные реле, но механическая память Z2 подводила ещё больше. И рассудил Цузе, что третья машина Z3 на одних реле собрана быть должна, пока жалкие людишки биполярные транзисторы не придумали. Как и Z2 программироваться дырками на фотоплёнке Z3 будет, но инструкцию квадратного корня на арифметике с плавающей запятой в мир привнесёт. "Не ассемблером единым человечество сильно будет", — решил Цузе и планкалькюль, первый высокоуровневый язык, сотворил. А людишки по образу и подобию свои языки пусть придумывают. Но не получилось у людишек подобия, а лишь дырки фотоплёнки на язык человеческий перевести им под силу было (для EDSAC, правда, но спишем это на неточность повествования). Так и получился ассемблер.

 

Exilibris

Микрокоманды к машинным словам никакого отношения не имеют. Машинное слово -- это "естественная" для данного процессора единица информации, которую он обрабатывает за одну операцию. Например, у одной из наших первых машин, "Стрелы", слово было 53 бита, если маразм не изменяет. У очень распространённых в своё время "Минсков" -- 37 битов (это точно), БЭСМ-6 -- 48 бит (тоже точно), у "Уралов" -- вроде как 18... В общем, полный разброд и шатания. Вдобавок, тогда не было деления слова на единицы меньшей разрядности. Та же примерно история творилась и за бугром.

8-разрядный байт впервые появился в IBM System/360 (анонс -- 1964 год, серийный выпуск -- с 1965-го). У этих машин слово имело размер 32 бита и могло быть разделено на два полуслова или четыре байта. Деление на байты получило признание не сразу, но в конце концов было принято практически всеми.

Микрокоманды, если и существуют, то только и исключительно внутри процессора; программист их никак не видит. В ранних вычислительных машинах никаких микрокоманд не было: процессор непосредственно выполнял машинные команды, считываемые им из памяти (так называемое жёсткое или схемное управление -- когда логика работы процессора целиком определяется его электрической схемой). Однако по мере усложнения системы команд реализовывать процессоры становилось всё сложней, и тогда появилось микропрограммное управление. В своём классическом виде оно работает так. Сравнительно простой с точки зрения внутреннего устройства процессор считывает из памяти очередную команду и запоминает её в одном из своих внутренних регистров. После этого управление получает последовательность микрокоманд (микропрограмма), реализующая эту команду. Когда выполнение микропрограммы закончится, будет считана следующая команда и вызвана микропрограмма для её выполнения и т.д. Программист всего этого не видит: с его точки зрения процессор просто выполняет команды, и всё; микропрограммы видит лишь разработчик процессора или те, кто этот самый процессор обслуживают (раньше ведь процессор мог состоять из десятков тысяч микросхем малой степени интеграции, занимая пару шкафов; естественно, всё это дело время от времени ломалось). Машины уже упомянутой Системы 360 частью имели микропрограммное управление, а частью -- чисто аппаратное. Первые были намного проще и дешевле, но работали медленнее, чем вторые. С точки зрения программиста, однако, они различались лишь производительностью.

Ну а что касается собственно трансляторов ассемблера, то, естественно, первый транслятор писался в машинных кодах и был очень-очень простым. Фактически это был переводчик мнемоник (типа ADD и SUB) в соответствующий машинный код, и не больше (никаких тебе макросредств, перемещаемого объектного кода и т.д. и т.п.). Это впоследствии они всё развивались и расширялись.

 

Ох ребятки беженьком беженьком находим книжку таненбаума и выкуриваем основательно. (приложение можно не читать )

 

SII, l_inc
Благодарю, стало немного яснее. Хотя появился еще ряд вопросов.

Satsura
Года полтора тому назад читал книгу этого автора - "Архитектура компьютера", но в ней, на мой взгляд, недостаточно детально раскрывается тема для глубокого понимания, хотя я не исключаю, что у меня недостаточно опыта для правильной интерпретации, и я просто многое упустил из того, что автор подразумевал как должное. Сейчас с удовольствием изучаю его труд "Операционные системы. Разработка и реализация."

---

P.S. Просто до этого я не сталкивался с тонкостями работы компьютера на низком уровне, и поэтому все механизмы были скрыты, скажем так, за определенным уровнем абстракции. Когда я впервые понял, что для качественной реализации идей необходимо опускаться в недра системы, детально понимать ее работу, я начал разбирать слой за слоем, но в конечном счете среди всех абстракций немного растерялся.

Так, в частности, в той же книге Эндрю Таненбаума "Архитектура компьютера" он пишет о многоуровневой компьютерной организации и раскрывает это понятие как отношения уровней "машина 0 - язык 0 - машина 1 - язык 1 - ...", совершенно логичным стал для меня вопрос о том, что является основанием для ассемблера. И если достаточно просто понять, как на самом языке можно расширять этот же язык или создавать новый, то не совсем очевидным было, на чем создавался ассемблер, если ничего до этого не было (с точки зрения эффективной разработки), кроме непосредственно набора доступных процессору команд.

SII
>>> Микрокоманды, если и существуют, то только и исключительно внутри процессора; программист их никак не видит.

Что тогда подразумевается под мнемоникой языка ассемблера? Мнемоника транслируется в набор машинных слов, которые интерпретируются логикой за уровнем аппаратной абстракции (внутри процессора)?

Когда говорят о "декодировании инструкции" имеют в виду разбор процессором машинного слова на последовательность дальнейших действий внутренними блоками, то есть, декодирование и есть процесс внутреннего "расщепления" (интерпретации) машинного слова на микрокоманды? Или я не так все понимаю?

Насколько я знаю, современные процессоры работают на х86 наборе инструкций, который относится к CISC-архитектуре, при этом инструкции внутри современного процессора транслируются в некоторую совокупность RISC-инструкций и затем исполняются (?). В этом случае RISC-инструкция также подвергается декодированию или она и есть минимальная единица логики для функиональных блоков процессора? Грубо говоря RISC-инструкция представляет собой инструкцию к действию или она тоже является каким-то слоем абстракции для уровня еще ниже (вентилей?).

Не обессудьте, я просто пытаюсь понять %)

 

Возможно просто невнимательно читали. В той же книге пишется что любой алгоритм, любую программу можно описать как программно(абстракциями) так и хардварно, т. е железками выстраивая нужную логику. Также существует взаимообратная конвертация. Отсюда делайте выводы.

 

Да я помню это утверждение, но от этого яснее не становится, я попробую объяснить почему: насколько я помню, приводимые в книге схемы примитивной логики построеной на вентилях реализуют логику с точки зрения подаваемых на них сигналов, то есть они не статичны, что и предполагалось в принципе, поэтому мне сложно отделить программную логику от "железа".

В моем представлении программа - это некий набор действий (при этом не суть важно как и что исполняется, важен сам принцип), программа - строгая последовательность.

В то же время схема - это потенциальное множество решений, то есть в железе мы можем реализовать в единой сущности потенциально все возможные варианты работы (с точки зрения бинарной логики).

Поэтму я не совсем понимаю, что имел в виду автор. Ведь компьютер не может существовать без какой-то конкретной программы. Необходимо инициализировать действия, чтобы "железо" отработало, то есть необходима некая мотивация, которую мы так или иначе программируем и выражаем в виде программы, которую исполняет машина. Иначе говоря, программист, создавая программу выбирает некоторое решение из множества возможных. Ну по крайней мере я себе это так представляю в глобальном смысле.

 

Проблема не в том что существует большое кол-во реализаций программы, т. е алгоритмов, а в том что существует так называемое 'золотое' правило классической механики. Если в чем то выигрываем, то обязательно в чем то проигрываем. Чтобы как то сбалансировать нужно находить золотую середину. По этому принципу сегодня и строятся современные микропроцессоры : CISC процессоры с RISC- микроядром. По поводу вашего вопроса насчет RISC инструкций, вы правы это всего лишь прослойка над аппаратной абстракцией, вентелей. По той же причине программирование в школах изучают начиная с блок-схем, ага (:

 

Exilibris

Мнемоники выдумывают люди, поэтому они могут быть, вообще говоря, любыми. Синтаксические и семантические правила конкретного языка ассемблера устанавливают соответствие между мнемониками и машинными кодами, ну а транслятор этого языка осуществляет преобразование мнемоник и сопутствующей информации (операндов) в машинный код. Машинный код интерпретируется и исполняется процессором; как конкретно это делается, для программиста неважно (а зачастую неизвестно). И кстати, некорректно говорить о трансляции мнемоники в "набор машинных слов", поскольку, как уже говорил, машинное слово -- это "стандартная" порция информации для данного процессора, ну а длина кода команды может ей не соответствовать. Например, у процессоров архитектуры IA-32 (тех самых, на которых построены все современные ПК; первым из них был 80386) длина машинного слова -- 32 бита, а код команды может иметь переменную длину от 1 до 15 байтов.

Не обязательно машинного слова, а просто очередного кода команды, который может иметь разную длину. Декодирование здесь понимается в довольно широком смысле; его цель -- понять, как же надо выполнить то, что предписывается очередной командой. Ну а конкретный способ декодирования сильно зависит от системы команд. IA-32 -- далеко не единственная процессорная архитектура, да вдобавок одна из самых худших; в частности, в ней декодирование команды -- это жуть (даже для того, чтобы просто понять, сколько байтов входит в код команды, нужно выполнить кучу действий, анализируя один за другим подряд расположенные байты).

Первое: не современные процессоры, а современные процессоры архитектуры IA-32. Она, как я уже говорил, далеко не единственная.

Второе: что же касается трансляции CISC в RISC... И да, и нет. То, что исполняет само железо процессора, не является RISC-командами, хотя это утверждают всякие там презентации и умные книги. Тут дело в том, что слова давно уже используются не в том смысле, который в них вкладывался. (Так произошло, например, с понятием "микроядро": реальных микроядерных ОС, нашедших практическое применение, не существует, ну а те, которые сейчас называются микроядерными, таковыми не являются -- но это так, лирическое отступление.) На самом деле блоки выборки и декодирования команд в современных процессорах архитектуры IA-32 транслируют каждую считанную ими из памяти команду в одну или несколько микроопераций (или микрокоманд -- это одно и то же), которые затем исполняются оставшейся частью процессора. Некоторые команды, например, "ADD EAX, EBX", транслируются в одну микрокоманду, которая предписывает примерно следующее: "подать на вход А арифметико-логического устройства содержимое регистра EAX, на вход B -- содержимое регистра EBX, выполнить операцию сложения без учёта входного переноса, записать результат в регистр EAX, обновить значения флагов в соответствии с полученным результатом). Более сложные команды транслируются в несколько микроопераций, ну а для выполнения самых сложных используются целые микропрограммы, хранящиеся во внутреннем ПЗУ: в этом случае блок выборки и декодирования команд просто запускает нужную микропрограмму из этого ПЗУ.

Конечно, на самом деле в современных процессорах всё сложнее, но общий принцип именно такой. Классическое же микропрограммное управление было проще: для каждой из машинных команд (или из "логических" групп машинных команд -- например, ADD, ADC, SUB, SBC, AND, OR, XOR все входят в одну группу -- арифметико-логические команды с двумя операндами) существует своя микропрограмма, находящаяся в ПЗУ, которое входит в состав процессора. Когда блок выборки и декодирования команд считывает из памяти очередную команду, он её анализирует и запускает на выполнение ту или иную микропрограмму, которая и выполняет действия этой команды. Причём декодирование фактически оказывается "размазанным". Например, блок выборки и декодирования определил, что сейчас надо выполнить команду из группы арифметико-логических с двумя операндами и запустил соответствующую микропрограмму, а уже в микрокоманде этой микропрограммы, непосредственно осуществляющей выполнение операции, вместо ценного указания "выполни операцию такую-то" стоит указание "выполни операцию, чей код задан битами такими-то байта такого-то, хранящегося в регистре кода текущей выполняемой команды" -- именно благодаря этому несколько разных команд могут выполняться одной микропрограммой.

Ну и третье. Если б то, во что транслировались настоящие команды процессора (CISC-команды в IA-32), было действительно RISC-командами, то они тоже нуждались бы в дальнейшем декодировании. Но на самом деле, как я уже говорил, это не так. Микрокоманды в дальнейшем декодировании как таковом не нуждаются: они уже задают функции, которые должны выполняться каждым из блоков процессора. Например, в составе микрокоманды могут быть несколько битов, указывающих, откуда брать операнд A, ещё несколько -- для операнда B, ещё -- для кода операции, которую выполнит АЛУ, ну и так далее. Все эти биты прямо идут к различным блокам процессора и управляют их работой в текущем машинном такте.

Естественно, в современных процессорах всё сложней, чем здесь описано, но принцип, в общем-то, именно такой. Но подробности являются страшной коммерческой тайной, поэтому о деталях работы остаётся лишь догадываться.

Кстати, разница между настоящим CISC-процессором (неважно, какой именно архитектуры -- IA-32, повторюсь вновь, далеко не единственная) и RISC-процессором заключается в том, что:

1) у RISC-процессора код команды всегда имеет одну и ту же длину, поэтому блок выборки и декодирования команд, зная адрес текущей выполняющейся команды, может сразу выбрать и начать декодирование следующей (он ошибётся только в том случае, если текущая выполняемая команда -- переход), причём выборка и декодирование намного проще как раз из-за фиксированной длины кода команды (не нужно анализировать байты последовательно, чтобы понять, где конец команды и за что каждый из считанных байтов отвечает);

2) сами RISC-команды таковы, что не нуждаются в дальнейшей сложной декодировке и могут быть выполнены за один такт (без учёта возможного ожидания готовности памяти или внешнего устройства). Поэтому среди классических RISC-команд не может быть, например, деления или там вычисления синуса: эти операции сложны и не могут быть выполнены за один такт;

3) простота RISC-команд исключает необходимость в микропрограммном управлении: каждая RISC-команда выполняется сразу как единое целое, без необходимости выполнения одна за другой нескольких микрокоманд. Поэтому настоящий RISC-процессор всегда имеет чисто схемное управление. (Вероятно, именно поэтому кто-то из "умников" заявил, что-де CISC-команды IA-32 транслируются в RISC-команды, хотя на самом деле они транслируются в микрооперации.)

Разница же между RISC-командами и микрооперациями примерно такова:

1) RISC-команды видны программисту, и он может прямо с ними работать (например, написать свою программу на языке ассемблера данного RISC-процессора). Программа, состоящая из этих команд, хранится во внешней по отношению к процессору памяти -- в оперативке, например -- и считывается во внутренние регистры процессора в ходе её выполнения. Микрокоманды программисту не видны, они существуют только внутри самого процессора. Соответственно, программист никак не может ими оперировать, программы с их использованием не пишутся, а сами микропрограммы хранятся в памяти самого процессора.

2) RISC-команда указывает процессору как единому целому, какую операцию он должен выполнить. Например, команда ADD R0, R1, R2 некоего гипотетического процессора говорит ему: сложи содержимое регистров R1 и R2 и засунь результат в регистр R0. В то же время она прямо не определяет, как именно процессор будет выполнять запрошенную операцию, что именно будут делать его различные блоки. Таким образом, команда указывает, что нужно сделать, но не говорит, как это нужно сделать.

Микрокоманда, наоборот, задаёт функции, выполняемые каждым блоком процессора, т.е. говорит, как нужно работать, но не говорит, для чего именно (В самом деле, одна и та же микрокоманда может использоваться в различных микропрограммах, отвечающих за выполнение разных команд, и просто исполнять какую-то общую для всех этих команд часть.) Например, все действия команды ADD R0, R1, R2 могут быть выполнены одной микрокомандой, содержащей следующие указания различным блокам процессора:

- блок регистров: выдать в начале такта содержимое регистра R1 на выход A, а регистра R2 -- на выход B; в конце такта принять с шины Y данные в регистр R0;
- мультиплексор входа A арифметико-логического устройства: принять информацию с выхода A блока регистров;
- мультиплексор входа B арифметико-логического устройства: принять информацию с выхода B блока регистров;
- арифметико-логическое устройство: выполнить сложение входов A и B без учёта входного переноса;
- мультиплексор шины Y: передать на шину информацию с выхода арифметико-логического устройства;
- регистр состояния: обновить значения флагов N, Z, V, C по результату выполнения текущей операции в арифметико-логическом устройстве; другие флаги не изменять;
- блок выборки и декодирования команд: выбрать и запустить на выполнение следующую команду.

В общем и целом, различные биты из состава микрокоманды прямо поступают в соответствующие блоки процессора и управляют переключением их вентилей в ходе выполнения этой микрокоманды.

Ага, но, помимо вентилей (логических элементов), есть ещё и память. Ну а отделить программную логику от железа очень просто: то, с чем имеет дело программист -- это программная логика, ну а то, что непосредственно выполняет программу -- это "железо" (и неважно, как оно реализовано внутри, поскольку, во-первых, для программиста это всё равно недоступно, а во-вторых, подробности внутренней реализации могут различаться, однако "снаружи", т.е. для программиста, поведение будет оставаться тем же самым).

Точнее, это некая последовательность кодов, задающая определённый набор действий. Сама по себе программа -- это всё ж не действие

"Схема" процессора -- это машина состояний, которая каждый такт переходит из текущего состояния в следующее на основе текущего состояния и поступающей извне информации. Этой внешней информацией являются содержимое памяти, считываемое процессором по мере необходимости, и всякие там сигналы сброса, запросов прерываний и т.д. Как именно реализована машина состояний, роли не играет: она всё равно выполняет свою работу

Существовать компьютер вполне может. Будет себе стоять и занимать место Вот что-либо делать без программы он действительно не может.

 

SII у вас какой то неправильный мед :3 или другими словами вы сейчас своим постом разрушили мое представление о работе процессоров семейства IA-32, т.к в книгах и статьях приводится совсем другое описание работы процессоров этого семейства =\ возможно это потому, что слова используются не в том значении что изначально., хотя хз черный ясчик он и в Африке, ну вы понели...
Всвязи с этим у меня два вопроса к вам:
1) является ли операционная система эндрю Таненбаума микроядерной ОС, то как он ее позиционирует?
2) Откуда у вас информация (еси не секрет) о так называемой реальной архитектуре IA-32, ведь как вы правильно заметили в своем посте архитектура современных микропроцессоров является комерческой тайной онных производителей ? (=

 

Satsura

1) Я не знаком с ОС Танненбаума, так что утверждать что-либо не берусь. Я учился в другое время и совсем по другим книгам, ну а читать его сейчас только для того, чтобы узнать, что там у него написано, особого желания нет. Могу сказать, однако, что, например, QNX не является настоящей микроядерной ОС, хотя сама фирма утверждает обратное (не знаю, имеются ли для этого исторические предпосылки, ну а сейчас ими движут маркетинговые побуждения: ведь широким народным массам "давно известно, что микроядерная ОС надёжнее, чем монолитная" -- хотя это тоже бред, поскольку надёжность системы не имеет прямой связи с её архитектурой). Дело как раз в том, что технические термины употребляются уж слишком вольно. Например, микроядерность изначально (ещё в 1970-е, а может, даже в 1960-е -- тут точно не скажу) понималась как реализация всех основных механизмов ОС в различных модулях, каждый из которых работает в своём собственном адресном пространстве и посему не может забраться в память другого модуля и нагадить там. В QNX же абсолютно всё, кроме драйверов, свалено в одну кучу с общим адресным пространством. Соответственно, это лишь слегка облегчённый монолит -- из ядра ОС вынесены драйверы, но всё остальное оставлено внутри. Про Винду я вообще молчу, хотя находятся авторы, утверждающие, что это тоже микроядерная ОС (видать, на основе того, что прикладной код работает с Win32 API, который является надстройкой над реальным API системы).

2) Для того, чтобы понять в общих чертах, какова микроархитектура того или иного процессора, достаточно технических презентаций, которые более-менее общедоступны и по которым пишутся всякие умные (и не очень) статьи в различных ИТ-изданиях, например, на iXBT. Ну а чтобы понять излагаемые в таких материалах сведения, надо достаточно хорошо разбираться в электронике. Мне в этом плане повезло: я начинал ещё на древней технике, причём не только как программист, но и как электронщик. Конечно, современные микропроцессоры внутри куда сложней, чем какая-нибудь ЕС-1035, однако многие идеи остаются теми же самыми уже несколько десятилетий...

Хм... Ну, если Вы изложите Ваше понимание принципов работы современного процессора архитектуры IA-32, то мы можем попробовать разобраться, в чём у нас возникла проблема Возможно, имеет место быть как раз терминологическая путаница. Я-то стараюсь использовать слова в тех значениях, которые в них вкладывались изначально, а с этим сейчас довольно плохо... И не только в ИТ, кстати: например, регулярно можно читать всякие глупости про то, что "инфляция в Новгородской области за прошедший месяц составила 0,5%" -- что полный бред, поскольку инфляция -- макроэкономический показатель, распространяющийся на всю конкретную валюту (российский рубль в данном случае), а не на отдельный регион. (В данном случае автор не видит разницы между ростом цен на некую "потребительскую корзину" в отдельной области и состоянием валютной системы страны в целом.)

 

Спасибо за подробный ответ, вы правы технически термины используются слишко вольно. Проблема олдскул и неюскул извечна ровно как и проблема отцов и детей (:

 

SII
Огромное Вам спасибо! Откровенно говоря, то что вы написали (включая комментарии к применяем всюду терминам, рассматривая их через призму собственного опыта и знаний) - это золотая информация без каких-либо преувеличений.

 

Exilibris
Ну при всём уважении к SII я бы на Вашем месте не верил всему написанному на слово.

 

l_inc
Ну дело не в вере, а в том, что человек постарался достаточно развернуто ответить на мой вопрос с точки зрения собственного опыта, и я благодарен за это.

Я лишь интерпретирую все вышесказанное и формирую собственную систему знаний, пытаюсь разобраться в интересующих меня вопросах, и теперь у меня есть еще одно весьма развернутое мнение на этот вопрос, которое, впрочем, дает мне некоторые вектора развития, а это очень ценно само по себе.

P.S. В конечном счете мы можем воспринимать мир таким, какой он есть, не задавая лиших вопросов, не пытаясь в чем-либо разобраться, оправдывая это тем, что в любом случае тонкости реализации скрыты за слоем абстракции нам недоступном. Но лично мое убеждение в том, что раз нам дана возможность мыслить, то мы должны не просто созерцать, но стремиться осознать процессы происходящие вокруг нас.

 

l_inc
Нам в универе читали курс архтитектуры ЭВМ в таком же ключе - если отвлечься от конвейеров, предсказания переходов, кеширования и прочих оптимизаций, то процессор - это АЛУ, регистры, куча мультиплексоров, котрые позволяют соединять эти куски в нужном порядке и микропрограмма.
Каждая команда микропрограммы - это довольно-таки длинное битовое слово, каждый бит которого определяет какой компонент микропроцессора к какому подключать на время выполнения очередного такта. Например, если в микропроцессоре есть 10 регистров, то длина микрокоманды - минимум 31 бит - т.к. для любой операции надо указывать минимум 2 входных регистра (первые 20 бит) и выходной (еще 10 бит) + 1 бит на выбор типа операции в АЛУ, если их всего 2. С упаковкой-распаковкой не парятся, т.к. это лишнее железо, замедляющее работу.

Т.е. цикл примерно такой:
-из памяти читается команда
-команда декодируется (по коду определяется номер микропрограммы, данные из команды вносятся во внутренние регистры микропроцессора)
-исполняется первое слово микропрограммы (процессор подключает нужные регистры к нужным АЛУ)
-делается такт, в течение которого отрабатывает АЛУ, забирая данные из входа и записывая результат на выход

Тут возможны варианты - слово микрокоманды может быть зашито непосредствено в схему для повышения быстродействия, либо микропрограмма может содержать несколько слов и даже циклы (например, команда умножения на микропрограммном управлении).

оффтоп: кто любит интересные задачки - реализуйте деление целых/дробных чисел на ассемблере через сложение и сдвиг, а потом загуглите, какие алгоритмы используют микропроцессоры

edit: вот например лекции по ОЭВМ, доступно и на русском : http://ak5.mylivepage.ru/file/1674/6622

 

И слово было у Бога

"Учите матчасть" (с)

 

прямо наоборот. Сначала теоретически придумали "классная штука, у нее еще есть такие приблуды, и чтоб когда мы посылаем туда что-то, оно бы приблуды суммировало". Приблуды стали называть регистрами, а классную штуку - процессором. И решили, что необходимо хотя бы суммирование (addition), пересылку (move A to B), и еще некоторые команды. И было это все сначала на бумаге и в голове разработчиков. И спорили они до хрипоты, как лучше кодировать команды, и какие команды вообще нужны. (Кстати, так к одному мнению и не пришли - поэтому в некоторых процессорах не было команд "сложить" или "вычесть" вместе. Была только одна. А=А+Б. а если надо вычесть, то А=А+(-Б). или наоборот.) А потом на платах спаяли из транзисторов сумматоры, логические элементы И-ИЛИ-НЕ, триггеров насували нужное число и получили процессор. Такой не ахти пока процессор, на 4-битных регистрах, но если их чем-то заполнить, и куда надо послать тот самый код, который выставили в соответствие сложению, то оно их даже сложит!

Так что сначала в теории были придуманы мнемоники - для обозначения элементарных операций. Потом определились как их кодировать наиболее разумным и экономным образом, то есть перевели в машинный код. А процессор в этот момент существовал только на бумаге. И уже по придуманному его сделали.

Первый ассемблер делали намного позднее. Потому что собранные процессоры были забавными, медлительными и управлялись примерно так: некоторое количество тумблеров размером в разрядность, и кнопки - в какой регистр писать. И в двоичном коде набираешь тумблерами, кнопку ткнул - регистр записан. Или другую ткнул - оно в память записалось. Памяти тоже немного было. 512 байт - это уже хорошо. Возьмите программируемый калькулятор старый, как он там, "Электроника-Б3", или где-то рядом. И вот примерно оно и будет, продвинутый микропроцессор с устройством ввода команд.

Когда задачи стали больше (а аппетит приходит во время еды - процессор изначально отнюдь на управление космическим кораблем не затачивался, так, сложит пару чисел - уже счастье), и программы тоже, вводить по 200-300 команд каждый раз стало неинтересно. И сделали перфокарты. А потом вместо механических дыроколов - программу для продырявливания перфокарт. А ассемблера все еще не было - были таблицы соответствия: чтобы вычесть, проколи 2-ю и 3-ю дырку сверху, а чтоб передать из регистра в регистр, 3-ю, 5-ю и 6-ю. И в таблицах были записаны для краткости именно мнемоники. И машинный код - те самые дырки. Программа писалась на листочке. Бумажном. Мнемониками. Потом ее несли оператору, который по таблицам дырявил картонку, вставлял в считыватель - и поехало. То есть если под ассемблером мы понимаем компилятор - вот тот самый оператор с дыроколом и был ассемблером.

И пока с перфокарт не ушли до текстового ввода-вывода, ассемблер был не нужен. Потому что текст программы для трансляции набивать дырочками гораздо дольше, чем "скомпилированную". А как только с текстовым вводом-выводом проблему решили, то от ассемблера-человека решили избавиться. И конечно же текст программы первого ассемблера написали на мнемониках, на листочке, перевели в машинный код уже испытанным методом, записали - и стали использовать. Как-то так оно и появилось.