Фантазии о Lisp OS

[love5an]

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

Понятное дело, что все то говно, которое мы имеем сейчас, от 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.

Comments

[maxim.livejournal.com]

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

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

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

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

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

[love5an.livejournal.com]

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

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

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

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

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

[ircicq.livejournal.com]

>Когда у нас весь код управляемый и с GC, то разные адресные пространства нафиг не нужны(ну два допустим только нужны, ядро и не ядро).

Тогда и разделение на ядро/не ядро и не нужно. это дорогая операция - переключать режим.

Другое дело, что мало пользы от OS, которая не позволит вызывать код писаный на другом (не Managed) языке.

[kmmbvnr.livejournal.com]

>> Мало пользы от OS, которая не позволит вызывать код писаный на другом (не Managed) языке.
А какже iOS? Просто новая нужна ниша. Еще одна OS позволяющая делать тоже самое что и существующие - никому не нужна :)

[ircicq.livejournal.com]

iOS позволяет Native-приложения.

[kmmbvnr.livejournal.com]

А чем принципиально что ObjectiveC не-managed язык? Api сильно ограниченны, другие языки административно запрещены.

[ircicq.livejournal.com]

Obj-C Managed, но орхитектура iOS не запрещает native код в принципе.

Речь шла об OS в которой весь код Managed, только тогда отпадет надобность в изоляции процессов и Kernel/user mode

[kmmbvnr.livejournal.com]

Мне непонятны преимущества когда "native код только в принципе", когда особо все равно не разгуляешься.

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

[ircicq.livejournal.com]

iOS базируется на Darwin/BSD. Правильнее говорить про них в данном контексте.

Другой пример Android: там тоже Java-подобная VM для 99% софта, но в принципе можно и native вызывать.

Это регулируется политикой. Apple по каким-то причинам решила сильнее ограничить.

[kmmbvnr.livejournal.com]

>> iOS базируется на Darwin/BSD
Для userspace софта вообще нет разницы какая там неонка внуртях. Многозадачности традиционной в iphone как не было так и не будет никогда.

Не вижу принципиальной разницы между административными ограничениями и софтварными. Ограничения есть - но это не мешает iOS быть успешной.

Вобщем имхо native код никому не уперся. Главная "новая" ниша, не занятая проблемами бинарной совместимости со старым по.

Новая в кавычках, т.к. по может на самом деле так эволюционировать, что старые наработки становятся особо не нужными. Так linux победила на рынке серверов.

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

А native или не native - уже не принципиально.

[ircicq.livejournal.com]

Ограничения есть - но это не мешает iOS быть успешной.
Успешны iPhone и iPad, а не iOS. Отдельно iOS не продается.


, что старые наработки становятся особо не нужными. Так linux победила на рынке серверов

Linux победила, потому что использовала наработки в UNIX и сохраняла совместимость с UNIX-софтом.