Представлен общий подход[0], позволяющий на основе высокоуровневых средств создать безопасную по памяти программную среду, защищённую от нарушений изнутри её собственными средствами. Основу предложения составляет ограничение псевдомодулей для работы с переменными с возможными нарушениями типизации, сохраняющее общую целостность. Даже обычный интерфейс SYSTEM позволяет применять схожий подход, что уже было проделано[1], но в силу несоответствия воплощения исходной простой задумке, это приводит к ограниченности применения и бо́льшим накладным расходам.
[0] github/vostok-space/безопасно-по-памяти.md
[1] проверяемые адреса при работе с SYSTEM
Здравствуйте, Константин.
ОтветитьУдалитьМожно ли будет на таком языке создавать классические операционные системы типа Линукса или Миникса с разделением адресных пространств? А то как я понял на Виртовских Оберонах это вроде не возможно.
0. Самый обычный Oberon никак не мешает созданию ОС с разделением адресных пространств, которые являются надъязыковым средством машины. Его бо́льшая безопасность в этой среде является избыточной, но это точно не недостаток
Удалить1. Предложенный подход также не мешает разработке обычных ОС, но задуман как раз для другого
2. Это ограничение, позволяющее создать безопасную среду без обязательного разделения адресных пространств и позволяющее создавать более гибкие и безопасные ОС, чем привычные низкоуровневые системы, опирающиеся только на машинные гарантии
0. У Оберонов же сборщик мусора. Я не понимаю как он может не мешать? Или вы имеете в виду, что возможно написание классической ОСи через трансляцию Оберона в Си?
Удалить0. Опишите, как именно мешает сборщик мусора такой ОС
Удалить1. Возможность трансляции в C, так же как возможность трансляции в машинный код никак не связана с наличием или отсутствием сборки мусора в программе на исходном языке
2. В определении самого языка Oberon про сборщик мусора ничего не сказано
Я не программист, но разве вызовы функций ядра, написанного на языке со сборкой мусора, из языка не поддерживающего сборку мусора не будут вызывать проблем? Просто я читал, что в языке D стандартную библиотеку языка переводили со сборки мусора на ручное управление памятью, чтобы, как я понял, можно было использовать стандартную библиотеку при кастомном отключении сборки мусора в некоторых участках кода программы на D.
УдалитьНет разницы, программист или нет. Раз пришли к такому выводу, значит можете описать, как к нему пришли.
УдалитьПросто на примере рантайма Java, который написан на Си, а не на самой Java плюс то, что в D стандартную библиотеку перевели на ручное управление памятью. Это и дало повод для меня считать, что сборка мусора может как-то мешать.
УдалитьЭтих примеров, мягко говоря, недостаточно, чтобы делать такие выводы, особенно учитывая то, что пример D свидетельствует об обратном. Пример Java тоже ни о чём, особенно в таком обобщённом виде. Почитайте, например, о GraalVM от Oracle.
Удалить