love5an | Фантазии о Lisp OS

А вот какой должна быть архитектура ОС ближайшего будущего?

Понятное дело, что все то говно, которое мы имеем сейчас, от AIX до Windows линейки NT - безнадежно устарело.

Я так думаю, что во-первых, естественно, новый тип ОС должен полностью исключать машинный код и прямое управление памятью. То есть, никакого Си, никакого C++, никакого ассемблера, никаких процессов(только треды), никакого разделения адресных пространств, и так далее. В ядре должен работать копирующий сборщик мусора, желательно(наверное даже обязательно) параллельный и желательно инкрементальный, а взаимодействие между частями кода должно быть полностью объектным. Весь код для такой системы должен компилироваться в некоторый промежуточный байт-код, который должен верифицироваться загрузчиком программ(перед трансляцией в машкоды), или некоторым AOT-компилятором(который бы помещал установленные программы в некоторое подобие дотнетовского GAC). Некоторую особо небезопасную часть такого промежуточного байткода позволялось бы использовать только в ядре.

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

.NET достаточно близко подобрался к тому, чтобы на нем можно было бы делать такую систему. Он практически никак не зависит от платформы, плюс вот вышеупомянутый GAC и так далее. Но, в идеале, как мне кажется, у ОС ближайшего будущего должен быть лисповый рантайм.

Хотя, у современных лиспов есть проблема с безопасностью, и они слишком сильно завязаны на свои сишные рантаймы.
Вот например:

(defun %address-of (vec)
  (declare (type (simple-array (unsigned-byte 32) (1)) vec)
           (optimize (speed 3) (safety 0)))
  (sb-sys:int-sap (logand #xFFFFFFF8 (aref vec 0))))

(defun address-of (object)
  (%address-of (vector object)))

(defparameter *vector* (make-array 4 :element-type '(unsigned-byte 32)
                                   :initial-contents '(1 2 3 4)))

(let ((pointer (address-of *vector*)))
  (dotimes (i 4)
    (format t "~a " (sb-sys:sap-ref-32 pointer (+ 8 (* i 4))))))
;; => 1 2 3 4

Нужен какой-то новый диалект лиспа, я бы даже сказал диалект CL, который был бы безопасным и компилировался во что-то типа SBCL'ного IR2, то есть в некий такой VOPCode.

Flat | Top-Level Comments Only

From:

maxim.livejournal.com

Так так :) Я хотел бы получить ответы на такие вопросы:

1. как будем бутстрепить транлированный код ? Допустим у нас есть хороший кросс-платформенный компилятор. Нам же все равно нужно будет организовать загрузку нашего образа, а существующие компиляторы делают PE/COFF/ELF, а это таблица релокаций, и линейное адресное пространство.

2. как будем писать оптимизацию переключателя потоков? APIC IPI? Тут дело не в лиспе, а том, что обычно все слишком умные, а как написать это на ассемблере правильно незнают, зато знают шаблоны, мультидиспач, и паб/саб :) Обработка прерываний, стек сообщений. Имеем ввиду что если мы хотим что бы это работало на мобильнике, то оно должно быть так написано, что бы не жрало много энергии. Потому что например на Андроиде Линукс, который сжирает все.

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

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

From:

love5an.livejournal.com

1. Понятное дело, что надо писать свой компилятор, так как существующие не подходят. Сложно, но можно; особенно если заимствовать код из открытых :)

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

3. Да не, я не говорю, что виртуальную память и пэйджинг вообще надо выкинуть. Надо выкинуть процессы(то есть разделение юзерспейсов). Когда у нас весь код управляемый и с GC, то разные адресные пространства нафиг не нужны(ну два допустим только нужны, ядро и не ядро).

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

Кремнивые решения сейчас легаси на 90% - начиная с a20, и заканчивая тем же разделением адресных пространств(потому что ведь Си, а в Си у нас плоская нетипизированная неуправляемая память, одна для всей для программы)

Фантазии о Lisp OS

Page Summary

Style Credit

Expand Cut Tags