Здравствуйте, AVC, Вы писали:
AVC>Увы, я практически не знаком с устройством OS/360.
Я тоже AVC>В принципе, я согласен с Вами в том, что "центр тяжести" обсуждения сместился к многозадачным ОС. Еще точнее, достаточно ли в многозадачной ОС загрузить каждый используемый модуль однократно, или требуется дублировать код по соображениям безопасности.
Ну в винде код шарится между процессами. В Обероне шарится не только код но и данные что не есть гуд. Ведь основная проблема программ не АВ как здесь пытаются представить защитники оберона(у меня и в С++ никаких АВ нет), а ошибки в логике которые к АВ не приводят но они случаются гораздо чаще и проблем с ними гораздо больше особенно если это просчет в арихитектуре программы у которой исходники измеряются мегабайтами и это не по тому что программисты тупые, а по тому что меньше всеравно не получится.
Я сейчас пишу под .НЕТ который защищен не хуже Оберона и прекрасно понимаю о чем говорю. AVC>На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".
1)Какие противники? Ты о чем? Чтобы у чегото были противники это что-то должно чегото стоить чего про обероны сказать нельзя. Народ тут просто развлекается...
2)В том то и дело что могут себе представить что произойдет с системой без защиты в которой начинают запускать кучу разнородного софта. Защита от АВ это не защита. Данные и без АВ можно испортить. AVC>Должен признать, что и наши аргументы иногда неубедительны.
Защита от АВ это конечно хорошо и с этим спорить глупо но назывть защиту от АВ панацеей еще глупее. AVC>Я думаю, все это по причине плохой информированности. Ведь по Windows, UNIX и Linux доступно море литературы, а вот книг по Оберону у нас в продаже нет. AVC>Это совсем не означает, что Windows или Linux — хорошо, а Оберон — плохо. Это всего лишь политика издательств.
Судя по той информации которую предоставил гн Губанов и компания в оберонах есть только защита памяти, а этого не достаточно для стабильного функционирования системы. Да и если вспомнить про то что кое что всетки пишется на не безопасных языках, да и в Обероне
AVC пишет:
> в Обероне, до простого как мычание объявления > >videobuffer[E4000000H]: VideobufferType; > > как это было предложено делать в старой книге Вирта "Программирование > на Модуле".
Внимание, вопрос! А как GC будет взаимодействовать с такими указателями?
Здравствуйте, Sergey, Вы писали:
S>Hello, Сергей! S>You wrote on Mon, 24 Jan 2005 13:57:59 GMT:
Д>>> И драйверов к железу тоже никогда не будет?
СГ>> Какая связь между языками Си/Си++ и драйверами? СГ>> Драйверы под оберон-системы пишутся на самих оберонах.
S>Дано: буфер видеокарты расположен по адресу 0xE4000000-0xE7FFFFFF. Требуется S>установить байт 0xE4000040 в 0xCE, шоб точку на экране показать. Как это S>сделать, принимая во внимание, что "вопрос "...менять содержимое памяти, S>принадлежащей другому приложению" не имеет физического смысла, поскольку в S>языке нет способа узнать что-либо про память, нельзя получить численное S>значение указателя (указатель — вещь в себе, его численное значение, если бы S>его можно было бы получить, оказалось бы вовсе не константой, а то и дело S>изменялось бы благодаря стараниям сборщика мусора)."?
S>With best regards, Sergey.
Скачайте сами и посмотрите. Система открытая. Лично я не смотрел, не знаю.
Hello, Сергей!
You wrote on Mon, 24 Jan 2005 16:21:41 GMT:
Д>>>> И драйверов к железу тоже никогда не будет?
СГ>>> Какая связь между языками Си/Си++ и драйверами? СГ>>> Драйверы под оберон-системы пишутся на самих оберонах.
S>> Дано: буфер видеокарты расположен по адресу 0xE4000000-0xE7FFFFFF. S>> Требуется установить байт 0xE4000040 в 0xCE, шоб точку на экране S>> показать. Как это сделать, принимая во внимание, что "вопрос "...менять S>> содержимое памяти, принадлежащей другому приложению" не имеет S>> физического смысла, поскольку в языке нет способа узнать что-либо про S>> память, нельзя получить численное значение указателя (указатель — вещь S>> в себе, его численное значение, если бы его можно было бы получить, S>> оказалось бы вовсе не константой, а то и дело изменялось бы благодаря S>> стараниям сборщика мусора)."?
СГ> Скачайте сами и посмотрите. Система открытая. Лично я не смотрел, не СГ> знаю.
Зачем? Я и так знаю, что без низкоуровневого доступа к памяти этого не
сделать. Соответственно, либо в Обероне есть средства для такого доступа,
либо драйвера/ядро написаны не на Обероне.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
A>> Указатель на видеобуфер, скорее всего, устанавливается в A>> пользовательском модуле, а в одном из модулей ядра. Ядро может быть A>> написано как на Обероне, так и на ассемблере. S>Нестыковка номер раз — утверждается, что ядро может быть написано только на S>обероне.
Ага, понял. Устраивается, так сказать, очная ставка.
Ядро может быть написано целиком на Обероне. Но на практике некоторая (небольшая) часть ядра часто пишется на ассемблере. Этот код мал, тщательно верифицирован и пишется в соответствии с требованиями Оберон-системы.
Код же расширений системы пишется программистами на Обероне, чтобы позволить компилятору контролировать свойства кода.
(В принципе, можно представить себе и создание "песочницы" для других языков: Си, Си++ и т.д. В таком случае они будут получать доступ к системе не прямо и эффективно, как программы на Обероне, а через специальный API, как, в принципе, это и делается в других системах. Так, как и привыкли делать программисты на этих языках.)
A>> самом деле, не слишком актуален. На всякий случай, напомню, что в A>> Обероне, как и раньше в Модуле, существуют средства низкого уровня A>> (low-level facilities), используемые для подобных целей. S>Нестыковка номер два — утверждалось, что низкоуровневых средств нет.
Средства низкого уровня упоминаются в описании языка Оберон.
Некоторые из них являются частью псевдомодуля SYSTEM, например: BYTE, PTR, VAL и т.п.
A>> А что такого страшного написал Губанов? S>Цитирую еще раз: S>1) "Драйверы под оберон-системы пишутся на самих оберонах" S>2) "...в языке нет способа узнать что-либо про память, нельзя получить S>численное S>значение указателя (указатель — вещь в себе, его численное значение, если бы S>его можно было бы получить, оказалось бы вовсе не константой, а то и дело S>изменялось бы благодаря стараниям сборщика мусора)"
S>Соответственно, либо эти утверждения являются истиной, либо для S>Оберон-систем в принципе возможны драйвера S>Соответственно, если у нас низкоуровневый доступ, вопрос о защищенности S>переходит из качественного в количественный — скока там реально получится S>багов, роняющих систему. То, что такие баги будут в принципе возможны, уже S>очевидно.
Низкоуровневый доступ может быть и запрещен при компиляции модулей, не входящих в ядро. Это зависит от предполагаемого использования Оберон-системы.
Само выделение низкоуровневых средств языка в отдельную часть, которую можно и не разрешить на определенных уровнях системы, — хорошая мысль. Такое деление возникло еще в Модуле-2.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, WolfHound, Вы писали:
WH>Ну в винде код шарится между процессами. В Обероне шарится не только код но и данные что не есть гуд. Ведь основная проблема программ не АВ как здесь пытаются представить защитники оберона(у меня и в С++ никаких АВ нет), а ошибки в логике которые к АВ не приводят но они случаются гораздо чаще и проблем с ними гораздо больше особенно если это просчет в арихитектуре программы у которой исходники измеряются мегабайтами и это не по тому что программисты тупые, а по тому что меньше всеравно не получится.
Наивный вопрос: что такое АВ?
WH>Я сейчас пишу под .НЕТ который защищен не хуже Оберона и прекрасно понимаю о чем говорю.
Особенно если учесть, что C# и Java — вариации Оберона, с Си-подобным синтаксисом для маскировки очевидных заимствований.
WH>1)Какие противники? Ты о чем? Чтобы у чегото были противники это что-то должно чегото стоить чего про обероны сказать нельзя. Народ тут просто развлекается...
Вот образец логики: защитники у Оберона все-таки есть (см. Ваш пассаж выше), а вот противников — нет.
Если так, то хорошо: "консенсус" достигнут.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Hello, AVC!
You wrote on Mon, 24 Jan 2005 16:31:00 GMT:
A>>> Указатель на видеобуфер, скорее всего, устанавливается в A>>> пользовательском модуле, а в одном из модулей ядра. Ядро может быть A>>> написано как на Обероне, так и на ассемблере. S>> Нестыковка номер раз — утверждается, что ядро может быть написано S>> только на обероне.
A> Ага, понял. Устраивается, так сказать, очная ставка.
Ну, примерно Просто в показаниях гражданина Губанова было замечено
довольно много противоречий. Некоторые из них пора бы разрешить, иначе флейм
совсем уж бессодержательный получается.
A> Ядро может быть написано целиком на Обероне.
Ответ на этот вопрос зависит от того, есть ли в Обероне низкоуровневые
средства. Для доступа к памяти и портам ввода/вывода хотя бы.
Да, а типизация там статическая или динамическая?
A> Но на практике некоторая (небольшая) часть ядра часто пишется на A> ассемблере. Этот код мал, тщательно верифицирован и пишется в A> соответствии с требованиями Оберон-системы. Код же расширений системы A> пишется программистами на Обероне, чтобы позволить компилятору A> контролировать свойства кода. (В принципе, можно представить себе и A> создание "песочницы" для других языков: Си, Си++ и т.д. В таком случае A> они будут получать доступ к системе не прямо и эффективно, как программы A> на Обероне, а через специальный API, как, в принципе, это и делается в A> других системах. Так, как и привыкли делать программисты на этих A> языках.)
Ну вот в это я уже верю. Для полного счастья не хватает обхода системы
типов — чтобы можно было эффективно писать библиотеки ввода.
A> Низкоуровневый доступ может быть и запрещен при компиляции модулей, не A> входящих в ядро. Это зависит от предполагаемого использования A> Оберон-системы. Само выделение низкоуровневых средств языка в отдельную A> часть, которую можно и не разрешить на определенных уровнях системы, - A> хорошая мысль. Такое деление возникло еще в Модуле-2.
Есть идеи и получше — перенести проверки валидности указателей на уровень
железа. Как Бабаян предлагает, например. Учитывая, что Intel купила МЦСТ,
лично мне это представляется более вероятным, чем тотальное нашествие
Оберон-систем.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Cyberax, Вы писали:
>> в Обероне, до простого как мычание объявления >> >>videobuffer[E4000000H]: VideobufferType; >> >> как это было предложено делать в старой книге Вирта "Программирование >> на Модуле". C>Внимание, вопрос! А как GC будет взаимодействовать с такими указателями?
С каким торжеством. Внимание! Вопрос!!!
Да никак! Или Вы предполагаете, что сумасшедшие авторы ядра присвоят указателю на видеобуфер нулевое значение? Доступные же снаружи ядра расширения не могут задействовать GC для "удаления видеобуфера" — ведь у них только копии этого указателя.
Кроме того, необязательно это должен быть указатель.
Ведь я предлагал несколько решений. Указатель — только одно из таких решений. Просто Sergey хотел получить именно указатель.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Hello, AVC!
You wrote on Mon, 24 Jan 2005 16:51:50 GMT:
A> них только копии этого указателя. Кроме того, необязательно это A> должен быть указатель. Ведь я предлагал несколько решений. Указатель - A> только одно из таких решений. Просто Sergey хотел получить именно A> указатель.
Я имел в виду запись по адресу. Указатель это вообще термин конкретного
языка (языков). Чтобы обрушить систему, нужна именно запись по произвольному
адресу, не важно как конкретно она будет называться. Для этого вполне
достаточен бейсиковский POKE.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
A>> Ага, понял. Устраивается, так сказать, очная ставка. S>Ну, примерно Просто в показаниях гражданина Губанова было замечено S>довольно много противоречий. Некоторые из них пора бы разрешить, иначе флейм S>совсем уж бессодержательный получается.
Уверен, что Сергей сам поправит себя, если он допустил такие противоречия.
В свою очередь, если я в свою очередь буду противоречить себе (как говорится, и на старуху бывает проруха ), то, пожалуйста, указывайте мне на эти противоречия.
A>> Ядро может быть написано целиком на Обероне.
S>Ответ на этот вопрос зависит от того, есть ли в Обероне низкоуровневые S>средства. Для доступа к памяти и портам ввода/вывода хотя бы. S>Да, а типизация там статическая или динамическая?
Средства низкого уровня в Обероне есть. Другое дело — кому они доступны. Это уже вопрос системной "политики".
Типизация в Обероне — статическая.
Но для указателей и параметров-переменных это требование смягчается, чтобы поддержать возможности ООП. Для них, кроме статического контроля базового типа, есть дополнительные средства:
1) type test:
IF (p IS NeededPtr) THEN ... END;
2) type guard:
p(NeededPtr).x := 21;
или
WITH p: NeededPtr DO ... ELSE(* если не хотим исключения *)END;
S>Ну вот в это я уже верю. Для полного счастья не хватает обхода системы S>типов — чтобы можно было эффективно писать библиотеки ввода.
Такие средства есть.
Это уже упоминавшийся BYTE (и ARRAY OF BYTE), кроме него: PUT, GET и т.д.
Но это опять же средства низкого уровня.
S>Есть идеи и получше — перенести проверки валидности указателей на уровень S>железа. Как Бабаян предлагает, например. Учитывая, что Intel купила МЦСТ, S>лично мне это представляется более вероятным, чем тотальное нашествие S>Оберон-систем.
Интересно!
Но мне приходится иметь дело с самыми разными процессорами, а не только Intel-овскими.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
>>> как это было предложено делать в старой книге Вирта "Программирование >>> на Модуле". > C>Внимание, вопрос! А как GC будет взаимодействовать с такими указателями? > С каким торжеством. Внимание! Вопрос!!! > Да никак! Или Вы предполагаете, что сумасшедшие авторы ядра присвоят > указателю на видеобуфер нулевое значение? Доступные же снаружи ядра > расширения не могут задействовать GC для "удаления видеобуфера" — ведь > у них только *копии* этого указателя.
GC при сборе мусора проходит по всему графу ссылок. Такие ссылки на
области памяти могут доставить ему немало проблем.
> Кроме того, необязательно это должен быть указатель. > Ведь я предлагал несколько решений. Указатель — только одно из таких > решений. Просто Sergey хотел получить именно указатель.
А что еще? Не делать же Peek(0x1238146) как в Бэйсике
Здравствуйте, AVC, Вы писали:
AVC>Наивный вопрос: что такое АВ?
Транслитерация (лень раскладку переключять) сокращения AV от Access Violation
AVC>Особенно если учесть, что C# и Java — вариации Оберона, с Си-подобным синтаксисом для маскировки очевидных заимствований.
А фанаты смаллтолка утверждают что эти системы происходят от смаллтолка...
AVC>Вот образец логики: защитники у Оберона все-таки есть (см. Ваш пассаж выше), а вот противников — нет.
А с логикой тут все в порядке. Лично мне Оберон глубоко по барабану(Я сюда просто потрепатся захожу когда работа задалбывает). А тебе и Губанову судя по всему нет. Вот вы и кидаетесь на всех кто высказывает сомнения в том что оберон решит все проблемы человечества.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
>> Кроме того, необязательно это должен быть указатель. >> Ведь я предлагал несколько решений. Указатель — только одно из таких >> решений. Просто Sergey хотел получить именно указатель. C>А что еще? Не делать же Peek(0x1238146) как в Бэйсике
А почему бы и нет?
Например, аналог Peek в Обероне — встраиваемая функция псевдомодуля SYSTEM
GET(address, variable);
Разница в том, что присваивание соответствует типу переменной variable.
C>ЗЫ: я сейчас пишу GC.
Вот это уже действительно интересно!
А почему? Ведь, вроде бы, и в Java, и в C# GC уже есть.
P.S. Если я сегодня вдруг "замолчу" (уже не успею ответить), то отвечу завтра.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, WolfHound, Вы писали:
AVC>>Наивный вопрос: что такое АВ? WH>Транслитерация (лень раскладку переключять) сокращения AV от Access Violation
Спасибо!
Я, увы, не догадался.
AVC>>Особенно если учесть, что C# и Java — вариации Оберона, с Си-подобным синтаксисом для маскировки очевидных заимствований. WH>А фанаты смаллтолка утверждают что эти системы происходят от смаллтолка...
Интересно, могут ли фанаты смоллтока подтвердить это, в то время как можно продемонстрировать, что практически все конструкции Java (по крайней мере, первоначальной) имеют аналоги в значительно более раннем языке Оберон, о котором в Sun не могли не знать (т.к. имели лицензию на ETH Oberon)?
AVC>>Вот образец логики: защитники у Оберона все-таки есть (см. Ваш пассаж выше), а вот противников — нет. WH>А с логикой тут все в порядке. Лично мне Оберон глубоко по барабану(Я сюда просто потрепатся захожу когда работа задалбывает). А тебе и Губанову судя по всему нет. Вот вы и кидаетесь на всех кто высказывает сомнения в том что оберон решит все проблемы человечества.
Я вроде бы ни на кого не кидаюсь.
И уж, тем более, никому не навязываю "треп", если он мне не интересен.
Вообще-то, все было прямо наоборот Вашему утверждению.
Мне подумалось, что Оберон-система — хорошее решение для некоторых задач.
Вот я и вынес на обсуждение вопрос: "Есть ли плюсы у Оберона?" (вот так я "на всех набросился").
Тут-то на мою бедную голову и посыпался град критики.
Я-де и Рихтера не читал, и т.д. и т.п.
(Вот если бы я признавался в любви к Си++, да еще с такой же абсурдной мотивировкой, как Курилка: люблю я его, гада, и все тут.)
Может быть, это были такие же "праздношатающиеся", как и Вы?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC пишет:
>>> Кроме того, необязательно это должен быть указатель. >>> Ведь я предлагал несколько решений. Указатель — только одно из таких >>> решений. Просто Sergey хотел получить именно указатель. > C>А что еще? Не делать же Peek(0x1238146) как в Бэйсике > А почему бы и нет? > Например, аналог Peek в Обероне — встраиваемая функция псевдомодуля SYSTEM > >GET(address, variable); > > Разница в том, что присваивание соответствует типу переменной variable.
А скорость будет... Представляю себе копирование многомегабайтных
массивов в видеопамять с помощью Poke'ов.
> C>ЗЫ: я сейчас пишу GC. > Вот это уже действительно интересно! > А почему? Ведь, вроде бы, и в Java, и в C# GC уже есть.
Для встраивания в Mono — там сейчас у них консервативный GC, а я пытаюсь
написать точный.
Здравствуйте, AVC, Вы писали:
AVC>(Вот если бы я признавался в любви к Си++, да еще с такой же абсурдной мотивировкой, как Курилка: люблю я его, гада, и все тут.)
Говорил я себе: никогда не пиши второпях, не дави на "клаву", если нет времени подумать!
Вот и сейчас: взял и оклеветал Курилку ни за что, ни про что!
Вышел из конторы, и екнуло: это был не Курилка, а Зверек Харьковский со своей статьей "C++ulture".
Приношу Курилке мои извинения (даже если он и вправду любит Си++ такой же безумной любовью, как и Зверек Харьковский )!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Cyberax, Вы писали:
>> C>А что еще? Не делать же Peek(0x1238146) как в Бэйсике >> А почему бы и нет? >> Например, аналог Peek в Обероне — встраиваемая функция псевдомодуля SYSTEM >> >>GET(address, variable); >> >> Разница в том, что присваивание соответствует типу переменной variable. C>А скорость будет... Представляю себе копирование многомегабайтных C>массивов в видеопамять с помощью Poke'ов.
Вот здесь Вы точно не правы!
Дело в том, что так называемый модуль SYSTEM (к которому относится процедура GET) — это псевдомодуль, реализуемый компилятором.
Практически все его функции — встраиваемые, многие из них реализуются одной-единственной машинной инструкцией.
Мало того, специально для пересылки "многомебайтных массивов" существует процедура MOVE.
Так что в данном случае Вам как раз гарантирована максимальная эффективность.
>> C>ЗЫ: я сейчас пишу GC. >> Вот это уже действительно интересно! >> А почему? Ведь, вроде бы, и в Java, и в C# GC уже есть. C>Для встраивания в Mono — там сейчас у них консервативный GC, а я пытаюсь C>написать точный.
Хотелось бы впоследствии узнать, удалась ли Ваша затея, и какие "подводные камни" Вам пришлось преодолеть.
Несмотря на расхождение во взглядах, мне всегда интересна точка зрения человека, делающего что-то самостоятельно.
Мой внезапный интерес к Оберону основан на практических мотивах: кроме компиляторов и отладчиков, которые я сейчас пишу для маленьких дешевых процессоров, возникла потребность в простой, эффективной, но достаточно надежной операционной системе. Оценив наши конкретные ограничения, я отбросил мысли о каких бы то ни было вариантах Linux и остановился на Обероне.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Драйверы под оберон-системы пишутся на самих оберонах.
Это мы уже проходили.
Которые делаются с помощью специальных "низкоуровневых библиотек", которые позволяют с легкостью прибить всю систему, и таким образом сводят на нет все преимущества как ОС, так и языка.
Здравствуйте, AVC, Вы писали:
AVC>На мой взгляд, противники Оберон-систем игнорируют факт существования многозадачных Оберон-систем, который вряд ли оспорим. Посему аргументы варьируются от "я не могу себе этого представить" до "черт побери, КАК это работает?!".
Запорожец-лимузин тоже существует. Только это не доказывает, что он годится хоть для какого-то практического использования.
И вопрос звучит не "КАК это работает", а "где гарантия, что это будет работать НЕ в лабораторных условиях"
Здравствуйте, Cyberax, Вы писали:
C>Прекрасно. Мы уже выяснили, что потоки называются в Обероне "активными C>объектами". Следующий вопрос: они образуют иерархию?
Такого ограничения нет. Объекты могут ссылаться друг на друга как им вздумается, хоть циклически хоровод водить. Запутанные связи между ними распутываются автоматически сборщиком мусора.
