Почему бы не иметь ОС на основе языка высокого уровня? Являются ли языки низкого уровня более эффективными?


44

Не будучи самонадеянным, я хотел бы, чтобы вы рассмотрели возможность этого. Большинство современных ОС основаны на довольно низкоуровневых языках (в основном C / C ++). Даже в новых, таких как Android, используется JNI, а основная реализация находится на C

На самом деле (это личное наблюдение) многие программы, написанные на C, работают намного быстрее, чем их высокоуровневые аналоги (например: Transmission (клиент bittorrent в Ubuntu) намного быстрее, чем Vuze (Java) или Deluge (Python) ). Даже компиляторы Python написаны на C, хотя PyPy является исключением.

Так есть ли конкретная причина для этого? Почему все наши так называемые «языки высокого уровня» с отличными концепциями «ООП» не могут быть использованы для создания надежной ОС?

Итак, у меня есть 2 вопроса в принципе.

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

36
Вы подразумеваете, что только «Языки высокого уровня» являются объектно-ориентированными, что не соответствует действительности.
Uooo

2
@rtindru "Довольно низкоуровневый язык" (в основном C / C ++)? Каково ваше определение языка высокого уровня тогда? Вы должны четко понимать свое определение / толкование языка высокого уровня. Python на самом деле является языком сценариев, так как он исполняется непосредственно на своем движке (IDLE или терминал командной строки), если вы этого еще не поняли. Есть очень веская причина (философская и практическая), почему C / C ++ используются в качестве языков реализации для многих ОС, но я уверен, что опытные пользователи здесь, вероятно, не будут вдаваться в подробности по этому вопросу.
hagubear

10
Android не является новой ОС. Это просто еще одна разновидность Linux.
Ден

3
@hagubear Существует очень веская причина (философская и практическая), почему C / C ++ используются в качестве языков реализации для многих ОС . Что это за очень веская причина?
rtindru

2
Если я правильно понимаю, ОС для LISP-машин была написана на LISP. Хотя, возможно, можно утверждать, что используемый диалект был языком низкого уровня?
Роберт Фишер

Ответы:


38

Microsoft провела несколько очень интересных исследований в этом направлении, если вы посмотрите на Singularity:

http://research.microsoft.com/en-us/projects/singularity/

Кроме того, Моти Роско и другие работали над Barrelfish, который использует язык программирования ограничений Eclipse в качестве службы ОС для решения всех видов проблем управления ОС и распределения ресурсов:

http://www.barrelfish.org/


Вау, я не могу голосовать, нужно 15 представителей ... только что присоединился сегодня! Большое спасибо.
rtindru

9
@rtindru: даже с 1 точкой повторения вы можете принять ответ. Что это значит, когда ответ «принят»?
Марьян Венема

6
Принятие ответа имеет тенденцию сокращать новые ответы / обсуждение. Лично я бы рекомендовал не принимать (к этому конкретному вопросу) хотя бы еще один день.
Брайан

1
Я бы добавил Космос в связку: с открытым исходным кодом, третье лицо, не такое интересное, как сингулярность, но у меня есть хорошие идеи! cosmos.codeplex.com
Лоренцо Дематте

38

Многое зависит от того, где вы поместите разделение между языками низкого и высокого уровня. Например, разные люди склонны ставить язык, подобный C ++, по разные стороны этого разрыва.

По поводу ваших вопросов:

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

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

  2. Если вы считаете C ++ высокоуровневым, то есть хотя бы одна ОС, полностью написанная на языке высокого уровня (Symbian OS написана на C ++). То, что мешает вам писать ОС на большинстве языков высокого уровня, это две вещи:

    • Операционная система нуждается в низкоуровневом доступе к памяти и оборудованию и выполняет грязные трюки с ними. Этот вид доступа обычно считается небезопасным для программ прикладного уровня, поэтому многие языки высокого уровня этого не допускают.
    • Операционная система должна выполняться без присутствия вспомогательного программного обеспечения, такого как интерпретаторы. Это крайне затрудняет написание ОС на языке, который не может быть легко скомпилирован в нативные инструкции.

35
Не существует такого понятия, как интерпретируемый язык или язык, который компилируется с нативными инструкциями. Язык - это набор математических правил, он не интерпретируется и не компилируется, он просто есть . Interp. и комп. черты интерпретатора или компилятора, а не язык. Каждый язык может быть реализован с использованием компилятора или интерпретатора. Большинство современных языков имеют как интерпретируемые, так и скомпилированные реализации. Есть интерпретаторы для C и все основные реализации JavaScript, компилируемые в нативный код. А что такое нативный код? Если я скомпилирую Java в байт-код JVM и запустлю
Jörg W Mittag

11
что на процессоре Java, и я компилирую C в машинный код ARM и запускаю его на интерпретаторе ARM, потому что на моем компьютере нет процессора ARM, тогда что делает ARM нативным, а JVML - нет?
Йорг Миттаг

5
@ JörgWMittag: Если у вас есть процессор, который может напрямую выполнять байт-код Java (без использования дополнительной JVM), то байт-код Java является собственным кодом для этого ЦП. Кроме того, я не исключаю возможности написания ОС на языке, который обычно интерпретируется или исполняется в ВМ, но это делает их менее очевидным выбором.
Барт ван Инген Шенау

15
@ JörgWMittag - Я согласен, что любой язык может быть скомпилирован или интерпретирован (скомпилировать bash-скрипт; использовать интерпретированный C ++ (CINT / Cling)), но многие решения в дизайне языка основаны на том, будет ли это интерпретироваться, компилироваться или и то, и другое. Язык, который заставляет вас вручную объявлять / инициализировать статически типизированные переменные, вручную выделять / освобождать память, выполнять арифметику указателей, не забывать проверять границы массивов, будет менее удобным в интерпретаторе (по сравнению с языком, который собирает мусор в памяти, выводит динамический тип, проверяет границы массива). Эта линия на 100% ясна? Нет, но разница существует на практике.
Доктор Джимбоб

15

Есть несколько веских причин для этого.

Сегодняшний язык низкого уровня был вчерашним языком высокого уровня

Да, хотите верьте, хотите нет, но когда-то даже Си считался языком высокого уровня. Даже ~ 20 лет назад это было достаточно распространенным, чтобы увидеть его как язык «среднего уровня». Это было время, когда ОО был столь же популярен, как сегодня, Java не существовало, C # не существовало, даже C ++ еще не был должным образом стандартизирован.

Историческая инерция

Операционные системы, которые вы используете сегодня, имеют глубокие корни в истории. Windows восходит к началу / середине 80-х, Unix - к началу / середине 70-х. В операционных системах много МНОГО старого рабочего кода, и вы обычно не хотите переписывать старый рабочий код.

В какой-то момент вы должны перейти к оборудованию

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

портативность

Я не имею в виду переносимость на другое оборудование или на другую ОС, как это принято понимать сегодня; это более тонкий. Есть одно важное преимущество предоставления интерфейса на основе C для чего-то, и это тот факт, что практически любой другой язык, который существует, может ссылаться на C. Даже Windows API по-прежнему является API на основе C по этой причине.

Личное предпочтение

Некоторые люди просто предпочитают программировать таким образом, и это может быть основным фактором. Например, у Линуса Торвальдса есть известная напыщенная речь против C ++, которая ясно дает понять, что, насколько он обеспокоен, C всегда будет его инструментом выбора для этого вида работы (содержание разглагольствования и согласны ли вы с этим или нет. не имеет отношения к этому обсуждению; факт, что напыщенная речь существует, достаточно).

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


13

Основная причина доминирования C в операционных системах лежит в истории - текущие основные операционные системы, такие как Windows, и все формы Unix (BSD, Solaris, HP-UX, MacOS X, ... а также клоны, такие как Linux) возвращаются долгое время, прежде чем ОО и другие конструкции «высокого уровня» стали мейнстримом.

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

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

Для широко распространенных операционных систем ярким примером, в котором не используется C, также является классический MacOS до MacOS X - который в значительной степени был написан на диалекте Паскаля, который допускал некоторую форму ориентации объекта.


12

Во-первых, есть некоторые проблемы с загрузкой. Большинство функций, облегчающих использование языков высокого уровня, основаны на абстракциях, которые ядро ​​должно предоставлять самостоятельно. Как вы пишете менеджер памяти на языке, который требует менеджера памяти? Как вы пишете драйверы ввода / вывода, не используя симпатичные стандартные библиотеки ввода / вывода на вашем языке? Как вы создаете потоки и примитивы синхронизации без использования языковых библиотек?

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

Другими словами, когда вы учитываете все ограничения и модификации, которые вам придется принять, C и C ++ начинают выглядеть намного проще.


2
Ваш первый абзац не имеет смысла. Драйвер ввода-вывода в C также не использует stdio.h. Пользовательская реализация мьютекса не использует pthreads. Это именно то, что значит реализовать это самостоятельно! И это не зависит от языка, который вы используете. Это не означает, что языки высокого уровня - хороший выбор для задач низкого уровня (они обычно не в моем опыте).

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

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

Неплохо подмечено.
Карл Билефельдт

6

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

Во- вторых, была ОС написана на бесспорно ЯВУ - Lisp Machine . (Тот факт, что он потерпел неудачу в коммерческих целях, был в большей степени связан с тем, что другое оборудование становилось дешевле, и триумф Хуже лучше, чем из-за недостатков его философии или дизайна).

В-третьих, C ++ является достаточно объектно-ориентированным и высокоуровневым, поэтому, как отмечали другие, Symbian OS является еще одним примером.

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


Вы пропустили мейнфреймы Burroughs B5000. Их операционная система была написана на Burroughs Extended ALGOL.
Джон Р. Штром,

1
there is little need for new OSes at this timeЯ до сих пор не решил сам, правда это или нет .. Да, современные ОС (современные windows (NT) / современные Unix) - это все, что нам нужно, функциональность и производительность. Но едва: они родились в другой области, где «сеть» была корпоративной / университетской, и пользователи доверяли, а multiproc - 2/4 процессоров. В некоторой степени они «страдают» от чрезмерного доверия (руткиты, вредоносные программы, вирусы и т. Д.). Я начинаю думать, что есть место для современной, безопасной, изолированной ОС ... с лучшей поддержкой параллелизма (лучше, чем потоки)
Lorenzo Dematté

Lisp - это низкий уровень, CARи CDRэто макрос для ассемблера IBM 704 ! Даже C выделяет встроенную сборку , а не обрабатывает ее как любую другую функцию. Учитывая Lisp CARи CDRработу над x86, ARM и множеством ISA, это впечатляюще портативная сборка. (Примечание стороны к любому я , возможно, перепутал: Да, Lisp является высоким уровнем языка. CARИ CDRявляется ассемблер макросы просто деталь реализации, не ключевой особенностью,.))
8bittree

4

Для лучшего этапа, что я написал ранее.

Машины Burroughs 5xxx - 6xxx не имели языка ассемблера. Самым низким доступным языком было расширение на Алгол. Алгол был реализован аппаратно. ОС и все языки были написаны на Алголе. Он превзошел все машины конкурентов того времени. Это также требовало значительно меньшего количества кода, что значительно облегчало его обслуживание. У него было аппаратное обеспечение стека, которое поддерживало рекурсивный язык, такой как Algol.

Операционная система Burroughs превратилась в версию под названием MCP. В настоящее время MCP работает в системах Unisys.


3

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

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

Теперь вы можете утверждать, что C ++ также является хорошим кандидатом, поскольку предлагает ручное управление памятью. C ++ уже использовался в некоторых операционных системах, таких как Symbian (упомянутый Bart ) и BeOS. Но IMHO C по-прежнему является самым быстрым языком, который можно перенести на многие архитектуры без огромных усилий (в отличие от сборки конкретной архитектуры).

[i]: Современные операционные системы, 3-е издание, стр. 73


3
Машины Symbolics имели автоматическое управление памятью. Smalltalk сделал на Альто. Это было в 80-х годах. Система линейного типа полностью устраняет необходимость в GC. Это решенные проблемы, если бы мы только могли это запомнить!
Фрэнк Шиарар

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

2

Как уже отмечали другие, несколько операционных систем были написаны на языках высокого уровня. Возможно, вы имеете в виду, что все успешные ОС массового рынка были написаны с использованием некоторой комбинации ассемблера, C и C ++?

Большинство языков высокого уровня имеют множество полезных функций, которые связаны с затратами на производительность. Автоматизированное управление памятью - очевидный пример, проверка границ массивов - другой. Если вы пишете ОС общего назначения, вы, скорее всего, столкнетесь с ситуациями, когда снижение производительности этих полезных функций превысит сумму, которую вы готовы заплатить. В этот момент вы хотели бы иметь возможность отключить их. Языки, такие как Python, C # и Java, различаются по функциям, которые вы можете отключить, но ни одна из них не является столь же универсальной, как C или C ++ в этом отношении.

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


0

Реальный ответ - Деньги . Недостаточно очевидной выгоды от языковой ОС высокого уровня, чтобы оправдать затраты ресурсов на ее создание, а затем подтолкнуть ее в мейнстрим. Например, огромные затраты связаны с созданием нового драйвера для каждого компонента оборудования, который он должен поддерживать.

Существуют различные ОС, написанные на языках высокого уровня, с основной целью исследования, такие как Oberon и Singularity .

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.