Re[6]: ОС на .Net
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.01.06 18:51
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Сдается мне, что GC — это такой черный ящик для нас, с очень миниатюрным АПИ. Другими словами, абсолютно фиолетово, какой именно GC будет реализовывать это АПИ.


Фиг там. На ЖЦ слишком многое опирается. И сам ЖЦ опирается на джит и среду исполения. Так что это очень важная и сильно интегрированная часть системы. Сменить простой ЖЦ на сложны — это значит переделать всю.

V>И вообще, ты всерьез считаешь, что для начала моделирования нужен самый лучший GC? (вопрос в силе и для всего остального).


Я считаю, что для начала вообще можно обойтись эмуляцией внутри процесса (Mono/CLR).

V>И еще, Boehm — очень неплохой GC,


Как минимум он требует наличия виртуальной пмяти. И думаю, что по скорости он будет просто никакой по сравнению с ЖЦ интегрированными с компилятором. Плюс проблема фрагментации. В общем, не ясно зачем связываться с хрен знает чем когда и в Моно и Роторе уже есть готовые ЖЦ. ВОт только они опять же онменеджед (на С/С++).

V> и небольшой по размерам исходник. Будет желание — можно будет попытаться перевести на unsafe C#.


Для этого сначала нужно создать аналог Бартока.

VD>>Что значит сейчас? Это нужно в принципе. Без этого будет не ОС, а МС ДОС.


V>Не все так просто с шедуллингом. Например в виндах шедуллинг напрямую корректируется состоянием окошек процесса, что позволило в свое время реализовать адекватный ГУЙ даже на машинах прошлых лет.


Вообще-то это не так. Единственное что есть — это отем времени при вызове некоторых системных функций (Sleep, GetMessage и т.п.). А "окошки" живут на банальной кооперативной многозадачности. В общем, к проблеме ОС это не имеет никакого отношения.

V>Опять же, шедуллинг — это тоже весьма миниатюрное АПИ.


АПИ — может быть. А вот объем кода это наипервейший. Если и он будет анменеджед и из другой ОС скомунизжен, то я уже не знаю что в этой ОС будет управляемым.

V>В общем, акценты не на том стоят. Надо прорабатывать общие архитектурные решения и протоколы взаимодействия частей ОС.


А что прорабатывать то? Процессы, птоки, компилятор, ХАЛ ты вроде уже отбросил. А что остается то?

V>В первом роторе я не увидел исходников джита. Этот момент — самый краеугольный.


Значит хреново смотерл. Ключевое слово fjit. Там есть С++-ные и ассемблерные части. Плюс куча всего генерируется при инсталляции с помощью скритов и макросов.

Джит в Роторе приметивнейший, но насколько я знаю есть исслеования замещающие его более мощьными.

V>Вопрос был — есть исходники ngen или нет.


Вроде есть. Но это не важно. Для затравки хватит и дижита. А чтобы получить аналог Бартока повкалывать придется нехило. Тут уж лучше все же Феникосом воспользоваться.

V>Если ты так настаиваешь на Bartok, давай порассуждаем.


Я вообще не верю, что этот трёд во что-то выльется. Но если и выльется, то без аналока Бартока никуда.

V>Предназначение Bartok — разработка VM (джит) на самом C#


Барток — это компилятор из МСИЛ в нэйтив код. Почти нген, но позволяющий обходиться без CLR.

V>Далее. Я плохо представляю себе разработку на C# без mscorlib. Понимаешь, куда я клоню? Как он запихнет в бинарный образ только то, что мне надо?


А зачем "без"? Это проскомпилятор. К тому же он по определению сам себя обязан уметь компилировать. Причем росплатформно. Чтобы из под Виндовс-версии можно было скопилировать любую другую. Ну, и на оборот соответсвенно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.