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

l_inc

Угу. Ну а если кто-то ещё не уловил разницу (Вы-то поняли, не сомневаюсь), на всякий случай поясню.

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

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

Ни в коей мере. Я уже упоминал, что часть IBMовских мэйнфреймов использовала чисто схемное управление, без микрокоманд, но это не делает их систему команд RISC'овой. Например, там есть такие операции, как строковые или десятичная арифметика, причём сами двоично-кодированные десятичные числа имеют переменную длину (от 1 до 16 байтов, т.е. от 1 до 31 десятичной цифры + знак). Т.е. и сложные CISC-команды тоже иногда реализуются чисто аппаратно.

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

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

Кстати говоря, на самом деле микрокоманды отнюдь не просты. Они просты в том смысле, что выполняются железом за один заход, но задают при этом множество действий сразу, поэтому их длина колеблется от нескольких десятков до нескольких сотен бит в зависимости от устройства процессора. Похоже, ассемблер IA-64 (Itanium) по своей сути близок как раз к микрокомандам (а может, таковым и является в чистом виде: не вникал-с).

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

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

1. Ошибку можно допустить всегда и везде.
2. Не всякая ошибка ведёт к полной неработоспособности подсистемы, а следовательно, не всегда может быть обнаружена и устранена сразу. Формальная верификация, конечно, помогает, но её для этого надо проводить Ну а проведение её что для микроядра, что для монолитного вполне возможно, если для монолитного ядра соблюдаются требования чёткого деления на модули и неукоснительного следования правилам взаимодействия между ними (поскольку в этом случае придётся анализировать не сразу всю "кашу" монолита, а его отдельные кусочки, по сложности примерно соответствующие таковым у микроядра).

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

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

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

 

SII

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

Для RISC-инструкций, реализуемых напрямую железом без микрокода, нет никаких "включить мультиплексоры". Все сигналы от битов инструкции идут в один такт на соответствующие мультиплексоры различных компонентов (хотя и для микроопераций это, кстати, не обязательно, т.к. если вспомнить какой-нибудь write miss в разделяемый блок в SMP, инициируется целый протокол, имплементируемый железом). Поэтому я всё ещё не понимаю, чем Вам не нравится реализация RISC-like operations, как RISC-инструкций, а не классических микроопераций. То, что операции микрокода поддаются большему распараллеливанию из-за меньшего числа взаимозависимостей? Ну дык максимальное распараллеливание как раз и достигается переупорядочиванием зависимых RISC-инструкций.

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

Это смешно. Ну допустите ошибку при передаче сетевого пакета между машинами, у которых нет сетевых интерфейсов. Трудно, не так ли?

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

Ну и на том спасибо. Вообще, по-моему, восстановление explorer.exe в винде (понятно, что к ядру и его архитектуре это не имеет отношения) — наглядный пример перезапуска подсистемы (в более общем смысле слова) после сбоя. Я иногда (редко, но всё-таки) замечаю его перезапуск только по короткому мельканию панели задач из-за полноэкранного окна браузера. Так вот то же самое было бы возможно и с некоторыми (ясно дело, что не со всеми) ядерными подсистемами.

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

А теперь контр-пример. Рухнул драйвер beep.sys. Что сделает винда? Правильно, BSOD, все данные утеряны. А ещё давайте вспомним, какой драйвер использовался Рутковской для проникновения в ядро. Что, неужели null.sys? Очень важный драйвер. Наверняка, важнее ntfs.sys, не так ли?

В монолитном ядре результат битых на винте данных точно так же ни к чему хорошему не приведёт. Вы ещё припомните попадание метеорита в системный блок. А ещё лучше давайте только его и рассматривать. Вот какие преимущества у производительности монолитного ядра, размазанного по кратеру метеорита? Никаких? Значит производительность у обеих архитектур одинаковая.

Так как раз в этом и преимущество: к TCB в основном относится вот тот небольшой объём кода, обеспечивающий взаимодействие модулей.

Именно. А в монолитном ядре не зависит. Что ни хакнет — всё плохо (про null.sys см. выше).

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

 

SII

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

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

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

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

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

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

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

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

 

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

 

насче микрокоманд - это чтото в таком роде

 

Mikl___

дык что тут? сказали ж выше (SII?) как дальнейшее развитие маркировок на перфолентах и перфокартах.
были еще любопытные взгляды на вопрос. например, серия МИР

 

l_inc

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

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

В общем, пока нет достоверной "низкоуровневой" информации о внутреннем устройстве современных процессоров, нельзя сказать наверняка, происходит трансляция CISC-команд IA-32 в RISC-команды или же в микрооперации. Но, судя по тому, что постоянно используется второй термин, а первый входит обычно в словосочетания вроде RISC-like, лично я придерживаюсь мнения, что трансляция ведётся именно в микрооперации, т.е. внутри нет никакого RISC-процессора, а есть обычный набор разных блоков, работающих под управлением микропрограммы.

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

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

 

SII
Видимо, пример с кирпичом оказался не очень наглядным. Более простой пример. Есть прямая связь между напряжением, поданным на контакты ползункового реостата, и силой текущего между ними тока?

 

l_inc
Ваши примеры банально неудачны и совершенно не связаны с вопросами разработки ПО. Действие закона всемирного тяготения или там закона Ома не зависит от субъектов, на которые они действуют, и определяется вполне однозначно; по-иному они просто не могут действовать. Однако архитектура программного комплекса (ОС, в частности) никак прямо на его качество не влияет, она может лишь способствовать повышению или понижению оного. То же самое относится и к языкам программирования. Си/Си++ ужасны в плане надёжности, но это не означает, что на них нельзя создать работоспособную и даже безглючную программу, равно как применение Ады отнюдь не означает автоматом, что любой написанный на ней код будет гарантированно корректным.

 

SII

Мои примеры — предельное упрощение вопроса разработки ПО. По Вашему, прямой связи между напряжением и силой тока нет, потому что напряжение — не единственный фактор, влияющий на силу тока. Аналогично с разработкой ПО. Я так понимаю, Вы вполне согласны, что выбор микроядерной архитектуры положительно влияет на надёжность. Но вы отказываетесь признать прямую связь лишь потому, что существуют и другие факторы вроде глупости программистов, которые могут нивелировать влияние выбора более надёжной архитектуры.

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

 

l_inc
Напряжение влияет на силу тока напрямую вследствие того, что закон Ома -- "прямого действия".

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

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

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

 

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

 

SII

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

 

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

С тем, что микроядерная архитектура упрощает ловлю ошибок, я сам говорил, так что, конечно, согласен.

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

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

А вот тут и начинается торг. Если некая группа разработчиков обеспечит приемлемое качество системы за приемлемое время и для микроядра, и для монолита, что выбрать? Скорей всего, монолит: выше производительность. Хотя, если разрабатывается нечто, где качеством №1 безусловно является надёжность, то есть смысл выбрать микроядро (при условии, естественно, что оно способно уложиться в ограничения по производительности: толку от абсолютно надёжной системы, если она не будет успевать выполнять свою работу?).

 

SII
Мне, если честно, уже несколько сообщений назад поднадоело. Когда техническая составляющая себя исчерпала, чисто философская дискуссия вроде "косвенный фактор или прямой" получается скучная.

 

SII

нет. не то. это совсем разные подходы со своими достоинствами и недостатками

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

разговор тут не о той надежности. просто автономный аппарат может быть за 10000км в местности без дорог, стоимость 1 ед обслуживающего персонала может сравниваться или превышать всю планируемую выручку от аппарата. и гонять это расстояние каждый раз когда очередные юные хацкеры завесят систему ради "гыгыгы" не совсем резон. предусмотреть все варианты некомпетентного, нецелевого, неадекватного, злонамеренного и прочего просто невозможно, особенно если возможность контроля == 0.
потому попытка сократить потери при сбое и время полностью автоматического восстановления нормальной работоспособности. микро с этим справляется лучше монолита.

монолит быстрее и не привязан к строгим интерфейсам (не знаю хорошо ли это). этим все сказано за.

есть и объединенные решения в которые стуктурно микро., но на этапе сборки нужные базовые наборы дров и сервисов компилятся в 1 файл. и подгружается только кое что (тяжелые сервисы, протоколы, не доверенные и экспериментальные дрова)

не так все сложно. даже проще чем в монолите. примерно как чтение и запись файлов. вы ведь не задумываетесь над задержкой чтения диска?

 

В статьях упорно упоминается, что Assembler является языком с императивной парадигмой, в то время как терминологическое определение "императивная парадигма программирования" предполагает тотальный контроль над действием; наверное, все же императивность в данном случае косвенная, так как, исходя из всего вышесказанного в ветке, ассемблер по сути своей обладает декларативной парадигмой (программа «декларативна», если она описывает каково́ нечто, а не как его создать).