OSDev

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

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

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

Самые тщательно продуманные ОС из моей практики -- RSX-11, VAX/VMS и VM/370-- были написаны на ассемблере. Даже весьма хаотичная на первый взгляд OS/360 продумана довольно неплохо. А вот Линух, как и исходный Уних, продуманностью, мягко выражаясь, не отличаются. Винда намного продуманней, но она своими корнями уходит непосредственно в VAX/VMS, и многие идеи пришли оттуда.

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

Программировать можно и на Васике ровно с теми же аргументами: усидчивость и внимательность, инструкции перехода... Ты не задумывался, почему на Васике никто не программирует?


"Чукча не читатель, - чукча писатель" (с)
10% времени занимает написание, а 90% - модификация и отладка, т.е. чтение.


Это почему не в тему? ООП - это сильнейший инструмент повышения производительности труда и повышения надёжности кода.
Я вот посмотрел сейчас, коммерческая база данных по учёту всего, которую я написал для своего предприятия - 20000 строк на С++ (причём, всё сплошь ООП) и SQL. Была написана за несколько месяцев. Я бы треснул писать такую же БД в тот же срок на асме и гарантировать при этом ту же надёжность (за 10 лет работы не найдено ни одной серьёзной ошибки) и ту же сопровождаемость (можно открыть проект в любой момент и что-то добавить). По правде говоря, на асме я бы даже не взялся за эту работу.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Я не могу похвастаться практикой RSX, VAX, VM/370. Программировать начинал на OS/360 на PL/1 в основном. Но боюсь это не аргумент, поскольку на всю жизнь не научишься. Программист глубоко знает только технологии последних пары лет. А о таких древностях - светлые воспоминания из юности. Продуманность идеологии IBM/360 была конечно весьма высокой. Но и цена тоже. Это была эра дорогих машин и дешевых людей. Поэтому программирование в те годы, когда разрабатывались упомянутые операционные системы было совсем другим ремеслом. Сегодня все наоборот. Сегодня эра дешевого железа и дорогих программистов. В юности вообще деревья были выше и небо светлее. Под той же IBM/360 можно было программировать под PL/1 и ассемблером в основном. И как бы, однажды потребовалась такая штука как простейший перекодировщик текста. Дело было году эдак в 87-88. Нужно было из DKOI перекодировать куда-то в KOI-7 кажется. Перекодировшик на PL/1 помнится на EC-1022 минут за 20-ть перекодировал строчек 10-ть текста. Потом ассемблерная версия 250 страниц того же текста перекодировала секунды за полторы. Это о тогдашней продуманности. PL/1 по сравнению с современными Java и .Net пожалуй вряд ли выигрывал концептуально. После PL/1 Си показался просто верхом изящества. Я не знаю как можно сравнивать такие древние архитектуры и сегодняшние компьютеры. "Вы были когда нибудь на Таити? Нет? Ну так вот..."

Линукс не сразу к юниксам причислили. Школьники причислили, чтобы гордо причислять себя к UNIX сообществу, а юниксоиды, чтобы погреться под лучами популярности Linux. Долгое время после появления Линукса юниксом его многие считать не хотели. Юниксов было два SysV и BSD. А Linux ни тем ни другим не являлся и вообще был писан на коленке и позволял такие вещи, какие приличные юникса позволить не могли. Ввиду борьбы за чистоту архитектуры. Сегодняшний Линукс вообще ушёл о UNIX-ов делеко. Поэтому ругать вместе и UNIX и Linux, на мой взгляд, слегка неверно. Linux не юникс. С таким подходом можно вообще все операционки объединить в одно целое.



Языки программирования, вроде Java отличаются от предшественников большой продуманностью технологий программирования, мощными средствами юнит тестирования, средствами continuos integration, средствами статического анализа кода, прекрасными средами разработки типа Intelij IDEA и т.д. Поэтому постараться использовать все выше перечисленное в разработке ОС является мудрым решением. Баланс между производительностью, чистотой концепций, простотой архитектуры и прочее достичь сложно. В этом и заключается мастерство архитектора ОС, чтобы прикрутить виртуальную машину в Операционную Систему эффективно. Пока красиво это сделать никому не удалось.

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

Если использовать Calling Conventions cdecl почему не воспользоваться Cи?

Да некоторые ассемблеры позволяют контролировать изменения регистров. Например встроенный ассемблер в gcc в расширенных выражениях позволяет указывать через какие регистры передаются параметры и результаты, и какие регистры меняются. Это круто и правильно. Но когда моя команда работала на Си++ и ассемблере, я не представлял, что проекты с zero bug quality могут программироваться месяца за три (включая обсуждение технического задание, документирование, программирование, покрытие юнит тестами, функциональное тестирование и полную сдачу в эксплуатацию). А сейчас такое возможно (на Java для японцев)... На Си++ и асме такие сроки просто нереальны. Плюс баги никогда не возвращаются. Сдали, оно работает... Хочется такого же и в ОС.

Я одно время внедрял FreeBSD массово в качестве маршрутизаторов. Было это в до Cisco-вскую эпоху. Так вот FreeBSD образца 1996 года подвисала в среднем раз в месяц. У меня их было штук 50-т. Соответственно дважды в день мне или админам приходилось звонить и объяснять электрику или тетке где-то в полях, как перегрузить комп. Приходилось жить на работе (мне сильно наскучило тогда из ядра лишние модули выпиливать, чтобы найти конфигурацию, которая будет работать максимально стабильно). Поэтому надежность операционной системы и кода вообще - на первом месте.

Ассемблер - круто. Но чудес не бывает. Человеческий фактор нужно уменьшать. Для этого и нужны ЯВУ.

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

Это, кстати, ещё одна причина, почему я не использую Си и иже с ним: читабельность очень плохая, если сравнивать с Паскалем/Адой.




Ну дык это типично прикладная программа, а не ядро ОС. Всему своё место, как говорится.

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

Извините, но насчёт скорости кода на ПЛ/1 -- бред. Естественно, на ассемблере было быстрей, и можно было очень круто оптимизировать, но такого разрыва быть не могло, если хватало памяти (а на ЕС-1022 её банально могло не хватать). Но это лирика.

А "физика" заключается в том, что сейчас системы захламлены кучей всяких дополнительных плюшек и сервисов, которые зачастую прикручиваются совершенно бездумно и за которыми не видно сути. На древней технике такого не было хотя б по той причине, что на всю эту фигню не хватило бы ни памяти, ни производительности процессора. Вдумайтесь: многозадачной многопользовательской (!) и с виртуальной памятью RSX-11 для работы было достаточно 248 Кбайт ОЗУ (реально даже меньше; собственно система со всеми драйверами не сжирала и сотни). Ну и сравните это... Нет, не с Виндой и Линухом, а с MS DOS, которая была однозадачной однопользовательской и без всякой виртуальной памяти (и лишь последнее нельзя было обеспечить в принципе на процессоре, лишённом MMU, т.е. на 8086 и его последователях), пожирая при этом больше 100 Кбайт ОЗУ только под себя -- а ведь за ввод-вывод отвечал BIOS, зашитый в ПЗУ (ещё несколько десятков килобайт). Та же OS/360 могла работать на машине со 128 Кбайтами памяти, пускай медленно и печально; для VM/370 хватало 512 Кбайт (напомню, это система виртуальных машин, а не просто ОС), ну и т.д.

В общем, в старых системах -- и программных, и аппаратных -- есть много вещей, которым стоило бы поучиться.



Ещё как верно. Идеология-то у систем во многом общая, API -- тоже (не техническая реализация вызовов и т.п. детали, а именно идеология). Так что Линух -- законорожденное (хоть и не в законном браке ) дитя Униха.



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

Кстати, о читабельности. Оформление кода и комментарии очччень сильно в этом деле помогают. У меня, грубо говоря, четверть исходников, если не больше -- это комментарии к коду.

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

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

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

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

Моё мнение -- самое кошерное, конечно же

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

К сожалению, найти вменяемый инструментарий для Ады достаточно сложно. По-настоящему доступен лишь GNAT, наследующий все недостатки GCC, частью которого является (низкое качество кода, в частности), но добавляющий и новые проблемы: фронт-энд явно хуже отлажен, чем для Си, поэтому бывает, что компилятор падает на совершенно корректной программе. Правда, с используемой сейчас версией (4.5.3 для АРМа и 4.6.2 для ИА-32 -- собирать её под АРМ лениво) падений компилятора пока не было, тьфу-тьфу-тьфу...