Здравствуйте, Pzz, Вы писали:

Pzz>Я тогда не очень понимаю. Если я могу использовать массивы и могу вычислять индекс в массиве, каким образом статически можно доказать, что я не выскочу за пределы массива?
Доказываешь, что индекс не может превысить границы. Это воможно не всегда, но в достаточно многих случаях.

Здравствуйте, Cyberax, Вы писали:

Pzz>>Я тогда не очень понимаю. Если я могу использовать массивы и могу вычислять индекс в массиве, каким образом статически можно доказать, что я не выскочу за пределы массива?
C>Доказываешь, что индекс не может превысить границы. Это воможно не всегда, но в достаточно многих случаях.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Ну т.е., криптографика какая-нибудь, которая сочетает замысловатые вычисления с активным использованием полувычисленного в качестве индекса в таблице, будет работать медленно, т.к. все время придется "вручную" проверять выход за границу таблицы. И то же самое относится к обработке изображения и звука.
Да, примерно так.

Здравствуйте, Cyberax, Вы писали:

Pzz>>Ну т.е., криптографика какая-нибудь, которая сочетает замысловатые вычисления с активным использованием полувычисленного в качестве индекса в таблице, будет работать медленно, т.к. все время придется "вручную" проверять выход за границу таблицы. И то же самое относится к обработке изображения и звука.
C>Да, примерно так.

Ну т.е., очередная игрушка "теоретиков" с целью опробовать некоторые идеи?

Здравствуйте, Pzz, Вы писали:

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

Исследования сейчас идут по поводу как ещё можно верифицируемость увеличить с помощью явных способов.

Здравствуйте, Cyberax, Вы писали:

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

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

А так, я вообще с симпатией отношусь ко всяким там теоретическим игрушкам. Plan9, Inferno, Singularity. Haskell опять же. Уважаю, да. Я не какой-нибудь там мракобес . Мелкософт уважаю немного меньше, потому что я не слышал до сих пор, чтобы что-нибудь заметное в computer science из них вывалилось.

C>Исследования сейчас идут по поводу как ещё можно верифицируемость увеличить с помощью явных способов.

Я может чего не понимаю, но по-моему верификатор должен быть частью компилятора, а не интерпретатора . И говорить свои слова он должен программисту в лицо, а не пользователю, который вообще не при чем.

Здравствуйте, Pzz, Вы писали:

Pzz>Я может чего не понимаю, но по-моему верификатор должен быть частью компилятора, а не интерпретатора . И говорить свои слова он должен программисту в лицо, а не пользователю, который вообще не при чем.

В компиляторе он тоже есть, на более высоком уровне. Если ты попробуешь вызвать на объекте метод, которого у него нет, тебе компилятор об этом сразу скажет и программа не скомпилируется. А вот если ты руками байт-код сфабрикуешь, и попробуешь его скормить такой машине с верификатором, то именно верификатор не позволит тебе этот код выполнить. В Java такая верификация уже цать лет, как работает. В частности, позволяя исполнять, и даже JIT-ить в нативный код апплеты и при этом быть уверенным, что они не сделают ничего лишнего.

Здравствуйте, Pzz, Вы писали:
Pzz>Я тогда не очень понимаю. Если я могу использовать массивы и могу вычислять индекс в массиве, каким образом статически можно доказать, что я не выскочу за пределы массива?
Это не имеет отношения к теме. Аппаратная защита контролем границ массивов не занимается. И вряд ли когда-нибудь будет — слишком дорого.

Здравствуйте, Pzz, Вы писали:

WF>>Не вижу проблем. Я вон даже пример приводил, где виртуальная функция была заинлайнена. LLVM, насколько я понимаю, именно над своим "биткодом" оптимизации делает.

Pzz>Вы не видите проблем как специалист по компиляторам, или как дилетант, не осознающий ограниченности своих знаних?

Я читаю то, что написано на сайте того же LLVM. И смотрю, что он умеет.

Pzz>Я не вижу проблем сделать инлайнинг на уровне ассемблера или байт-кода — вставил нужный код в нужное место, прошелся peephole'м и все дела.

Это плохой инлайнинг. Он не позволит тебе соптимизировать функцию, как одно целое. Например, соптимизировать регистры. Вынести инвариант из цикла.

Pzz>Можно даже peephole'м не проходиться, если не знаешь, что это такое

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

Pzz>Но как, видя байткод, а не синтаксическое дерево, сделать data flow analysis или вынос инварианта из цикла, я ума не приложу.

Вы видите проблему как специалист по компиляторам, или как дилетант, не осознающий ограниченности своих знаних?

Между прочим, тот же gcc оптимизации делает совсем не на синтаксическом дереве. А на внтуреннем представлении кода, в частности, на коде, представленном в [http://en.wikipedia.org/wiki/Static_single_assignment_form]SSA[/url] форме. А у LLVM, сюрприз, как раз "биткод" с расчетом на SSA сделан.

Здравствуйте, Pzz, Вы писали:
Pzz>За счет чего сингулярити дает 100% гарантию? Какие при этом налагаются ограничения?
Предлагаю пойти и прочитать одну обзорную статью про Singulrity, чтобы не задавать в тридцатый раз дурацкие вопросы.

Pzz>Сискол на линухе, который почти ничего не делает (gettimeofday(), например), занимает 1 микросекунду на довольно средненькой машине. Глядя на то, как в линухе реализована обработка сисколов, становится понятно, что его можно разогнать раз в 10, просто аккуратно перекодировав соответствующие места, без необходимости менять архитектуру. У них там в пути несколько сотен строк довольно развесистого сишного кода.
Я уже приводил тут ссылку на статью, где сравнивались характеристики систем по отношению к межпроцессному обмену информацией. Софтная изоляция рулит неподетски.
Pzz>Это я к тому, что мешает использование именно аппаратной защиты. Плохому танцору известно, что мешает.
Ага. Плохому программисту обычно мешает неумение и нежелание читать.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Cyberax, Вы писали:

Pzz>>>Но как, видя байткод, а не синтаксическое дерево, сделать data flow analysis или вынос инварианта из цикла, я ума не приложу.
C>>А какие проблемы? Строим дерево и делаем анализ. Байткод для этого вполне адекватен.

Pzz>Байткод это ассемблер некоторой абстрактной машины. К тому времени, когда программа стала байткодом, много существенной информации об исходном коде уже утеряно.
Это в случае, когда байткод выбран неудачно. Современные байткоды пишутся так, чтобы существенной информации не терялось.
Вообще, есть очень хорошая серия книг Аппеля, "Modern compiler implementation". При желании, можно найти в сети. Очень рекомендую почитать — там много написано про то, как вообще работают оптимизирующие компиляторы.

Здравствуйте, Sinclair, Вы писали:

S>Это не имеет отношения к теме. Аппаратная защита контролем границ массивов не занимается. И вряд ли когда-нибудь будет — слишком дорого.

Как это не имеет? Если у всех процессов общая память должны же быть гарантии, что один процесс не съест все остальные...

Здравствуйте, WFrag, Вы писали:


Pzz>>Но как, видя байткод, а не синтаксическое дерево, сделать data flow analysis или вынос инварианта из цикла, я ума не приложу.

WF>Вы видите проблему как специалист по компиляторам, или как дилетант, не осознающий ограниченности своих знаних?

WF>Между прочим, тот же gcc оптимизации делает совсем не на синтаксическом дереве. А на внтуреннем представлении кода, в частности, на коде, представленном в [http://en.wikipedia.org/wiki/Static_single_assignment_form]SSA[/url] форме. А у LLVM, сюрприз, как раз "биткод" с расчетом на SSA сделан.

Да и в книге дракона написано, что оптимизация идет на стадии кодогенерации, а не синтаксического анализа или трансляции.

Здравствуйте, DOOM, Вы писали:

DOO>Как это не имеет? Если у всех процессов общая память должны же быть гарантии, что один процесс не съест все остальные...

Выход за границы массива это далеко не всегда выход за границы памяти процесса.

Здравствуйте, WFrag, Вы писали:
WF>Выход за границы массива это далеко не всегда выход за границы памяти процесса.
На самом деле Doom прав. Никаких "границ процесса" в софтной изоляции не должно быть — не хватит адресного пространства.
Вся идея как раз в том, что данные могут располагаться более-менее вперемешку. Просто есть жесткий контроль за указателями, в частности — никакой арифметики. Благодаря этому всегда есть гарантия, что никакой процесс никогда не увидит чужие данные — у него просто нет средств это сделать.
Зато можно получить очень дешевый маршалинг без копирования — просто система явно вносит указатель на данные процесса-источника в "область видимости" процесса-приемника.

Единственное место, где в управляемой среде остается арифметика указателей — это доступ к массивам. Поэтому все операции доступа к массивам обязаны проходить range check.

Sinclair пишет:

> Pzz>Я тогда не очень понимаю. Если я могу использовать массивы и могу
> вычислять индекс в массиве, каким образом статически можно доказать, что
> я не выскочу за пределы массива?
> Это не имеет отношения к теме. Аппаратная защита контролем границ
> массивов не занимается. И вряд ли когда-нибудь будет — слишком дорого.

У Бабаяна кстати на эту тему (аппаратная защита всего на свете) что-то
было. Не понятно правда чем там дело кончилось.

Здравствуйте, Pzz, Вы писали:

Pzz>Тем не менее, FAQ про DirectShow есть вопрос, будет ли DirectShow доступен через managed код. Ответ — "нет", по причинам произвидительности. Я думаю, это честный ответ.

Честный ответ — MS на него просто забили

DirectShowLib это доказывает. Там ведь просто куча интерфейсов, весь код выполняется в недрах... Другое дело — писать фильтры, где будет реальная обработка видео, например. Но их никто на C# писать и не призывает.

Здравствуйте, Sergey, Вы писали:

S>У Бабаяна кстати на эту тему (аппаратная защита всего на свете) что-то
S>было. Не понятно правда чем там дело кончилось.

У бабы яна много чего было. Больше на словах.

Здравствуйте, Ikemefula, Вы писали:

I>У бабы яна много чего было. Больше на словах.
А ты вообще мог бы помолчать, если сказать ничего не можешь по сути.

Схема защиты памяти в бабаяновских "Эльбрусах" была успешно реализована ещё в OS/390 и Sun SPARC — там старший бит мог использоваться для указания того, что данные в памяти являются указателем. Соответственно, для операции с ним нужны были привиллегированые операции.

Здравствуйте, DOOM, Вы писали:

S>>Это не имеет отношения к теме. Аппаратная защита контролем границ массивов не занимается. И вряд ли когда-нибудь будет — слишком дорого.
DOO>Как это не имеет? Если у всех процессов общая память должны же быть гарантии, что один процесс не съест все остальные...
А как он это может сделать? Адресной арифметики нет, до другого процесса ты можешь добраться только по графу ссылок. Т.е. если тебе не дадут ссылку на объект в другом процессе — ты до другого процесса просто никак не доберёшься.