T>>Виртуальная память влияет на производительность, накладные расходы в железе для неё минимальны (для реализации SPARC v8 под названием Leon3 и для известных мне вариантов MIPS — примерно размер регистрового файла, который сам ~10% от площади ядра микропроцессора). Для x86 успешное обновление TLB при промахе занимает ~400 тактов, для MIPS — ~40. WH>Экономия ~10% от площади ядра микропроцессора и 0 тактов вместо от 40 до 400. WH>Так и запишем.
Ты говоришь о полном и безоговорочном доказательстве всего на свете.
В этом случае, конечно, нативный код отомрёт.
WH>>>Да и сам процессор можно сделать без лишних заморочек типа слоя совместимости с x86. T>>А это-то здесь при чём? WH>Ну при том что сейчас очень много процессоров с этой нашлепкой. WH>Я уверен почти на 100% что ты сейчас сидишь за компом в котором стоит именно такой процессор.
Дома у меня есть PowerPC. Так что вероятность всего 2/3 (работа, дом и дом).
WH>Управляемые системы позволят от этой нашлепки избавиться. WH>Ибо в случае с управляемой ОС нужно будет просто описать модель нового процессора. WH>И весь софт стразу на нем заработает. WH>С нативными ОС такой фокус не пройдет.
Да, соглашусь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Chrome, Вы писали:
C>Верифицируемый код не позволяет портить чужие данные. Что еще нужно?
Моему извращенному уму нативный код писать проще и приятнее. А верифицируемость накладывает кучу ограничений, которые надо потом думать, как разрулить.
Здравствуйте, Chrome, Вы писали:
C>Или его со временем полностью вытеснит верифицируемый промежуточный код?
а хто будет исполнять этот промежуточный код? еще одна виртуальная машина? а за ней еще одна? вещь в себе какакя-то =)
пока железо не будет позволять таких финтов, никуда нативники не денуться
хотяяя... он и тогда никуда не денется, просто он будет нативным не для x86 а для SkyNet или T-800 на худой конец ))
C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
х\з... а какие тут накладные расходы, и на столько ли они существенны, что пенальти превышает бенефиты такого подхода?
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
да куда она денется?... изолировать их все равно надо, а какими механизмами — вопрос отдельный.
Здравствуйте, thesz, Вы писали:
T>Ты говоришь о полном и безоговорочном доказательстве всего на свете.
А все на свете и не нужно.
Достаточно доказать что не будет проездов по памяти и гонок.
А для этого даже зависимые типы приплетать не нужно.
Если приплести зависимые типы то можно на корню убить юнит тесты. Ибо зависимые типы позволяют доказать куда больше чем юнит тесты могут протестировать.
Единственное с чем будут проблемы это с тем как доказать что модель процессора которую использует бекенд соответствует реальному процессору.
К счастью это довольно не большое количество полностью декларативного кода.
Ну и конечно нужно IOMMU с защитой иначе через DMA периферия сможет наломать дров.
T>Дома у меня есть PowerPC. Так что вероятность всего 2/3 (работа, дом и дом).
Ладно. Про маки я забыл.
Но сколько этих маков? Процентов 10? Или меньше?
В любом случае возможность менять систему команд процессора ИМХО дорогого стоит.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>>ИМХО это опциональная возможность причем далеко не факт что вообще полезная. T>Вот и ответ на "полное вытеснение нативного кода". Там, где это полезно, то лучше использовать нативный код.
А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?
Здравствуйте, Mystic, Вы писали:
M>Моему извращенному уму нативный код писать проще и приятнее.
А мне нет ибо нативность отбирает кучу умственных ресурсов на вопросы не связанные непосредственно с задачей.
M>А верифицируемость накладывает кучу ограничений, которые надо потом думать, как разрулить.
Какие конкретно ограничения?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Chrome, Вы писали:
C>>а где гарантии, что код, исполняемый в режиме ядра не содержит ошибок?
PD>Нет такой гарантии. Более того, эти ошибки в драйверах имеют место сплошь и рядом, да и в собственно ядре тоже есть. Но вот попытка приложения 3 кольца модифицировать область данных ядра или другого процесса блокируется аппаратно.
А еще лучше когда эта попытка не допускается верификатором (который может быть запущен один раз), и работает все без аппаратных проверок.
кроме того, может вообще не быть API которое позволяет лезть в чужой процесс. (хотя как там debug сделать — не знаю).
Здравствуйте, ili, Вы писали:
ili>а хто будет исполнять этот промежуточный код? еще одна виртуальная машина? а за ней еще одна? вещь в себе какакя-то =)
Процессор.
Блин уже хрен знает сколько лет промежуточный код компилируют непосредственно в коды конкретного процессора, а все находятся орлы которые этого не знают.
ili>пока железо не будет позволять таких финтов, никуда нативники не денуться
Железо только упростится.
Например нашлепка x86'ой совместимости пропадет.
ili>х\з... а какие тут накладные расходы, и на столько ли они существенны, что пенальти превышает бенефиты такого подхода?
А у аппаратной защиты есть преимущества по сравнению с программной?
Огласите весь список пожалуйста.
ili>да куда она денется?... изолировать их все равно надо, а какими механизмами — вопрос отдельный.
Программными.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>То есть ты хочешь сказать, что вирусы в состоянии нарушить аппаратную защиту защищенного режима, и , работая в 3 кольце, получить доступ к страницам, для которых U/S == 0 ? Расскажи , как это делают вирусы, мне это очень интересно
Да мне плевать как. Главное что вирусы пролезают в ядро не смотря на аппаратную защиту.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>>>ИМХО это опциональная возможность причем далеко не факт что вообще полезная. T>>Вот и ответ на "полное вытеснение нативного кода". Там, где это полезно, то лучше использовать нативный код. G>А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?
На 99%.
Один процент на то, что потребуется ассемблер. А он потребуется.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, ili, Вы писали:
ili>>а хто будет исполнять этот промежуточный код? еще одна виртуальная машина? а за ней еще одна? вещь в себе какакя-то =) WH>Процессор. WH>Блин уже хрен знает сколько лет промежуточный код компилируют непосредственно в коды конкретного процессора, а все находятся орлы которые этого не знают.
эмн... тут вы мои слова неверно поняли, или я не яно выразился ))) фактически это я и имел ввиду — в результате все равно получается нативник.
ili>>пока железо не будет позволять таких финтов, никуда нативники не денуться WH>Железо только упростится. WH>Например нашлепка x86'ой совместимости пропадет.
да прекрасно, что я против что ли? я же сказал, что в итоге, нативник останется, только он уже может не быть нативником х86.
ili>>х\з... а какие тут накладные расходы, и на столько ли они существенны, что пенальти превышает бенефиты такого подхода? WH>А у аппаратной защиты есть преимущества по сравнению с программной? WH>Огласите весь список пожалуйста.
ili>>да куда она денется?... изолировать их все равно надо, а какими механизмами — вопрос отдельный. WH>Программными.
по этим двум моментам, я не говорю о различиях реализации программной и аппаратной. я говорю о том, что как таковые они остануться, а как они будут сделаны (программно\аппаратно\при помощи маленького демона с мальбертом и красками в коробочке\etc.) — вопрос вообще отдельный.
колесо тоже когда-то деревянным было, сейчас железные с резиновой обкладкой предпочитают вот только колесо от этого колесом быть не прекратило.
Здравствуйте, ili, Вы писали:
ili>эмн... тут вы мои слова неверно поняли, или я не яно выразился ))) фактически это я и имел ввиду — в результате все равно получается нативник.
Очень важная поправка: Верифицированный нативник.
ili>по этим двум моментам, я не говорю о различиях реализации программной и аппаратной. я говорю о том, что как таковые они остануться, а как они будут сделаны (программно\аппаратно\при помощи маленького демона с мальбертом и красками в коробочке\etc.) — вопрос вообще отдельный.
Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
ИМХО тут весьма неоднозначно подразумевается именно аппаратная защита.
ili>колесо тоже когда-то деревянным было, сейчас железные с резиновой обкладкой предпочитают вот только колесо от этого колесом быть не прекратило.
С доказательствами по аналогии иди в другое место.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Mystic, Вы писали:
M>>Моему извращенному уму нативный код писать проще и приятнее. WH>А мне нет ибо нативность отбирает кучу умственных ресурсов на вопросы не связанные непосредственно с задачей.
M>>А верифицируемость накладывает кучу ограничений, которые надо потом думать, как разрулить. WH>Какие конкретно ограничения?
Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами. У меня есть память, я к ней обращаюсь как хочу. Захочу, прочитаю из нее указатель, захочу прочитаю из нее целое значение. Записи с вариантами и т. п. Попытка начать писать тот же шахматный движок под .NET быстро натолкнулась на то, что без постоянного использования unsafe крайне проблематично выделить под хэш фрагмент памяти, разбить его на блоки одинакового размера, представить его в виде списка свободных блоков. Вместо того, чтобы за пять секунд написать то, что я хочу, я вынужден тратить уйму времени на вопросы не связанные непосредственно с задачей.
Например, я хочу хранить некоторые данные как последовательность заканчивается нулевым символом. Так мне удобнее всего в данном случае. Но, соотвественно, код, который берет по одному символу пока не наткнется на нулевой, уже не будет безопасным. И т. п. Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Последний раз ИМХО исправляли одну из первых версий 386, в которой был какой-то баг в чем-то, связанном с плавающей точкой. С тех пор я не помню об ошибках в процессорах, требовавших их замены.
Если отбросить последние два слова, то багов без фиксов хватает. Хотя бы даже если смотреть по документику. Какие из них можно (и можно ли) использовать для прорыва в 0-вое кольцо — я не знаю, может и никакие.
Здравствуйте, thesz, Вы писали:
WH>>>>ИМХО это опциональная возможность причем далеко не факт что вообще полезная. T>>>Вот и ответ на "полное вытеснение нативного кода". Там, где это полезно, то лучше использовать нативный код. G>>А подход с компиляцией при установке, как драйверы в Singularity, такие проблемы не решает?
T>На 99%.
T>Один процент на то, что потребуется ассемблер. А он потребуется.
Ну создателям singularity пока не потребовался. Есть вероятность что и в дальнейшем не потребуется.
Здравствуйте, Mystic, Вы писали:
M>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами. У меня есть память, я к ней обращаюсь как хочу. Захочу, прочитаю из нее указатель, захочу прочитаю из нее целое значение.
Зачем читать целое как указатель или указатель как целое?
M>Записи с вариантами и т. п.
Ты про алгебраические типы? http://en.wikipedia.org/wiki/Algebraic_data_type
M>Попытка начать писать тот же шахматный движок под .NET быстро натолкнулась на то, что без постоянного использования unsafe крайне проблематично выделить под хэш фрагмент памяти, разбить его на блоки одинакового размера, представить его в виде списка свободных блоков. Вместо того, чтобы за пять секунд написать то, что я хочу, я вынужден тратить уйму времени на вопросы не связанные непосредственно с задачей.
Зачем весь это ужос?
Чем System.Collection.Generic.Dictionary<Key, Value> не подошол?
M>Например, я хочу хранить некоторые данные как последовательность заканчивается нулевым символом.
Зачем?
M>Так мне удобнее всего в данном случае. Но, соотвественно, код, который берет по одному символу пока не наткнется на нулевой, уже не будет безопасным.
Зачем нужен такой код?
Чем не устраивает fold?
M>И т. п. Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.
А чем не подходит x & ~(x — 1)?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mystic, Вы писали:
M>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами.
Очень зря.
M>У меня есть память, я к ней обращаюсь как хочу. Захочу, прочитаю из нее указатель, захочу прочитаю из нее целое значение. Записи с вариантами и т. п.
Вдвойне зря.
M>Попытка начать писать тот же шахматный движок под .NET быстро натолкнулась на то, что без постоянного использования unsafe крайне проблематично выделить под хэш фрагмент памяти, разбить его на блоки одинакового размера, представить его в виде списка свободных блоков. Вместо того, чтобы за пять секунд написать то, что я хочу, я вынужден тратить уйму времени на вопросы не связанные непосредственно с задачей.
Просто ты пытаешься программировать на уровне абстракции ниже, чем предоставляет .NET, от этого и проблемы.
M>Например, я хочу хранить некоторые данные как последовательность заканчивается нулевым символом. Так мне удобнее всего в данном случае. Но, соотвественно, код, который берет по одному символу пока не наткнется на нулевой, уже не будет безопасным. И т. п.
Опять проблема неверного уровня абстракции.
Тебе ведь на самом деле не важно каким образом представлен конец последовательности в алгоритме, главное то что он вообще есть.
M>Да и просто получить первый (последний) бит, установленный в единицу, оптимальным способом, уже ассемблерная вставка.
Оптимальность ассемблерного кода очень сильно зависит от процессора. А формула a&0x1 или a&0x80 может компилироваться хоть в AND, хоть BT, хоть еще во что-то, что является оптимальным по мнению компилятора (а он гораздо лучше знает).
Кроме того если копилятор в нативный код (JIT) выбирает оптимизации в зависимости от текущего процессора, то более высокоуровневый код в среднем будет более оптимальным, чем написанный на ассемблере.
Здравствуйте, Mystic, Вы писали: M>Я мыслю алгоритмы большей частью как манипуляцию с байтами и битами.
Ну будет у тебя верифицированная работа с битовым массивом (матрицей, кубом?). Делов-то.
вот только колесо от этого колесом быть не прекратило.
