Чтобы полностью и ядро и драйвера и вся системная часть была на .NET?

Ваш прогноз?
Почему?

а сам фреймворк на чем крутиться будет?
на прерываниях биоса?
:)

Никогда не будет переписана. Виртуальная машина NET тоже сама на себе выполняться будет?

> DVM ©   (15.12.08 22:39) [2]
>
> Никогда не будет переписана. Виртуальная машина NET тоже
> сама на себе выполняться будет?


Нет, но сразу после загрузчика будет стартовать виртуальная машина с Jit-компилятором. Начальных 64-128 Мб для старта ядра ОС это будет вполне нормально.

> но сразу после загрузчика будет стартовать виртуальная машина
> с Jit-компилятором

Но она же будет не под .NET написана. Все на NET перевести не выйдет таким образом.

Есть эксперементальная ос сингулярити она на нет пишется.
Нужно посмотреть на результаты тогда можно прогназировать. Так может за 2 года и перепишут. Но вопрос в том стоит или нет. Я считаю что стоит попробовать а там будет видно. Плюсы от этого есть. Но и минусов много. Нужну лет 5 на структурирование три из которых прошли. Если и будет то нераньше 2010.

> Городской Шаман   (15.12.08 22:44) [3]

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

> [0] Городской Шаман   (15.12.08 22:24)

это еще зачем? .net позиционируется как платформа для прикладных приложений, там ей и место.

> Начальных 64-128 Мб для старта ядра ОС это будет вполне
> нормально.

Не тут  в 2-10 раз больше нужно будет и приложения будут есть в 2 раза больше памяти.

> это еще зачем? .net позиционируется как платформа для прикладных
> приложений, там ей и место.

И где-же она позиционируется?

Никогда, ИМХО.
Драйвера на .NET... такое и в кошмаре не приснится...

Проект Singularity давно остановлен. Ну а так большого смысла в .NET на уровне ядра нет. Драйвера оборудования принципиально не могут быть управляемыми. А так, дже если брать чисто графическую подсистему, если ее реализовать в ООП-ключе, то все выльется в жуткие тормоза даже на современном железе.

> Mystic ©   (15.12.08 23:56) [12]


Зато есть одно интересное преимущество, прощай защищенный режим с кольцами защиты.  GDT, LDT, NX бит и еже с ними.
Сколько могут поднять на одних только переключаниях на шлюзы вызова(call gates).

> oxffff ©   (16.12.08 00:02) [13]


Ну GDT то LDT и PAGE TRANSLATION пусть конечно останутся
(нужно же по 4GB всем выделить :) ), только убрать сразу проверку DPL на CPL. Убрать сразу карту IO c TSS. И т.д. и т.п.

> [13] oxffff ©   (16.12.08 00:02)

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

>  а именно для улучшения производительности


А как защищенный режим оказывает влияния на производительность?

> Eraser ©   (16.12.08 00:12) [15]


Protected mode - он потому, что

CHAPTER 12
PROTECTION
Protection is necessary for reliable multitasking. Protection can be used to prevent tasks from
interfering with each other. For example, protection can keep one task from overwriting the
instructions or data of another task.
During program development, the protection mechanism can give a clearer picture of
program bugs. When a program makes an unexpected reference to the wrong memory space,
the protection mechanism can block the event and report its occurrence.
In end-user systems, the protection mechanism can guard against the possibility of software
failures caused by undetected program bugs. If a program fails, its effects can be confined to
a limited domain. The operating system can be protected against damage, so diagnostic
information can be recorded and automatic recovery attempted.
Protection can be applied to segments and pages. Two bits in a processor register define the
privilege level of the program currently running (called the current privilege level or CPL).
The CPL is checked during address translation for segmentation and paging.

> [16] oxffff ©   (16.12.08 00:15)

самым прямым образом - работе с оборудованием и памятью не мешают второстепенные задачи.

> [17] oxffff ©   (16.12.08 00:21)

это только подтверждает то, что я сказал выше.

> Eraser ©   (16.12.08 00:25) [18]


> Eraser ©   (16.12.08 00:26) [19]


Ну не выкручивайся, :)
по твоим словам, один и тот же код будет работать быстрее в защищенном режиме. Но это не так.
Попробуй обратись в портам ввода вывода разрешенным в IO MAP TSS из RING3 и из реального режима.
+тебе еще пример TLB

The information which either maps linear addresses into physical addresses or raisesexceptions is held in data structures in memory called page tables. As with segmentation, this information is cached within the CPU to minimize the number of bus cycles required for address translation. Unlike segmentation, the address translation caches are completely invisible to application programs. The processor's caches for address translation information
are called translation lookaside buffers (TLB). The TLBs satisfy most requests for reading
the page tables. Extra bus cycles occur only when the TLBs cannot satisfy a request. This
typically happens when a page has not been accessed for a long time.

Еще вопросы?

не .net, но аналог - Active Oberon System
интересующиеся могут посмотреть Bluebottle OS

http://bluebottle.ethz.ch/
http://forum.oberoncore.ru/index.php
http://a2os.org.ua/forums/

CLR будет крутиться на жабе, а жаб-машина будет написана на .Net

> [20] oxffff ©   (16.12.08 00:31)


> по твоим словам, один и тот же код будет работать быстрее
> в защищенном режиме

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

> защищенный режим это способ структурировать выполнение кода.

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

> [24] Petr V. Abramov ©   (16.12.08 01:57)

и это тоже, но не это первопричина.

Что вы все программно мыслите... все будет аппаратно.

> KilkennyCat ©   (16.12.08 03:18) [26]
> Что вы все программно мыслите... все будет аппаратно.

Вот даже сокет 939 устарел шибко-шибко, под него щас и процессор не сыщешь (и сижу с ним, сокетом, как дурак). Так что, к тому времени, как устареет .Нет, сменится еще поколений 16 процессоров...

> Чтобы полностью и ядро и драйвера и вся системная часть
> была на .NET?

Когда компьютеры будут аппаратно исполнять MSIL. Типа как LISP-машины в прошлом веке.

Тест(

Странно, не проходили мессаги...

> Джо ©

У нас продаются S939 - 3000+, 3200+, 3500+  и 3800+ от 699 руб до 2400руб соответственно.

> Eraser ©   (16.12.08 02:20) [25]
> > [24] Petr V. Abramov ©   (16.12.08 01:57)
>
> и это тоже, но не это первопричина.

ругаться лень

> oxffff ©   (16.12.08 00:08) [14]

Если бы все было так просто.. Начнем с того, что JIT-компилятор должен иметь возможность транслировать в нативный код и его запускать. Значит это можно делать средствами .NET. Так что все равно проверки что можно, а что нельзя никуда не денутся. Да и не самое это узкое место :)

никак - иначе сразу отхачят

> Mystic ©   (16.12.08 21:54) [32]


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

Поскольку IL набор инструкций .NET для простых смертных не содержит никаких аппаратных инструкций типа in|out, то технически ничего не мешает их ввести в IL набор, поскольку в большинстве известных мне процессорных архитектур (я не утверждаю, что знаю все) эти инструкции присутствуют. Далее проиходит анализ интроспекции Trusted .NET кода перед JIT компиляцией на предмет возможностью переназначения ресурсов DMA, IRQ, Shared IRQ, IO range и т.д. и т.п. Далее JIT компилер обращается к PnP .NET менеждеру, который уведомляет о наличии таких то и таких, то ресурсов доступных. JIT компилер производит транслирование IN|OUT IL команд в команд процессора In out c "заколоченными" номерами портов которые дал PnP. То есть по факту IL in|out не содержат номера портов в качестве операндов, а получают от  runtime .NET.
   Таким образом эта проверка (доступ к аппаратным ресурсам)производится в моменты компиляции IL кода + в моменты перекомпиляции кода при изменении параметров оборудования например при Shared ресурсе.

Таким образом уже не будет комманд процессора типа SYSENTER и SYSCALL причем у AMD и intel они разные, но смысл их один "даешь быстрый вход в режим ядра". Но все равно накладно. + нет необходимости в других аппаратных проверках. типа RPL, CPL, DPL.
    Тем не менее расмотренный мною случай решения не единственный, например IL набор команд можно не расширять, а для например делать при JIT inline кода для вызовов HardwareResources.AssignIRQ(acquireIORange) - это пседвовызовы. (Например в IL наборе нет lock\unlock (С# lock) вызова для объекта, зато есть библиотечный тип с вынесенной за приделы IL реализации, оно понятно что разницы не будет - что это будет IL в .NET Set или вызов типа в стандартной библиотеке .NET.)
Причем идея в том, что система сама предоставляет ресурс и технически в него можно что то только передать и получить аля BlackBox, но не перенастроить.

Думаю в Microsoft парни тоже не простые, и еще не такое могут предложить.
Такие вот дела. :)

Что меня смущает, так это только коммуникации посредством передачи сообщений/ Здесь возможны "провалы".

Можно операционку на Java написать :)
http://en.wikipedia.org/wiki/Java_processor is the implementation of the Java Virtual Machine (JVM) in hardware. In other words the bytecodes that make up the instruction set of the abstract machine become the instruction set of a concrete machine.

> oxffff ©   (17.12.08 08:42) [34]

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

> IN|OUT IL команд в команд процессора In out c "заколоченными"
> номерами портов которые дал PnP. То есть по факту IL in|out
> не содержат номера портов в качестве операндов, а получают
> от  runtime .NET.
>    Таким образом эта проверка (доступ к аппаратным ресурсам)производится
> в моменты компиляции IL кода + в моменты перекомпиляции
> кода при изменении параметров оборудования например при
> Shared ресурсе.

Bred of Sieve Cobyle
это все аппаратно сделано в 286-м процессоре, на уровне какого-то аппарантного исключения по обращению к порту не из ring0.

> Petr V. Abramov ©   (17.12.08 23:40) [37]


Bred of Sieve Cobyle?
Ты суть разговора держишь?

Мы обсуждаем как возможно сократить количество проверок при работе всего в RING0.

> Mystic ©   (17.12.08 22:41) [36]
> > oxffff ©   (17.12.08 08:42) [34]
>
> IL анонсировался как независимый от платформы язык. Поэтому
> не вижу большой необходимости включать в него инструкции
> обращения к портам. Получается набор из Intel-IL, AMD-IL,
>  и т. д.


Абсолютно не получается. Opcode x86 команд In|Out идентичны.
Ничего не мешает ему таким и оставаться.


>Во-вторых, многие устройства внешние физически
> пишут в память.


И это называется DMA. И что им будет мешать?


>Как тебе идея написать какой-нить щейдер,
>  который пропишет результаты вычисления в стек, а там будем
> JMP на блок данных?


А с какого собственно перепугу там будет JMP?
Да, и шейдер это в видеодаптере. И он совершенно не пишется на IL.

> И это называется DMA.


Это называется отображение регистров устройств на память - схемотехническое решение для процессоров, у которых нет команд IN/OUT

> oxffff ©   (18.12.08 00:36) [39]


Кроме Intel и AMD есть еще ARM-ы и т. д. Мешать ничего не будет. Просто если устройство может писать в память, то, теоретически, оно может писать в пять код. И код может писать поверх существуюещего .NET кода.

> Игорь Шевченко ©   (18.12.08 00:52) [40]
>
> > И это называется DMA.
>
>
> Это называется отображение регистров устройств на память
> - схемотехническое решение для процессоров, у которых нет
> команд IN/OUT


И такое есть (если не ошибаюсь у SUN sparc).
Но речь шла не только об этом, есть еще DMA.
Непосредственно DMA контроллер + Bus Master IDE.

http://ru.wikipedia.org/wiki/DMA
http://www.ixbt.com/mainboard/bmide.html

Но и в том и в другом случае, либо физический адрес статичен и известен,  либо динамичен (задается драйвером).

> Mystic ©   (18.12.08 00:54) [41]
>
> > oxffff ©   (18.12.08 00:36) [39]
>
>
> Кроме Intel и AMD есть еще ARM-ы и т. д. Мешать ничего не
> будет. Просто если устройство может писать в память, то,
>  теоретически, оно может писать в пять код. И код может
> писать поверх существуюещего .NET кода.


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

Только что заметил ветку...

> В каком году Windows будет полностью переписана на .NET
> Чтобы полностью и ядро и драйвера и вся системная часть была на .NET?

Никогда. Потому что ядро, написанное на .Net, не сможет работать без VM, а VM не может работать без ядра.

Слышать подобные вопросы от программиста - более чем странно.

> Юрий Зотов ©   (18.12.08 14:51) [44]


:)

А как же тогда  oxffff ©   (15.12.08 23:51) [11]
очень рекомендую
http://www.rsdn.ru/article/singularity/singularity.xml

> oxffff ©   (18.12.08 14:56) [45]
>
> А как же тогда  oxffff ©   (15.12.08 23:51) [11]


А никак. Просто потому что CPU умеет исполнять только свой нативный код и ничего более. А это значит, что ядро любой ОС может быть выполнено только на этом нативном коде и ни на чем другом. Даже если это ядро будет представлять собой некую VM - все равно оно останется ядром и будет выполнено на нативном коде. И никакие танцы с бубнами тут не помогут.

> Юрий Зотов ©   (18.12.08 15:30) [46]
> на нативном коде. И никакие танцы с бубнами тут не помогут.

Поможет .NET в железе. Где-то я эти  мечты читал вроде.

> Юрий Зотов ©   (18.12.08 15:30) [46]
>
> > oxffff ©   (18.12.08 14:56) [45]
> >
> > А как же тогда  oxffff ©   (15.12.08 23:51) [11]
>
>
> А никак. Просто потому что CPU умеет исполнять только свой
> нативный код и ничего более. А это значит, что ядро любой
> ОС может быть выполнено только на этом нативном коде и ни
> на чем другом. Даже если это ядро будет представлять собой
> некую VM - все равно оно останется ядром и будет выполнено
> на нативном коде. И никакие танцы с бубнами тут не помогут.
>


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

> Юрий Зотов ©   (18.12.08 14:51) [44]


Нуу... возможно появятся процессоры с аппаратной поддержкой IL. Или загружается загрузчик с мини-VM и HAL(то что нельзя использовать без нативного кода) где все остальное вплоть до драйверов устройств написано на .NET. Вполне реально уложить такой загрузчик с микроядром в 1Мб. Все остальное чистый .NET.

Тогда мы имеем микроядро с сервисами, которые еще и работают на управляемом коде.

В принципе MS уже нечто подобное для прикладной обкатки написала, посмотрите здесь: UMDF http://en.wikipedia.org/wiki/User-Mode_Driver_Framework

> Городской Шаман   (18.12.08 15:41) [49]
> Тогда мы имеем микроядро

Я сильно не спец в ОСях, но слышал сказки от MS, что они сделали в 2000 и т.д. типа микроядро. Но скорость оказалась никакущей, потому это "микроядро" "расширили", подпихав туда и драйвера и т.д.
При этом упорно говорят, что архитектура, мол, микроядерная, но правда - и дальше выкручиваются.

> oxffff ©   (18.12.08 15:41) [48]
> Городской Шаман   (18.12.08 15:41) [49]


Ядро, по определению - это та часть ОС, которая может работать само по себе, без какой-либо внешней поддержки. Значит, ядро любой ОС может быть выполнено только на нативном коде CPU.

Назовите это ядро как угодно - VM, загрузчик VM, интерпретатор Васика, медиаплеер, Блокнот и т.д. Но выполнено оно все равно может быть только на нативном коде.

И этим все сказано. Ну не падают яблоки вверх , как ни шамань.

> В каком году Windows будет полностью переписана на .NET

а нахрена, кстати?

> KSergey ©   (18.12.08 16:13) [50]


Minix3 микроядерная архитектура, рвет по производительности и Win и *nix. Но писалась 15 лет.

> Юрий Зотов ©   (18.12.08 16:35) [51]


Но вы не будете отрицать что драйвер FDO нельзя написать на промежуточном языке, так как он не лезет к оборудованию, а только интерпретирует. Кроме того реальный драйвер оборудования тоже можно написать на .NET если HAL будет поддерживать функции IOPort.In(...) IOPort.Out(...).

> clickmaker ©   (18.12.08 16:43) [52]
>
> > В каком году Windows будет полностью переписана на .NET
>
> а нахрена, кстати?


Чтобы индусы могли писать драйвера?

> нахрена, кстати?


Присоединяюсь к вопросу.
Я бы еще добавил, что неплохо бы расслоить загрузку.
Ядро полностью отдельно, GDI тоже. (Или я что-то пропустил)

> Городской Шаман   (18.12.08 16:53) [54]

Хоть драйвер, хоть что угодно еще можно написать в любом ненативном коде. Только без соответствующей поддержки работать этот код не будет - значит, к ядру ОС он по определению никакого отношения не имеет.

> Юрий Зотов ©   (18.12.08 17:01) [57]


Ладно, соглашусь. Про ядро погорячился. А что вы скажете про загрузчик, VM и HAL в нативном коде, а вот драйвера все на управляемом? Будет тормозить, но работать.

> Городской Шаман   (18.12.08 17:39) [58]
> а вот драйвера все на управляемом?
>  Будет тормозить, но работать.


А зачем?
Ты хочешь устойчивость системы провысить за счет ее тормознутости.
Смысл управления на уровне человека, обменом по шине(конкретнее отлавливание ошибок).

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

> Юрий Зотов ©   (18.12.08 16:35) [51]
>
> > oxffff ©   (18.12.08 15:41) [48]
> > Городской Шаман   (18.12.08 15:41) [49]
>
>
> Ядро, по определению - это та часть ОС, которая может работать
> само по себе, без какой-либо внешней поддержки. Значит,
> ядро любой ОС может быть выполнено только на нативном коде
> CPU.
>
> Назовите это ядро как угодно - VM, загрузчик VM, интерпретатор
> Васика, медиаплеер, Блокнот и т.д. Но выполнено оно все
> равно может быть только на нативном коде.
>
> И этим все сказано. Ну не падают яблоки вверх , как ни шамань.
>


И как это противоречит возможности ядру быть написаным на .NET языке?

Минизагрузкик переходит в защищенный режим, поднимает виртуальную .NET машину и загружает некий образ .NET - образ самого ядра ОС возможно откомпилированный NGEN(по нему уже JIT не нужен).
Естественно в эту часть ядра входит часть unmanaged кода HAL платформы написанная на С++ c ASM вставками.

И тут я Вас перенаправляю к вышеупомянутой мною статье

5.1 Система ввода/вывода
Система ввода/вывода Singularity состоит из трех слоев: HAL, менеджера ввода/вывода и драйверов. HAL – это маленькая доверенная абстракция аппаратного обеспечения РС: абстракции IoPorts, IoDma, IoIrq и IoMemory для доступа к устройствам; интерфейсы к таймерам, контроллер прерываний, часы реального времени и отладочная консоль; заглушка для отладки ядра; регистратор событий, векторы прерываний и исключений; обнаружение ресурсов BIOS и код связывания стека. HAL написан на C#, C++ и ассемблере. Доля ассемблера и C++ в HAL составляет примерно 5% от доверенного кода системы (35 из 561 файла).

Из этого следует, что действительно для ядро ОС написано на .NET и HAL на С++ , а загручик действительно написан не на .NET. Но его задача только загрузить и больше он не нужен.

Вопрос 1.

Признаете ли вы что это возможно, если нет, то почему?

Вопрос 2.

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

Вроде, уже java-vm встраивали в процессоры, и где они теперь. Теперь, подрасло следующее поколение, повисла идея встроить в процессор .net :-)
Прикол этого вопроса только в том, что дальше вопроса у аФФтара дело не пойдёт...

>  и где они теперь.


Вот сегодняшняя новость от SUN

http://www.theinquirer.net/inquirer/news/097/1050097/amd-works-shanghai-java-for-oriental-opteron

CHIMPZILLA is working with Java systems developers to optimise the performance of Java Virtual Machines on its new Shanghai lines of processors.

AMD's Shanghai series fabbed on 45nm technology feature larger caches, a new version of Hyper Transport technology and lower power consumption. Shanghai chips also implement AMD's Instruction Based Sampling (IBS) performance monitoring.

AMD is collaborating with JVM designers at Sun, IBM and Oracle to develop ways to use IBS data to improve JVM performance, according to Ben Pollan, AMD Java Labs manager.

> oxffff ©   (19.12.08 00:02) [60]
> > Юрий Зотов ©   (18.12.08 16:35) [51]

я согласен с > oxffff ©   (19.12.08 00:02) [60], с какого-то момента драйверы стали все написаны не на ассмеблере, были вопли "что теперь будет, что теперь будет", да ничего не стало, как падали машиы из-за кривых драйверов, так и падают.
А цена девайсов снизилась, в т.ч. из-за снижения себестоимости разработки драйверов.