Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 6, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Общие :: Разное |
|
<< Предыдущая тема | Следующая тема >> |
| Виртуальные машины (было: Типы данных Java VM) | ||
| Переход на страницу [1] 2 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| Roman I Khimov |
| ||
  ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | Копаю в сторону виртуальной машины .NET и вот какое выяснилось интересное обстоятельство: в стеке машины могут находиться только данные типов int32, int64, native int (родная для машины разрядность) и F (плавающая точка, родная для машины). Соответственно, всякая мелочь вроде восьми- и шестнадцатиразрядных int расширяется до int32 и только затем с ней идет работа, при сохранении, понятное дело, все сворачивается в один-два байта, как положено. Ага. После этого я начал копать исходники NanoVM на предмет выяснения того, как с этим обстоит дело в Java и, насколько я понял, там реально поддерживаются int'ы "мелких" типов, насчет 8-разрядного не уверен, но 16-разрядный виден точно. Соответственно, было интересно спросить у знающего народа как оно на самом деле, до спецификаций сейчас не добраться физически. А так получается, что .NET совершенно не приспособлен для embedded и портировать его на ADuC812 не удастся (то есть можно, но будет ужасно медленно).  [ Редактирование ] Греби и улыбайся! | ||
| Наверх |
| ||
| captain cobalt |
| ||
  ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Это называется "бинарная совместимость".  Даже несмотря на то, что машина - виртуальная, чтобы софт для неё мог быть "написан однажды - работать везде" требуется совместимость реализаций машин "с точностью до бита". Именно поэтому у них строго фиксирован размер в битах всех типов. Java специально была разработана чтобы "достаточно эффективно работать на 32-битных машинах". NET видимо, тоже. Если по делу - я не знаю, имеет ли место означенная проблема. Если это действительно так, то действительно следует похвалить архитекторов Java за более предусмотрительное проектирование несмотря (а может, наоборот, благодаря) на то, что разработчики NET имели возможность учесть их опыт. _____________________________ Альтернативный и более успешный подход называется "совместимость на уровне исходных текстов". При таком подходе во время разработки базовые типы стараются считать непрозрачными, то есть имеющим неизвестный размер. Тогда при перекомпиляции под машину с более широкой разрядностью алгоритмическая корректность сохраняется, но увеличивается диапазон поддерживаемых данных и/или скорость. Такой подход используется, например, в ОС Unix и Oberon. Насколько можно видеть по результатам, это гораздо более практичный способ реализации принципа "написано однажды, работает везде". Поэтому, возможно, всякие виртуальные машины можно считать лишь забавными игрушками, не больше. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
| ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | Насчет совместимости-то понятно, но все-таки не дает покоя вопос. Native int, имеющийся в .NET использовать не рекомендуется, ибо не переносим он. А все остальные - или 32 или 64. Блин, я, конечно, зациклился слегка на этой теме, но вроде бы простые вещи, а не работает, чертовски обидно, хотел занять себя созданием безопасной среды на ADuC812...  А в Java все-таки, насколько я понял, работает. Доберусь до документации - посмотрю точно. Обидно за .NET, хотя, виртуальная машина от этого становится явно проще. Все-таки Java изначально была нацелена на embedded, в отличие от настольного .NET. Ай-ай-ай, обидно, блин...Насчет уместности виртуальных машин не согласная. Это удобно, ибо а) это позволяет создавать действительно безопасные системы (иначе это невозможно без использования аппаратных механизмов процессора). б) прекомпиляция из кода виртуальной машины должна быть быстрее компиляции из исходников (ОК, ОК, зависит от компиляторов/языков, требует тестирования, но должно) в) это удобно для конечного пользователя - бинарник один-единственный, можно сразу запустить и работать, а можно оптимизировать под платформу (читай AOT компиляция). Сюда же относится отсутствие необходимости держать вагон и маленькую тележку *.h файлов на диске (хотя, если я правильно пониманию, для Oberon и бутылки это не актуально - язык правильный) Греби и улыбайся! | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
| ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | Единственное, что меня сейчас тревожит, так это стековость этих машин. Как же так, получается, что от прекрасных технологий современных процессоров в виде MMX, SSE1/2/3, 3DNow!, AltiVec и прочих мы не выигрываем ни-че-го? А между тем GCC 4.x обрел автовекторизацию и может использовать это все на обычном коде! А виртуальные машины в пролете? Очень нехорошо получается. Греби и улыбайся! | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
| ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | И тем приятнее узнавать о вот таких проектах: http://www.parrotcode.org/ Регистровая архитектура, машина для Perl 6, хотя я уже упоминал на OSRC язык "Amber for Parrot". Греби и улыбайся! | ||
| Наверх |
| ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Roman I Khimov написал(а) ... Ничего страшного, каждый зациклился на какой-нибудь теме. Блин, я, конечно, зациклился слегка на этой теме Roman I Khimov написал(а) ... И ведь ещё тормозит на этих мощных рабочих станциях.Все-таки Java изначально была нацелена на embedded, в отличие от настольного .NET. Ай-ай-ай, обидно, блин... Roman I Khimov написал(а) ... Разумеется, возможно, если вместо виртуальной машины брать исходники. а) это позволяет создавать действительно безопасные системы (иначе это невозможно без использования аппаратных механизмов процессора). Roman I Khimov написал(а) ... Да, компилятору приходится переделывать из стека обратно на регистры. Глупость какая-то.Единственное, что меня сейчас тревожит, так это стековость этих машин. Roman I Khimov написал(а) ... Здесь как раз виноват пункт б)Как же так, получается, что от прекрасных технологий современных процессоров в виде MMX, SSE1/2/3, 3DNow!, AltiVec и прочих мы не выигрываем ни-че-го? А между тем GCC 4.x обрел автовекторизацию и может использовать это все на обычном коде! А виртуальные машины в пролете? Очень нехорошо получается. Roman I Khimov написал(а) ... б) прекомпиляция из кода виртуальной машины должна быть быстрее компиляции из исходников (ОК, ОК, зависит от компиляторов/языков, требует тестирования, но должно) bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
| ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | captain cobalt написал(а) ... Roman I Khimov написал(а) ... а) это позволяет создавать действительно безопасные системы (иначе это невозможно без использования аппаратных механизмов процессора). Разумеется, возможно, если вместо виртуальной машины брать исходники. Черт, кажется, наконец-то вошло в мозг. Если все от и до компилировать из исходников на безопасных языках, то да. Но все-таки их можно подменить так, чтобы они изменяли бинарники, лежащие в ФС. Ну а неконтроллируемый native binary code в нулевом кольце - это крах. Так что все-таки нет, это не подходит. Хотя бывают еще и механизмы подписей. И, в принципе, они работают. Ну а раз мы работаем только с исходниками и их аутентичность подтверждена, то исходя из безопасности языка мы имеем безопасную среду. Ха! Однако ж, есть проблема - не бывает так, чтобы один язык. Вот тут уже не сделать ничего, кроме как изобретать средства взаимодействия различной степени красоты. Плюс к этому появляется возможность использовать небезопасный язык и тогда даже неправильно написанный "Hello world" способен убить систему, ибо нулевое кольцо защиты. Нет уж, безопасность начинается не с этой стороны. К тому же, бизнесу еще длительное время так или иначе придется иметь дело с бинарными проприетарными приложениями, которым доверять невозможно вообще. captain cobalt написал(а) ... Да, компилятору приходится переделывать из стека обратно на регистры. Глупость какая-то. Все-таки, мне кажется, что это еще пол-беды, неиспользование же векторных расширений - почти преступление! Греби и улыбайся! | ||
| Наверх |
| ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Roman I Khimov написал(а) ... По отношению к бинарникам на ФС вряд ли есть различие. В обоих случаях может использоватся контроль доступа, чтобы исключить это.Черт, кажется, наконец-то вошло в мозг. Если все от и до компилировать из исходников на безопасных языках, то да. Но все-таки их можно подменить так, чтобы они изменяли бинарники, лежащие в ФС. Roman I Khimov написал(а) ... Это крах только в случае злоумышленности. Ну а неконтроллируемый native binary code в нулевом кольце - это крах. Почему во всех попсовых ОС (включая Windows, Linux, MacOS X, Solaris) имеется возможность загружать "модули ядра"? Roman I Khimov написал(а) ... Здесь есть надежда на бинарную компиляцию.К тому же, бизнесу еще длительное время так или иначе придется иметь дело с бинарными проприетарными приложениями, которым доверять невозможно вообще. Например, команде МЦСТ/Эльбрус, удалось ещё в 1997 году, судя по публикациям, запустить Windows на SPARC, используя (динамическую) компиляцию x86 -> SPARC. Аналогичным образом можно преобразовать "опасный" код в безопасный. Коду выделяется некоторый участок в общей памяти. Код анализируется, и там где во время компиляции невозможно определить попадание формируемого адреса у данный участок, перед этой командой вставлять команду проверки. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Roman I Khimov |
| ||
| ID пользователя #1 Зарегистрирован: Воскресенье 27.06.2004 12:37Местонахождение: Санкт-Петербург Сообщений: 601 | captain cobalt написал(а) ... По отношению к бинарникам на ФС вряд ли есть различие. В обоих случаях может использоватся контроль доступа, чтобы исключить это. AOT бинарники можно сделать вообще недоступными из ФС - и это будет правильно. Механизмы контроля доступа все-таки могут где-то прорываться. Впрочем, это уже такие вещи, о которых невозможно говорить без конкретных систем и конкретных на них атак. captain cobalt написал(а) ... Это крах только в случае злоумышленности. Доброжелатели найдутся всегда, тут можно не сомневаться. captain cobalt написал(а) ... Почему во всех попсовых ОС (включая Windows, Linux, MacOS X, Solaris) имеется возможность загружать "модули ядра"? Есть большое и великое "НАДА". Хотя, конечно, это тоже не способствует безопасности - от root (или Администратора) система не защищена ничуть. captain cobalt написал(а) ... Аналогичным образом можно преобразовать "опасный" код в безопасный. Коду выделяется некоторый участок в общей памяти. Код анализируется, и там где во время компиляции невозможно определить попадание формируемого адреса у данный участок, перед этой командой вставлять команду проверки. А не многовато ли анализа, тем более учитывая запутанность и сложность того же x86? Впрочем, тут тоже уже надо смотреть на конкретные примеры... Греби и улыбайся! | ||
| Наверх |
| ||
| captain cobalt |
| ||
| ID пользователя #12 Зарегистрирован: Воскресенье 04.07.2004 21:44Местонахождение: /ru/perm Сообщений: 144 | Roman I Khimov написал(а) ... Вот именно.Есть большое и великое "НАДА". Микроядерщики могут попить воды. В такой ситуации можно предпринять только две вещи: 1. Чётко разделить опасный и безопасный код. 2. Помочь сделать опасный код более безопасным на уровне языка программирования. Чистые низкоуровневые языки плохо помогают в этом, а виртуальные машины не позволяют низкоуровневого программирования и могут иметь ограниченную производительность (основная причина "НАДА"). Roman I Khimov написал(а) ... С качественной точки зрения, анализировать меньше, чем в современных оптимизирующих компиляторах. Ещё можно облегчить задачу, если реализовать сначала только необходимые команды; скорее всего, компилировать придётся скомпилированную программу, а компиляторы в сгенерированном коде используют не все существующие команды.А не многовато ли анализа, тем более учитывая запутанность и сложность того же x86? Впрочем, тут тоже уже надо смотреть на конкретные примеры... Конкретных примеров не знаю. bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом. | ||
| Наверх |
| ||
| Переход на страницу [1] 2 | |
Powered by e107 Forum System