Центр информации по операционным системам: Форумы / Разное / Язык как основа операционной системы

Центр информации по операционным системам :: Форумы :: Общие :: Разное		<< Предыдущая тема \| Следующая тема >>
Язык как основа операционной системы

Переход на страницу 1 2 3 ... 15 16 [17]
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

Hmmm

Четверг 03.01.2008 15:31

ID пользователя #719

Зарегистрирован: Среда 09.08.2006 11:29
Местонахождение: Москва
Сообщений: 108

ossadchy написал(а) ...

Для начала к вопросу о повышении производительности. Что дает нам разработка системы на типобезопасном языке(в который не включены операции непосредственного обращения к произвольным областям памяти):
1. возможность размещения всех компонент в одном адресном пространстве.
- отсутствие необходимости перезагрузки TLB -- одной из самых медленных и часто выполняющихся операций
2. отсутствие необходимости переключения в режим супервизора -- тоже очень частая операция
3. отсутствие необходимости тратить дополнительные ресурсы на локальный IPC -- также, прошу заметить, немаловажно

Компьютерные вирусы, с вашей точки зрения, есть исключительно плод ошибок программирования? Управление памятью вообще и TLB в частности это вообще отдельная тема, я просто не знаю на каком уровне вы готовы ее обсуждать.
Локальный IPC довольно шустрый, если конечно уметь им пользоваться. Все равно никуда вы от перемещения данных между стеками не денетесь, и shared memory никто еще вроде не отменял. И семафоры и мьютексы и условные переменные придется использовать, поскольку это не есть средства разграничения доступа а лишь средства синхронизации, разницу понимаете? В родственных процессах, получив адрес структуры в памяти, я могу наплевать на мьютексы и работать без них, само по себе их отстутствие или наличие ни в чем меня не ограничивает. Другое дело что в результате ерунда получится.
Вы предлагаете все процессы сделать родственными, я не против этого, вот только одного принципа типобезопасности тут явно не достаточно. Разделять код и данные все равно придется. Делать возможным передавать управление данным тоже придется (через создание алиасов или както еще - не суть) Это значит, что программа может на ходу сгенерировать нужный ей код и передать ему управление, никакая типобезопасность ей не помешает.

ossadchy написал(а) ...

Теперь к вопросу о JIT. Увы но архитектура современных процессоров сильно отстает от задач которые надо решать повседневно. Отсюда и необходимость создания дополнительных прослоек. Можно строить Java и MSIL процессоры, но это дорого, да и технологии все еще развиваются.
С другой стороны, объектно-ориентированный, типобезопасный язык не обязан быть интерпретируемым. Пример -- компилятор Java GCJ.
Да и напомню я написал "как "на лету" так и единожды"

Это как??? Другими словами вы утверждаете, что способы решения повседневных задач не адекватны используемым процессорам? Может проще на другие способы перейти, раз уж вы сами это понимаете?

Наверх

ossadchy

Пятница 04.01.2008 11:18

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

Ну в первой части поста четко прослеживается насколько вы НЕ готовы обсуждать тему программной реализации механизмов защиты в рамках типобезопасных сред. Есть масса работ показывающих что это возможно. В чем-то этот подход перекликается с SASOS, но не буду проводить паралелей дабы не порождать флуд в данной теме.

По поводу разрыва между архитектурой железа и ПО -- это очевидно, и он порождает массу слоев в виде виртуальных машин. С другой стороны железо, которое бы непосредственно могло выполнять байт-коды типа MSIL, Java bytecode достаточно сложно реализуемо, хотя движения в этом направлении есть(PicoJava(tm), к примеру). Но сложно сказать хорошо это или плохо.
С третьей стороны

писать программы в двоичных кодах, на языке ассемблера, на С и даже С++ в наше время сложных программных систем становится все труднее.

Хочу заметить, что прекрасно понимаю что "серебрянной пули нет", но с другой стороны не вижу причин не обсуждать какой либо радикальный подход

Наверх

ossadchy

Понедельник 07.01.2008 12:49

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

2Hmmm: и по-моему разглагольствования на тему "в одном адресном пространстве все будет падать", свидетельствуют как минимум о том что вы совершенно не знакомы с Oberon-системами.

Наверх

Dron

Понедельник 07.01.2008 14:33

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

ossadchy: С оберон системами все выглядит хорошо, пока они никому не нужны... пока система варится в своем соку - она абсолютно неуязвима

А стоит ее подключить к интернету...

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

Андрей Валяев

Наверх

Hmmm

Вторник 08.01.2008 20:10

ID пользователя #719

Зарегистрирован: Среда 09.08.2006 11:29
Местонахождение: Москва
Сообщений: 108

ossadchy написал(а) ...

Ну в первой части поста четко прослеживается насколько вы НЕ готовы обсуждать тему программной реализации механизмов защиты в рамках типобезопасных сред. Есть масса работ показывающих что это возможно. В чем-то этот подход перекликается с SASOS, но не буду проводить паралелей дабы не порождать флуд в данной теме.

Из массы работ хоть одну ссылку могли бы и привести. И потом, хотите сказать, что программные механизмы защиты будут работать быстрее аппаратных? Вы же вроде сетовали на переключение TLB.

ossadchy написал(а) ...

По поводу разрыва между архитектурой железа и ПО -- это очевидно, и он порождает массу слоев в виде виртуальных машин. С другой стороны железо, которое бы непосредственно могло выполнять байт-коды типа MSIL, Java bytecode достаточно сложно реализуемо, хотя движения в этом направлении есть(PicoJava(tm), к примеру). Но сложно сказать хорошо это или плохо.
С третьей стороны

писать программы в двоичных кодах, на языке ассемблера, на С и даже С++ в наше время сложных программных систем становится все труднее.

Я имел в виду немного другое, я хотел указать на то, что интерпретируемые языки сейчас используются где надо и где не надо. Джава и шарп это очевидно из разряда "не надо". Отчасти потому что кодят на них в основном люди малограмотные, про всех не говорю конечно. Отчасти потому что программы на них писанные в основном увеличивают энтропию вселенной из за очень слабой производительности. Вот и хотел что бы вы сами пришли к выводу о негодности этих подходов, раз уж доводы приводимые вами прямо на это указывают. Когда разработчик программы говорит, что его ПО хорошее а процессор для которого оно писано плохой это извините анекдот про танцора.

Наверх

ossadchy

Воскресенье 10.02.2008 13:16

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

ну ведь и Java и C# живы уже много лет и хоть многие с самого начала сетовали на то что эти языки якобы интерпретируемы(хотя компилируются они во время выполнения, что несколько иной подход) эти языки используются и для решения БОЛЬШИНСТВА задач они очень неплохо подходят. Уже и компиляторы Java в нативный код есть, с очень неплохой производительностью. Суть не в Java, C#, глупости и некомпетентности всех в мире этом кроме ВАС, а в росте сложности ПО и необходимости освобождения программиста от рутины(освобождение памяти, к примеру) для того чтоб он мог творить.

ПО SAOS -- ну если уж интересно то всегда в гугле можно вбить это словосочетание...

Наверх

Переход на страницу 1 2 3 ... 15 16 [17]
Перейти: Наверх