Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 76 14-06-2006 11:15 | |
Ответ на »сообщение 73« (AVC)
___________________________
Я тоже стараюсь подойти к формулировке этого важнейшего качества ОТ.
Т.е. интуитивно оно (почти) понятно.
Но хочется внятно для себя сформулировать, почему это так важно.
Потому что избыточная сложность есть уязвимость.
Вот это-то и есть, кстати, принцип Калашникова.
№ 75 14-06-2006 08:39 | |
Ответ на »сообщение 57« (Alexey Veselovsky)
___________________________
Не совсем понимаю суть вопроса.
Касаемо BlackBox: это же Windows-программа и она подчиняеется тем же правилам, что и любая другая Windows-программа.
Oberon System и Bluebotle действительно не защищены от криво- и злонамеренно-написанных программ. Но даже если подключать аппаратную защиту, в разделении адресных пространств нет никакой необходимости.
К тому же в этих системах нет виртуальной памяти, а значит, нет надобности иметь больше адресного пространства, чем физической памяти.
№ 74 14-06-2006 08:05 | |
Предлагаю такой план действий. :)
Сначала мы все (скажем, в течение недели) составим и "утвердим" список основных механизмов ОТ, а затем станем исследовать эти механизмы более пристально.
В силу сложности детального изучения (Оберон, простой для прикладного программиста, не так уж прост внутри; чего стоят одни только тонкости раздельной компиляции и фингерпринтов), возможно, имеет смысл иногда разбиваться на группы.
№ 73 14-06-2006 07:29 | |
Ответ на »сообщение 71« (info21)
___________________________
Один из ключевых элементов ОТ -- отсутствие (почти) всего лишнего. Этот элемент отсутствует во многих других технологиях.
Но с другой стороны, в лиспе и форте нет, кажется, и необходимого (для читабельности, для эффективности и т.п.).
Т.е. эпиграф "Make it as simple as possible, but not simpler" (он же известный KISS-principle или "принцип Калашникова") точно выражает подход Оберона. :)
Я тоже стараюсь подойти к формулировке этого важнейшего качества ОТ.
Т.е. интуитивно оно (почти) понятно.
Но хочется внятно для себя сформулировать, почему это так важно.
Что здесь, так сказать, Сцилла, а что -- Харибда. :)
Догадываюсь, что здесь есть родство и с обычными принципами структурирования программ (например -- once & only once у Бека в экстремальном программировании и т.д.).
Также предлагаю к ОТ отнести способ конструирования языка и компилятора -- легкость подстройки того и другого под специальные приложения есть важно.
В принципе согласен.
Сужу о подходе Вирта к построению языка и компилятора по его книге "Compiler construction" и любопытной статье Мессенбека (кажется, из книги "The art of simplicity"; или что-то похожее).
Ну, и, немного, -- по исходным текстам компиляторов Оберона и КП.
Единственное, что немного смущает, это сознательный отказ от значительной оптимизации и использования метода раскраски графа при распределении регистров. :)
(Взамен Вирт использует принцип delayed code emission.)
Но простота, несомненно, окупается.
А в случае slim binaries еще и дает неожиданные (?) дивиденды.
№ 72 14-06-2006 07:12 | |
Ответ на »сообщение 64« (Alexey Veselovsky)
___________________________
Собственно не имея защиты памяти, мы создаем прям таки рай для всяких кулхацкеров. То что запускаемый модуль вроде как не импортирует SYSTEM еще не означает что в нем не используется адресная арифметика, что он не напакостит в память. Ибо бинарник после компиляции можно и ручками подправить. И убрать упоминание о SYSTEM.
Выхода 2: первый - распространять модули в промежуточном коде, второй - положиться на прогресс железа. В процессоры понемногу проникает защита памяти в рамках одного адресного пространства (например, наши в "Эльбрусе" предлагали для этого механизм тегов, практически типизация на аппаратном уровне) и рано или поздно этот механизм будет реализован в полной мере.
№ 71 14-06-2006 06:55 | |
Ответ на »сообщение 56« (AVC)
___________________________
Уважаемый AVC, раньше не смог передать мысль, попробую другими словами :-)
Один из ключевых элементов ОТ -- отсутствие (почти) всего лишнего. Этот элемент отсутствует во многих других технологиях.
Но с другой стороны, в лиспе и форте нет, кажется, и необходимого (для читабельности, для эффективности и т.п.).
Также предлагаю к ОТ отнести способ конструирования языка и компилятора -- легкость подстройки того и другого под специальные приложения есть важно.
№ 70 14-06-2006 06:53 | |
№ 69 14-06-2006 06:47 | |
Ответ на »сообщение 66« (Андрей Хохлов)
Вполне возможно, что фраза вырвана из контекста, а буквальное ее толкование представляетс крайне сомнительным. А может просто хороший != великий.
Литературоведы утверждают, что у Шекспира практически нет своих сюжетов.
Все они (или почти все; смягчу, ведь я не литературовед :) ) -- заимсвованы.
Но кто решится сказать, что Шекспир -- не великий драматург? :)
№ 68 14-06-2006 06:42 | |
№ 67 14-06-2006 06:40 | |
Ответ на »сообщение 64« (Alexey Veselovsky)
___________________________
С первым понятно. Со вторым - нет. Сборки чего?
Речь идет о некоем аналоге приложения в обычных системах.
Если приложению требуется модуль, то для приложения подгружается отдельная копия этого модуля. (За исключением нескольких системных модулей ядра.)
Зато потом можно выгрузить все приложение целиком -- и модули, и документы -- не задевая других приложений.
Если адресное пространство у всех задач одно и то же, и память никак не защищена, то работа системы становится непредсказуемой.
Конечно.
Но, ИМХО, для того, чтобы гарантировать инварианты памяти, необязательно отказываться от единого адресного пространства.
Проблему можно решать с помощью языковых средств -- ограничений промежуточного языка системы (как в .NET) или безопасной моноязычности (как в Обероне).
Собственно не имея защиты памяти, мы создаем прям таки рай для всяких кулхацкеров. То что запускаемый модуль вроде как не импортирует SYSTEM еще не означает что в нем не используется адресная арифметика, что он не напакостит в память. Ибо бинарник после компиляции можно и ручками подправить. И убрать упоминание о SYSTEM.
Бинарник можно защищать контрольными суммами (это может быть частью фингерпринта) или иными способами.
Другой подход -- slim binaries Франца.
Читал, что их загрузка всего на 10-20% медленнее объектных модулей.
Т.о. без защиты памяти система крайне уязвима для: 1)Ошибок. 2)Преднамеренного вредительства.
И если первое еще как-то лечится запретом импорта SYSTEM для несистемных модулей, то второе уже не лечится.
Вы полагаете, что это лечится в других системах?
Ведь опасным может быть не только "падение" конкретной программы, но и неверное вычисление, и принятое вследствие этого решение и т.д.
Ну, если в модуле MATH, кто-то на функцию SUM повесил не а+б, а а-б, то тут уже ничего не поделаешь.
Зато можно предотвратить ошибки, связанные с нарушениями инвариантов памяти (выход за границы массива, обращение по висячему указателю, неверная интерпретация полей вариантной записи и т.п.).
Так. А давайте еще вспомним, что в большенстве оберон-системы (в т.ч. и ББ) у нас есть проблема со сборщиком мусора для многопоточных приложений...
Думается, что именно все эти проблемы и привели к Active Oberon и Bluebottle.
Согласен, именно противоречия и нерешенные проблемы вызывают эволюцию.
Не стоит рассматривать вещи как что-то застывшее и неизменное.
Поэтому название нашей языковой ветки и содержит слово "эволюция".
Active Oberon, кроме прочего, добавил потоковую безопасность (thread-safe).
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|