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

Вот он, сладкий пупсик.
2 регистра вроде, и еще один специального назначения.
Подробностей уже не помню, но мог в морской бой играть.

 

Интересно... С точки зрения логики интересно: относительно конечного результата (написание программ на мнемониках) теоретическими мнемониками (то есть семантически ясными для человека терминами и сокращениями на бумаге, или проще говоря в теории) была сформирована программа, транслирующая целевые мнемоники (на уровне текстового ввода-вывода) в инструкции процессора. Эдакое рекурсивное самоопределение получилось. Хм... :-/

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

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

У меня начинает ассоциироваться понятие "компьютер", точнее принципы его работы со своего рода философией.

 

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

А вы что, думали, что сначала откопали обломки терминатора из будущего, потом докопались до машинного кода, и назначили этим кодам мнемоники??? Процессор вырос из арифмометра и счетных машин. Даже вроде на некоторых специальностях курсовую дают: придумайте систему команд для гипотетического процессора. Опкоды не с потолка назначали. Самые часто используемые и необходимые команды - 1 байт. Для кодировки регистров - набор бит. Почему SSE3 сложные в плане опкодов? потому что все байтовое пространство было занято. Осталось несколько "префиксов для расширения", к ним привязывали новые команды. Чтобы совместимость не рушить.

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

 

FatMoon
У первых машин, как уже писал, никаких байтов не было, были только машинные слова, обычно приличной разрядности. Команда как раз занимала полное слово. Можете, если интересно, посмотреть на www.computer-museum.ru -- там были описаны некоторые древние машины вроде нашей ламповой "Стрелы" или более поздних, уже транзисторных, "Минсков".

Что касается IA-32, да и вообще всех процессоров/микроконтроллеров разработки Intel (кроме, может быть, IA-64, которые "Итаниумы": в них не ковырялся), то они очень хорошо демонстрируют, какой не должна быть архитектура и система команд. Сложная и запутанная кодировка у IA-32 -- как раз следствие полнейшего идиотизма архитекторов Intel, а впоследствии и AMD (которая, как известно, прикрутила к IA-32 64-разрядную систему команд, впоследствии скопированную Интелом). Вот ребята, которые собственно создают процессоры, т.е. разрабатывают микроархитектуру (то, как процессор устроен внутри), -- молодцы, ибо умудряются на столь плохой системе команд достигать великолепной производительности...

P.S. А насчёт философии сказал бы резче. Это философы античности определённую пользу приносили, поскольку тогда не было отдельных наук как таковых, и всем занималась философия. Ну а современные философы -- это бездельники и демагоги.

 

scf
Какое отношение эти азы имеют к тому, что я сказал? Во-первых, "в том же ключе" совсем не означает идентичные формулировки. Во-вторых, что Вам читали — совсем не обязательно истина в последней инстанции. Что же до постов SII, то я не буду расписывать каждое слово, к которому я мог бы придраться, т.к. SII пишет гораздо больше и быстрее, в результате чего я остаюсь всё равно в проигрыше. Опыт уже имеется. Поэтому выдеру одну фразу:

Я очень плотно знаком с RISC-архитектурами, в которых это ни разу не правда. Например, в Arctangent-A4 (официально недокументирована) инструкция может содержать long immediate value, удваивающее длину инструкции. Пока процессор не выберет, не декодирует её и не определит, содержит ли она ссылку на long immediate, он не сможет решить, как ему декодировать следующее машинное слово (которое может быть long immediate, а может быть следующей инструкцией).

 

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

На практике всё это оказалось эффективным лишь до некоторого предела. Так, RISC-процессор за единицу времени может выполнять больше команд, чем CISC, однако там, где CISC'у требуется выполнить одну команду, RISC'у зачастую приходится выполнять несколько -- и в результате лидером по производительности, а не пиковому быстродействию, часто оказывается именно CISC. Кроме того, для кодирования нескольких команд в общем случае требуется больше памяти, чем для одной, что приводит к увеличению размера кода, а это, в свою очередь, увеличивает требования к объёму кэша и пропускной способности памяти для обеспечения той же производительности... В общем, практика показала, что в своём изначальном виде идея RISC-архитектуры порочна, и её стали видоизменять и расширять. В частности, у довольно многих процессоров, которые именуют RISC'ами, появились команды переменной длины, операция деления и некоторые другие медленные инструкции и т.д. В общем, развитие пошло в сторону усложнения архитектуры, и нынешние так называемые RISC-процессоры (те же ARMы) по большинству своих характеристик не шибко-то соответствуют изначально заложенным в этот термин идеям. Ну а от того, что процессор назовут RISC'ом, он таковым не станет -- точно так же, как не станет микроядерной ОС от того, что в ней реализуют некоторые элементы, изначально заложенные в идею микроядерности. Вероятно, этот самый недокументированный Arctangent-A4 таким псевдо-RISC'ом и является. Ну так если сравнивать с IA-32, то абсолютно не RISC'овые IBM'овские мэйнфреймы тоже могут RISC'ами показаться

Кстати, нагляднейший пример отсутствия прямой связи между формальной архитектурой (RISC или CISC) и реальной производительностью являют собой современные процессоры Intel. Хотя на некоторых специфических задачах RISC'и им могут составить достойную конкуренцию, но на задачах "вообще" тягаться с ними очень мало кто может. Другое дело, что столь высокая производительность достигается огромной сложностью самого процессора, а значит, высоким энергопотреблением, ценой и т.п., но, когда первые RISC'и только появлялись, эта идея подавалась именно как способ повышения производительности, а отнюдь не снижения цены или потребления! Но, как уже говорил, увы и ах: лидерами по производительности являются CISC'и, а выжившие RISC'и постепенно приближаются к ним по сложности.

А насчёт Ваших проигрышей... Это скорей не из-за скорости, с которой я флужу (или флудю) на форумах, а из-за того, что я предпочитаю охватывать проблему целиком, а не кусочками. Можем вспомнить, например, спор про виртуальные адреса в Винде, где, если не ошибаюсь, Вы упорно держались за 32-разрядную архитектуру IA-32 с её сегментной моделью, игнорируя и изначальную мультиплатформенность Винды, и то, что сама Мыкрософт вложила в это понятие в функциях API. Так и здесь: Вы исходите из того, что, если в неких архитектурах есть команды переменной длины и эти архитектуры называются RISC'ами, то, значит, у RISC'ов команды переменной длины допустимы, -- но, похоже, Вы не допускаете и мысли, что разработчик архитектуры использует термин RISC совсем не в том смысле, какой в него вкладывался, а соответственно, попросту врёт.

Кстати, из-за такого размывания терминов регулярно придумывают новые (они, правда, обычно не пользуются широким распространением). Кроме RISC'ов, позднее выдумали MISC'и (минимальная система команд); а вместо микроядра, которое благополучно превратилось в слегка облегчённое монолитное (см. QNX), выдумали наноядро (интересно, пико- и фемптоядра уже существуют? )... Вот отвечали бы разработчики за базар (и за качество разработок) -- всё было б куда проще, понятней и надёжней. Но это лирика-с.

P.S. Всё это пишу не для того, чтобы Вас переспорить, а чтобы показать народу, насколько вольно обращаются с терминами в наше время. Может, это тоже проявление политкорректности? ))

 

SII
Ну вот. Началось.

Вообще неправда. И именно поэтому внутренняя архитектура Intel (как бы Вы этому не сопротивлялись) именно RISC'овая, основанная на микрооперациях. Блоки переупорядочивания, предсказания переходов, переименования регистров и т.п. работают с микрооперациями ради повышения производительности, а наружу для программиста действительно торчит CISC'а в целях совместимости. И глупость разработчиков Intel здесь не причём: ранее было важно делать инструкции как можно меньше в целях экономии памяти, а потом было уже слишком много написано под x86. Терять совместимость и соответственно рынок и соревноваться с новыми архитектурами только ради того, чтобы сделать проще архитектуру — вот это было бы глупостью. Где там Itanium'ы со своими 128-битными VLIW'ами? Несколько лет ещё, и их не станет. Вот поэтому и сидит Intel на своей золотой корове, всячески извращаясь с нехилыми наворотами вроде симультанной многопоточности (не знаю, как в русских источниках называется) в виде HT?

Микроядра (и именно так они и называются) находятся и по сей день в активной разработке (особенно ввиду практической возможности проведения формального доказательства корректности для небольшой доверенной кодовой базы, где, кстати и находится отрицаемая Вами прямая связь между надёжностью системы и архитектурой). Хотя на данный момент портирование системы под ту же Fiasco — это ой какая головная боль из-за крайне неудачных интерфейсов и кучи багов. Но на подходе уже усовершенствованные решения.

 

l_inc

Дык... Холивар -- святое дело

Извините, но здесь Вы написали полную чушь. Микрооперации к RISC'ам вообще никакого, ну ни малейшего отношения не имеют. Они и появились-то задолго до этих самых RISC'ов, а именно в 1960-х годах. Начиная примерно с их середины, а реально и несколько раньше, на микропрограммном управлении были построены все мини-ЭВМ и почти все мэйнфреймы (та же IBM'овская Система/360, анонсированная в 1964 году, или наша БЭСМ-6, пошедшая в производство с 1967-го).

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

Такие вещи, как переупорядочивание порядка выполнения инструкций, предсказания переходов и т.п., появились примерно тогда же, когда и микропрограммное управление (ну, чуть позже). В частности, о том, что процессор может выполнять команды не в той последовательности, как записано в программе, и даже несколько за один "присест", но при этом гарантирует такие результаты, как если бы программа выполнялась строго последовательно, прямо пишется в "IBM System/370 Principles of Operations" (а сама Система/370, пришедшая на смене Системе/360, начала продаваться с 1970 года, и в старших её моделях действительно применялись все эти средства повышения производительности). Кстати, там же в связи с этим описывались особенности программирования для многопроцессорной системы: второй процессор может увидеть в памяти не те результаты, поскольку первый может выполнять команды в "неправильном" порядке.

Глупость разработчиков Intel не в том, что они совместимость сохраняют, а в самой изначальной архитектуре 8086 и в подходах к её расширению. Для начала они создали ужасную систему команд ради мифической "логической" совместимости с 8080 (тоже не блещущий гениальностью процессор, но для 8-разрядного простительно многое из того, что для 16-разрядного выглядит полным идиотизмом): каждой команде 8080 у них соответствовала определённая команда 8086, хотя кодировка полностью различалась. В результате получилась неудобная для работы и малоэффективная, в том числе по расходу памяти, система команд. Хотя в некоторых случаях код на 8086 действительно мог оказаться короче, чем на тоже 16-разрядных PDP-11, Z8000 или 68000, но в абсолютном большинстве случаев одна и та же программа на 8086 занимала больше места, требовала больше команд и выполнялась медленнее (при одинаковой тактовой частоте, конечно: понятное дело, что 8-МГц 8086 работал быстрей, чем 1-МГц кристаллы вроде нашего К1801ВМ2 -- клона DEC'овских с системой команд PDP-11). Одной из причин здесь был неуниверсальный характер регистров "общего назначения" 8086, из-за чего их постоянно требовалось сохранять и восстанавливать, причём изначально это нельзя было сделать одной командой (PUSHA/POPA появились, кажется, в 80186). В других упомянутых архитектурах регистры за парой редких исключений полностью равноправны, ну а PDP-11 и вовсе может выполнять любые операции только с памятью, что нередко резко сокращает число команд на реализацию того же самого алгоритма.

Когда делали 80386, то вместо создания новой, нормальной системы команд просто тупо расширили старую. Между тем, никаких технических причин делать это не было: та же DEC, создавая свои 32-разрядные VAX-11, реализовала в них "идейно" близкую к 16-разрядной PDP-11, но намного более развитую систему команд, причём кодировка самих команд полностью отличалась, что не мешало VAX-11 исполнять прикладные программы от PDP-11: просто у процессора был предусмотрен режим эмуляции. Учитывая, что в 80386 транзисторов было больше, чем в нескольких процессорах VAX-11, реализовать подобный ход могли без каких-либо проблем, но, видать, религия не позволила создать новую систему команд с новой же кодировкой, учитывающей многолетний опыт ИТ-индустрии.

Много позже абсолютно ту же ошибку допустила AMD, из-за чего 64-разрядный режим стал ещё более идиотским в плане кодирования команд и имеет ряд нелепых ограничений.

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

Кстати говоря, инженеры, которые создают нутро процессоров Intel, молодцы, тут ничего не скажешь: обеспечить столь быстрое выполнение для столь мерзкой системы команд -- это действительно интеллектуальный подвиг.

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

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

Прямую связь я отрицал и буду отрицать: её нет. Есть связь косвенная: настоящая микроядерная архитектура в силу своих особенностей действительно упрощает написание надёжной системы и её формальную верификацию. Тем не менее, написать кривую и глючную микроядерную систему вполне возможно, как возможно написать и "прямую" систему с монолитным ядром. Или, если угодно, мою мысль можно выразить по-другому: от того, что система имеет микроядерную архитектуру, она не становится автоматически более стабильной и надёжной, чем система с монолитным ядром, поскольку качество системы зависит не от архитектуры, а от качества проектирования и реализации. Надеюсь, не надо доказывать, что 10 высококвалифицированных программистов смогут создать более надёжную систему, чем 1000 индусских быдлокодеров?

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

Кстати, провокационный вопрос Почему это в микроядерной системе куча багов? Да и "на подходе", кажется, не одно десятилетие продолжается...

 

Да, это было своеобразно и даже приятно - ДВК, супер-компьютер БК01... и можно сколько угодно плеваться в несуразную архитектуру интела - но ПОЧЕМУ рынок остался у Интела, если все так плохо? Почему везде интел и интел-совместимые? Не убедили. Вовсе не в том дело, что у интела более способные менеджеры и пиарщики, и бизнесмены они хорошие. Вертикальная совместимость как раз и причина. Они не топтались на месте, ожидая, пока кто-то скомпилит новый софт под новую совершенную систему команд. Они дали стандарт - пишите ТАК и под ЭТО. А мы гарантируем, что во всех следующих процессорах все будет работать аналогично. Ну за некоторым исключением, не надо трюки использовать и недокументированные возможности.

и у интела хватило смелости сначала выпустить итаниум, потом практически плюнуть на него и поддержать АМД 64 - именно из соображений совместимости. Процессор сейчас - ничто. Софт - все. Нельзя пускать разработанный софт в корзину, если новый процессор использует другую систему команд. Легче отказаться от процессора. Готовы делать гениальный процессор и гениальный софт - вперед. И это останется для узко-специализированной задачи в каком-нибудь НИИ, и 10 лет будет работать, наполняя гордостью сердца - "Наш компьютер совершеннее всех аналогов на момент создания. Это архитектура, превосходящая Интелы на порядок!". А через 10 лет этот гениальный комп останется на той же стадии, и выполняться будет на нем все та же задача + написанные от скуки программистом тетрис и еще пара игрушек. А Интел шагнет вперед и будет - о, ужас! - выпускать все те же процессоры с неудобной, тьфу на нее, системой команд, на которых аналогичная задача все-таки будет выполняться быстрее. А гениальная разработка, с уникальным софтом, уйдет на склад и в лом. Потому что кроме этого НИИ, она нафиг никому не сдалась. Винда на ней пойдет? нет. Линух? что, тоже нет? Ах, даже компилятор Це для нее не запилили, вы там собственный язык использовали, "Этюд2М"? молодцы, молодцы. Выкидывайте! )

 

FatMoon

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

а что его запиливать?

 

FatMoon

Вот тут Вы не правы. Точней, насчёт значения совместимости Вы, конечно, правы, но Интел -- далеко не первые. Те же мэйнфреймы IBM, анонсированные в 1964-м и появившиеся на рынке в следующем году, сохраняют практически полную совместимость на уровне прикладного кода с современными, выпускаемыми сейчас -- а это без малого уже полвека. Ну а держатся так долго в т.ч. из-за совместимости, поскольку, пожалуй, первыми в истории с самого начала обещали пользователям, что создадут серию совместимых программно и на уровне периферии машин с разной производительностью, а значит, ценой. То же самое позднее повторилось, например, с PDP-11: DEC выпустил несколько десятков разных моделей, а позднее оставил совместимость на уровне прикладного кода и в VAX-11.

А ошибаетесь в том, что Интел ничего потребителям тогда, на момент появления что самого этого микропроцессора (1978-й, если не ошибаюсь), ни выхода IBM PC (1981-й) не гарантировал, да никто и не рассматривал эту технику всерьёз. Совместимость тогда тоже ещё не играла роли, это впоследствии стало важным, когда для ПК появилась куча ПО. Думается, тут всё ж грамотная бизнес-политика плюс элементарное везение: закрой IBM свой ПК, как это сделала Apple (её Макинтош был, помнится, на 68000, по всем статьям превосходящем 8086), и вряд ли он получил бы сколько-нибудь широкое распространение -- уж очень убогая это была конструкция, помимо убожества его процессора, ну а так -- начали клепать все, кому не лень...

Сейчас -- да, но не в первой половине 1980-х, когда этого самого софта для ПК почти и не было. Ну а ту же постоянно поминаемую мною DEC погубила именно безграмотность бизнес-руководства. Они не разглядели перспектив ПК, поэтому не прикладывали нужных усилий для развития линейки LSI-11 (примерно того, чем у нас были ДВК, только получше; хотя, собственно, первые PDP-11, ещё в самом начале 1970-х, да и более ранние их машины были по своей сущности именно ПК) и для "оперсоналивания" VAX-11 (технически это было уже возможно, хотя стоимость такой персоналки была бы очень высокой -- но зато она прекрасно дополняла бы LSI-11, имея при этом совместимость на уровне прикладного кода); практически всё они бросили на увеличение и без того неплохой производительности VAX'а, фактически пытаясь впихнуть его в несвойственную этим машинам и не шибко перспективную нишу мэйнфреймов (а надо бы наоборот: сделать пускай довольно медленный, но дешёвый микропроцессорный комплект и построить на нём персоналку -- учитывая огромное количество ПО для PDP-11 и VAX-11, их можно было бы продавать в 1980-е, как пирожки, при условии установления разумной цены). Ну а затем влезли в авантюру со своим 64-разрядным RISC-процессором Alpha, который, как известно, провалился. Плюс интересно, с чего это из DEC ушёл Дэвид Катлер -- создатель DEC'овских операционок, а позднее -- Винды НТ. Похоже, они там просто разругались на самых верхах... Как бы то ни было, а DEC вылетела в трубу, а вместе с ней накрылись и самые удачные 16- и 32-разрядные архитектуры...

 

FatMoon

Знаете, дело в том, что каждый человек воспринимает все индивидуально и оперирует терминологией, какой бы она ни была, тоже исключительно индивидуально. Но при всем уважении, так говорить, как минимум некорректно.

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

Я лишь сделал попытку взглянуть на вещи еще более обширно, чем изначально предполагал, задавая вопрос, поэтому это могло показаться вам странным. А сам термин "филсофии" я понимаю как теорию, которая описывает тот или иной вопрос, оперируя абстракциями. А что может быть глубже, чем непосредственно реализация того, о чем говорилось выше? Я лишь счел нужным, да и в принципе считаю нужным, с целью более тонко понять суть вещей, абстрагироваться в некотором смысле, да и воспринимать многие вещи лишь как абстракции (например, тот же термин "программа" является лишь абстракцией над аппаратной реализацией работы компьютера в целом).

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

 

соглашаюсь-соглашаюсь

 

SII

Боюсь, Вы путаете операции микропрограммного управления и микрооперации Intel, представляющие собой настоящие инструкции. После декодирования CISC'овых инструкций интеловские процессоры выполняют реальную трансляцию опкодов в простые RISC'овые инструкции одинакового размера, после чего отправляют их в очередь для микроопераций на дальнейшие стадии исполнения, начиная с буфера переупорядочивания. О сложных длительных операциях вроде rep cmpsb или даже простого add [addr],eax уже и речи нет, их реализация в RISC'овых опкодах считывается из ROM процессора и исполняется со всеми свойственными RISC'ам оптимизациями, как программа для RISC'а.

Причём здесь, когда они появились? Я говорю, что все эти навороты выполняются в интеловских процессорах с RISC-операциями, а не исходными интерфейсными CISC'овыми. Для CISC-инструкций сложность того же out of order execution возрастает в разы, поэтому Intel, начиная с P6, внутренне с ними не работает.

Есть прямая связь между сбрасыванием кирпича с балкона многоэтажки и падением его на землю? Согласно Вашим рассуждениям, нету, т.к. в момент его падения может проезжать машина или пролетать американский томагавк. Вот так же и с микроядром: сторонний потребитель исходит из того, что некоторая компания направляет значительные усилия на то, чтобы избавиться от багов. С учётом этого эти усилия дают значительно больший эффект при разработке микроядерной архитектуры. Вот и прямая связь.

Архитектура — это и есть результат проектирования.

Надеюсь, не надо доказывать, что десять высококвалифицированных программистов смогут выполнить гораздо более надёжное развитие кода, написанного десятью высококвалифицированными программистами (микроядро), чем написанного тысячей индусских быдлокодеров (монолитное ядро)?

Не в микроядерной архитектуре, а конкретно в Fiasco. Разработчики сильно привязали её к linux, под который она изначально разрабатывалась. В результате некоторые механизмы Fiasco основаны на особенностях работы linux (что, кстати, нарушает микроядерную архитектуру), что плачевно сказывается на попытках порта под другие системы. Насчёт "на подходе", не знаю, о каких конкретно десятилетиях Вы говорите. Я имел в виду, например, сравнительно недавнюю (года три ей) Karma, которая на данный момент является всего-лишь интерфейсной прослойкой, значительно упрощающей портирование, причём с использованием аппаратной виртуализации, но сейчас планируется начать снятие ограничений на наличие аппаратной виртуализации (с планами порта, например, на ARM'ы без неё), а в будущем из прослойки сделать полноценное микроядро, если интерфейсы Karma себя оправдают.

 

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

 

l_inc

Судя по имеющимся материалам, трансляция команд IA-32 производится именно в более-менее традиционные микрокоманды, а отнюдь не в некую RISC'овую систему команд. Разница между нынешними процессорами и древними лишь там, что в последних микропрограмма лежала в ПЗУ (ну или в ОЗУ, но динамически не изменялась, а загружалась туда перед запуском процессора), а в современных она генерируется "на лету" в соответствии с выполняемым потоком CISC-команд, а сами микрокоманды могут выполняться не в исходном порядке и иногда одновременно.

Нет, в теории я допускаю именно такую трансляцию, но она будет банально неэффективной в плане производительности, поскольку одна микрокоманда позволяет прямо задать "низкоуровневые" (реально прямо выполняемые железом) операции сразу нескольким внутренним блокам процессора, в то время как RISC-команда не имеет никаких принципиальных отличий от CISC и задаёт лишь одну "высокоуровневую", которую ещё надо преобразовать в "низкоуровневые" (просто для настоящего RISC'а такое преобразование выполняется куда проще, чем для CISC'а, в силу простоты самих команд). Помимо необходимости в декодировании RISC-команды, подобный подход плох ещё и тем, что не позволяет процессору оптимизировать выполнение самих микроопераций. Например, если две идущие подряд настоящие микрокоманды (а не RISC-команды; условно обозначим их A и B) задают работу исполняющим блокам №1 и №2 соответственно, но обе одновременно задают ещё работу и блоку №3, выполнить их одновременно уже оказывается невозможно. В то же время за ними может следовать микрокоманда C, которой нужен только блок №2, и её можно исполнить параллельно с микрокомандой A, если нет зависимостей по данным с микрокомандой B. Ну а интеловские процы, похоже, очень активно не просто транслируют CISC-команды в микрооперации, но ещё и переупорядочивают и группируют эти самые микрооперации...

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

Странное у Вас понятие о прямой связи...

Если говорить про монолитную/микроядерную и т.д. архитектуру, то она -- не результат проектирования, а наоборот, "исходные данные" для начала работы над проектом. Ведь, разрабатывая ОС, не делают, а потом смотрят, что получилось, а сначала смотрят, что должно получиться, и лишь потом делают.

Вы считаете, что монолитное ядро способны написать (и пишут) только тысячи индусских быдлокодеров, но никак не десяток квалифицированных разработчиков?

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

Идея микроядра была высказана то ли в начале 1970-х, то ли даже ещё в 1960-х -- точней не скажу, ибо читал про это дело ещё в 1980-х в бумажном виде. Однако настоящих микроядерных систем, нашедших широкое практическое применение, как-то не шибко заметно. Большинство ОС -- откровенные монолиты, другие (как QNX) подаются как микроядерные, но таковыми не являются... В общем, это явно не мэйнстрим осестроения -- вероятно, не в последнюю очередь как раз из-за того, что реальные преимущества микроядерной архитектуры (упрощение разработки и отладки, что потенциально ведёт к лучшей надёжности) существенно меньше, чем кажется на первый взгляд, а вот недостатки вполне реальны и неизбежны.

 

abcd008
Посмотрите статьи на ixbt про современные процессоры; там в том числе были ссылки на интересные забугорные сайты, где были и такие таблицы. Правда, понятие "времени выполнения" применительно к суперскалярным процессорам не шибко корректно; тут, вероятно, лучше говорить об алгоритмическом времени (числе тактов), потребном на исполнение команды в идеальном случае, и о возможных задержках и их причинах...

Без микрокода же никакие инструкции не исполняются. Просто простые команды (типа MOV EAX, EBX или там OR ECX, EDX) транслируются каждая в одну микрокоманду и выполняются за один такт; кроме того, несколько таких микрокоманд могут быть выполнены вместе, если они не связаны по данным и могут быть распределены по разным исполнительным блокам. А вот для сложных генерируется целая последовательность микрокоманд либо вообще запускается микропрограмма, находящаяся во внутреннем ПЗУ процессора.

 

SII

Ну ничего так заявочка. Т.е. задать одной инструкцией чтение из памяти, сложение значения с регистром, а потом запись назад в память — это оказывается "никаких принципиальных отличий"?

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

Общие базовые механизмы не являются коммерческой тайной и с одной или с другой стороны часто освещаются в статьях и книгах при поддержке инсайдеров (тем более, что трансляция в RISC-микрооперации уже почти 20 лет, как используется Intel). Что пишет Jon Stokes (Inside the Machine):

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

Реальные преимущества в надёжности. Практическая возможность проведения (полу-)автоматизированного формального доказательства корректности значительного объёма кода в разумные сроки существует не так давно (насколько мне известно). Реальные недостатки в производительности. Чтобы система была хоть сколько-нибудь конкурентоспособной, основной упор во многих случаях делают на производительность.

 

l_inc

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

Ну, "микрокод на VHDL" -- это уже полный бред. Поучите матчасть, что ли...

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

В подобных публикациях достаточно информации, чтобы понять общие принципы работы, но совершенно недостаточно, чтобы установить детали. В приведённой Вами цитате ясно написано: by translating x86 CISC operations into smaller, faster, more uniform RISC-like operations. RISC-оподобные операции и RISC-команды -- это всё же разные вещи. В чём именно заключается подобие? Да в двух вещах: в фиксированной длине (классический, настоящий RISC-процессор использует только команды фиксированной длины -- как раз для достижения максимальной простоты и скорости) и в выполнимости за один элементарный шаг (обычно, но не всегда за один такт: например, чтение из памяти может занимать много тактов, но лишь в силу того, что придётся ожидать доставки данных; сама по себе операция остаётся элементарной, не требующей разбиения на кучу других операций). Недаром результат трансляции называется микрооперациями, а не RISC-командами, ведь по сути они являются именно первыми, аналогичными тем, что применяются в машинах с классическим микропрограммным управлением ("неклассическим" здесь является динамическое создание микроопераций для многих исходных команд -- лишь часть из них пользуется готовым кодом из ПЗУ микропрограмм; а также оптимизации в виде изменения порядка выполнения и т.п., но и это применялось и раньше, просто редко в силу большой сложности, которую трудно реализовать на микросхемах, имеющих в лучшем случае десятки тысяч, а не миллионов транзисторов).

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

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

 

SII

Ага. Таки я в проигрыше не только потому, что Вы быстрее пишете. Спасибо. Действительно у меня было неверное понимание понятия "микрокод". Реализация в микрокоде для меня была равносильна реализации напрямую в железе.

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

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

Вы лучше расскажите, в чём их отличие. Потому что матчасть говорит, что Ваше классическое микропрограммное управление в x86 существовало задолго до P6, а вот трансляция в RISC-like operations появилась только в Pentium Pro.

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

Ага. Только Вы забываете учесть различие в "доставании пользователя". В монолитном ядре Вы получите BSOD или полное зависание, а в микроядре свалится одна подсистема и с некоторой вероятностью перезапустится даже незаметно для пользователя.

На самом деле я бы даже сказал, что число строк в микроядерной архитектуре будет бОльшим. Значительно меньшим число строк будет в самом микроядре, относящемся к trusted computing base (TCB), которая и требует тщательной верификации. В монолитном ядре тщательная верификация необходима всем подсистемам ядра в равной степени: что уязвимость в графической подсистеме, что в менеджере объектов — злоумышленник поимеет всю систему. В микроядре он поимеет лишь одну подсистему с ограниченными правами.