> 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.