OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 14:18

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 125 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.
Автор Сообщение
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Понедельник, 05 Ноябрь, 2007 18:26 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
У меня вообще "вызрело" убеждение, что именно выработка адекватных механизмов управления памятью имеет решающее значение для оберонов. :!: :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 00:44 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Борис Рюмшин писал(а):
Одного я не пойму: какое отношение имеет GC Оберона (КП/BlackBox) к ядру ОС?


1) Речь шла о ядре линукса.
2) Использовать в ядре полноценный GC не получится, использование чего-то неполноценного вызывает еще больше вопросов.

Борис Рюмшин писал(а):
Во-первых, Оберон не требует обязательного наличия GC, это частность.


Оберон и так сильно покоцан, если отрезать GC, то он лишится главного достоинства - безопасности.

Борис Рюмшин писал(а):
Во-вторых, в ядре ОС вполне можно использовать GC, но не в стандартных ядрах типа юниксовых


Изначально разговор шел о линуксовом ядре.

Борис Рюмшин писал(а):
И с чего вообще такое мнение, что для написания ОС будет использоваться стандартный рантайм языка? Это нонсенс, ибо ядро (микроядро с серверами и драйверами, скажем) само себе рантайм.


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

Борис Рюмшин писал(а):
Да и к вопросу об Обероне для ядра Линукса: достаточно сделать фронт-энд к GCC. Это сделать можно и достаточно быстро при наличии соответствующих ресурсов и, как скажет info21, насущной для этого необходимости.


Сделать можно, я не спорю. Главный вопрос (и предмет спора) - зачем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 01:40 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
AVC писал(а):
Vlad писал(а):
Возможно это тривиально, но я не представляю как это сделать не дублируя кода. Можно намекнуть - как?

Например, используя метапрограммирование. (Это пока просто идея.)


Т.е., готового, простого и проверенного способа нет. А метапрограммирование в обероне не стандартизировано.

AVC писал(а):
По крайней мере, так работает NEW: компилятор передает кроме переменной-указателя также дескриптор типа.


Компилятор может делать что угодно. Что такое дескриптор типа? Как его получить стандартным для всех имплементаций оберона способом?

Vlad писал(а):
"Да пожалуйста!" (c) :)
В ББ атрибут untagged наследуется, untagged записи не собираются сборщиком мусора.


Сасибо! :) Опять имеем некоторое нестандартное "расширение" языка. Подозреваю, что такие записи не только не собираются GC, но и не имеют того самого волшебного "дескриптора типа" ;)

Для меня вывод вполне очевиден. Язык, похожий на оберон, можно использовать для написания ядреного кода линукса. Но для начала такой язык надо придумать, написать для него компилятор и рантайм. Флаг в руки :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 02:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Такой язык уже есть - Модула-2. Дополнить её расширяемыми RECORD - и вперёд :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 10:01 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Vlad писал(а):
Компилятор может делать что угодно. Что такое дескриптор типа? Как его получить стандартным для всех имплементаций оберона способом?


Дескриптор типа -- дальний родственник таблицы виртуальных функций (vtbl) в Си++. :)
Кроме таблицы методов (в О-2/КП, но не в О-1, где вместо методов для ООП используются обычные процедурные переменные), содержит массив ссылок на базовые типы (для эффективной реализации type test/type guard) и массив смещений полей-указателей в записи (для поддержки прецизной сборки мусора).
Дескрипторы типов -- такая же неотъемлимая часть модуля, как переменные или процедуры. Так что они обязательно доступны как компилятору, так и рантайму.
Каждая (tagged) запись содержит указатель на дескриптор типа (собственно, type tag :) ).

Vlad писал(а):
Сасибо! :) Опять имеем некоторое нестандартное "расширение" языка. Подозреваю, что такие записи не только не собираются GC, но и не имеют того самого волшебного "дескриптора типа" ;)


Совершенно верно.
Т.к. они untagged, то не содержат type tag (указатель на дескриптор типа), и (как правило) рантайм не знает об их внутренней структуре (т.к. не имеет доступа к соответствующему дескриптору типа).
Вместе с тем, AFAIK, большинство реализаций Оберона позволяет использовать (при условии импорта SYSTEM) untagged записи (для совместимости с окружением, написанном на Си, и, возможно, для реализации низкоуровневых деталей рантайма).

Цитата:
Для меня вывод вполне очевиден. Язык, похожий на оберон, можно использовать для написания ядреного кода линукса. Но для начала такой язык надо придумать, написать для него компилятор и рантайм. Флаг в руки :)


IMHO, Илья Ермаков прав: такой язык может быть чем-то средним между Обероном и Модулой-2.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 11:04 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Vlad писал(а):
Потому что, например, C позволяет использовать стандартный рантайм. А для оберона придется придумывать специализированный. А это дополнительные расходы на разработку.

А какой у Си стандартный рантайм? :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 17:53 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
AVC писал(а):
Vlad писал(а):
Потому что, например, C позволяет использовать стандартный рантайм. А для оберона придется придумывать специализированный. А это дополнительные расходы на разработку.

А какой у Си стандартный рантайм? :)


Тот, который описан в стандарте ;) Хотя, конечно, я погорячился, все не так просто. Но вот точечно отстрелить/подменить нужный функционал рантайма намного проще. Тот же malloc в C - это обычная функция, написать ее аналог можно используя стандартные языковые средства, для этого не нужны нестандартные расширения языка или специфические знания о компиляторе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 18:39 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Vlad писал(а):
Борис Рюмшин писал(а):
Одного я не пойму: какое отношение имеет GC Оберона (КП/BlackBox) к ядру ОС?

1) Речь шла о ядре линукса.
2) Использовать в ядре полноценный GC не получится, использование чего-то неполноценного вызывает еще больше вопросов.

В ядре Линукса GC не нужен, это очевидно и спорить тут не о чем. А вот сам Оберон пригодился бы - для внесения ясности в код :)

Ещё раз - если ядро ОС (не юникс ядро) спроектировано для работы с GC, то там всё будет нормально.

И ещё раз, для того, что бы писать компоненты ядра Линукс на Обероне нужен лишь фронтэнд к GCC. Тогда понятие "модуль ядра" может принять несколько другой смысл. :mrgreen:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 20:57 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Борис Рюмшин писал(а):
В ядре Линукса GC не нужен, это очевидно и спорить тут не о чем. А вот сам Оберон пригодился бы - для внесения ясности в код :)


За счет чего будет большая ясность? Можно по пунктам :) Например, в ядре линукса широко используется goto для обработки ошибок и освобождения ресурсов. goto в обероне нет, что вместо него? Или вот препроцессор - мало сказать, что он плох, что оберон предложит вместо?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 21:00 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Vlad писал(а):
Например, в ядре линукса широко используется goto для обработки ошибок и освобождения ресурсов. goto в обероне нет

Поверьте мне, надёжность ядра серьёзно возрастёт... :mrgreen: :mrgreen: :mrgreen: :mrgreen:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 21:08 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Vlad писал(а):
За счет чего будет большая ясность? Можно по пунктам :) Например, в ядре линукса широко используется goto для обработки ошибок и освобождения ресурсов. goto в обероне нет, что вместо него? Или вот препроцессор - мало сказать, что он плох, что оберон предложит вместо?

Нормальную модульность и механизмы коммутации модулей.
Например, для переключения платформенно-зависимого кода нет ничего глупее, чем использовать #ifdef, когда можно коммутировать реализацию по разъёмам и не провоцировать изменения/перекомпиляцию кода. Ну а про линковку, которая не нужна, вообще не говорю.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 21:13 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Борис Рюмшин писал(а):
Vlad писал(а):
Например, в ядре линукса широко используется goto для обработки ошибок и освобождения ресурсов. goto в обероне нет

Поверьте мне, надёжность ядра серьёзно возрастёт... :mrgreen: :mrgreen: :mrgreen: :mrgreen:


Поверьте мне, только лишь от отсутствия в языке goto, надежность не возрастет.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 21:16 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Нормальную модульность и механизмы коммутации модулей.
Например, для переключения платформенно-зависимого кода нет ничего глупее, чем использовать #ifdef


А препроцессор используется не только для включения/выключения кусков кода.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Вторник, 06 Ноябрь, 2007 23:35 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Ну а про линковку, которая не нужна, вообще не говорю.


Теоретически. Есть сильное подозрение, что чтобы поддержать динамическую загрузку модулей в духе оберона, одного фронтенда к GCC будет мало ;) Ядро придется хорошо переколбасить. Настолько хорошо, что будет проще и правильнее написать новое :) Итак, в голом остатке у нас:
1) Строгая типизация. Хотя для меня по-прежнему не очевидно, не создаст ли она больше проблем, чем решит.
2) Модульность (в привычном понимании, без какой-то динамики)
3) Проверка индексов массивов. Хотя смысла в такой проверке применительно к ядру не сильно много, все равно придется падать, полезно только как ранняя диагностики проблем.

Что еще?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Среда, 07 Ноябрь, 2007 00:53 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Vlad писал(а):
3) Проверка индексов массивов. Хотя смысла в такой проверке применительно к ядру не сильно много, все равно придется падать, полезно только как ранняя диагностики проблем.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Среда, 07 Ноябрь, 2007 01:16 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Vlad писал(а):
Что еще?

А чего еще? :)
И все это на фоне (совершенно беспомощного во всех этих отношениях) Си с его мифическим "стандартным рантаймом".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Среда, 07 Ноябрь, 2007 11:07 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Vlad писал(а):
2) Модульность (в привычном понимании, без какой-то динамики)
Модульность оберона (только в смысле синтаксиса), где придется писать ИмяМодуля.сущность в 10 раз повысит понятность кода, т. к. пропадёт необходимость помнить (искать по докам/исходникам) в каком-же это месте у меня эта функция/переменная/тип определены.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Четверг, 08 Ноябрь, 2007 11:19 

Зарегистрирован: Вторник, 04 Июль, 2006 13:04
Сообщения: 88
Откуда: Novosibirsk
Vlad писал(а):
Ага. Можно. Только не на обероне ;) О чем и речь. Нечего оберону с его GC делать в ядреном коде. И убогость существующих обероновских ОС только подтверждает сию объективную реальность.
P.S. Напишите Линусу о желании написать что-то ядреное на обероне, он человек прямолинейный, сразу скажет куда пойти :) Или почитайте его претензии к C++, как возможного языка для написания GIT (а это всего лишь VCS, не OC).


Мда давно не заглядывал а тут флейм вовсю кыпыт))

2Vlad. Не надо заниматься бесполезными спорами))
Типизированный Оберон безусловно не способен удобно выразить СТАРУЮ
низкоуровневую архитектуру системы с НЕТИПИЗИРОВАННОЙ памятью.
Дык это наоборот замечательно, он для того и был задуман!))
И уж всяко это не является проблемой))
Просто Оберон был предназначен с самого начала для выражения другой,
ТИПИЗИРОВАННОЙ архитектуры памяти которая может делать все то-же самое
что и старая и при этом более высокоуровнева.
System3 и AOS не менее реальны чем Linux. Просто - другие.
И приложения портировать поэтому трудно, нужно перепроектировать.
Линукс же ничем не отличается от того что было до него и поэтому
в него так много старого мусора портировано.
Это не значит что Линукс - достижение. Наоборот.

У Вас проблема наподобие - как запрячь лошадь в автомобиль))

Если Вам нужна интеграция со старыми Си-системами,
если Вам нужен лишь ЯЗЫК, используйте Модулу-2))
Она приемлемо интегрируется с Си.

Оберон-системы же (не языки, а АРХИТЕКТУРЫ СИСТЕМ) как раз и
строились как попытка выяснить что будет если отказаться от
некоторых старых принципов и сделать ВСЕ ИНАЧЕ.

Перепроектируйте то что вы хотели выразить. Без нетипизированной
памяти. И НЕ ИСПОЛЬЗУЯ неявно никаких предварительных условий на
ФИЗИЧЕСКОЕ РАСПОЛОЖЕНИЕ ДАННЫХ В ПАМЯТИ. Работайте с логической структурой.

ЗЫ. С личным менеджером памяти все просто и на Обероне.
И не писали этого тут лишь потому что всем влом))
А все отличие - в том что память должна быть типизированной.
Желательно - жесткий массив структур. Но если хочется можно
и на части порезать вдоль. Тогда число массивов будет не более
числа всех используемых элементарных типов. Байты, целые, ....
Но и проблемы появятся как и с указателями почти.
Любую программу можно переписать в такой манере
заменив указатели на индекс в нужном массиве. Массив из структур
заменить на структуру из массивов. Еще сто лет назад так делали в
Фортране)). И списки и все прочее)) Да, это наверно займет больше памяти.
Так же как struct обычно больше занимает чем union. Ну и что?))
Да, это будет по безопасности нечто среднее между типизированным
статическим массивом структур и полиморфной динамической памятью.
Дык это плата за динамичность и гибкость которую Вы так требуете))

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

ЗЗЫ. Линус не авторитет, как программист он весьма стандартен))
Просто ему повезло, у него было свободное оплаченное институтом
время для разработки))
Вот что верно так это то что у него неплохие организационные
способности и что его юниксоиды распиарили)) в целом он похож на Билла))

...Опенсоурс программы разрабатываются не бесплатно а за счет
организаций которые платят деньги программистам за другую работу))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Четверг, 08 Ноябрь, 2007 17:28 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
CheshireCat писал(а):
У Вас проблема наподобие - как запрячь лошадь в автомобиль))


У меня как раз нет такой проблемы, мне обероновского фронтенда к gcc, чтобы писать модули ядра, не надо ;)

CheshireCat писал(а):
Оберон-системы же (не языки, а АРХИТЕКТУРЫ СИСТЕМ) как раз и
строились как попытка выяснить что будет если отказаться от
некоторых старых принципов и сделать ВСЕ ИНАЧЕ.


Если сделать все иначе, то все будет иначе :) На базе какого языка (языков) и какой архитектуры будет основано следующие поколения массовых операционок я судить не берусь. Хотя сильно сомневаюсь, что это будет C в его текущем состоянии. Лично мне импонируют функциональные языки :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Linux+BlackBox=?
СообщениеДобавлено: Четверг, 08 Ноябрь, 2007 19:20 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
CheshireCat писал(а):
2Vlad. Не надо заниматься бесполезными спорами))
Типизированный Оберон безусловно не способен удобно выразить СТАРУЮ
низкоуровневую архитектуру системы с НЕТИПИЗИРОВАННОЙ памятью.

Вопрос именно в том, как писать на Обероне код, управляющий нетипизированной памятью (увы, фон Нейман не дал нам другой :) ).
Речь идет о ядре ОС и управлении динамической памятью.
В том и проблема, что сам менеджер динамической памяти не может быть (целиком) написан на безопасном языке. Ведь его задача в том и состоит (немного упрощенно), что он превращает нетипизированную память в типизированную и обратно.
Т.е. сам налево и направо нарушает безопасность типов. :)
Вот Vlad и спрашивает: как, мол, вы станете выкручиваться с вашим строго типизированным Обероном?
С подтекстом: ха-ха-ха-ха! :)
На мой взгляд, ответ простой: запрем менеджер памяти в низкоуровневом модуле и используем SYSTEM.
А что касается синтаксической стороны вопроса, то не вижу, чем
Код:
int n;
float x;
...
x = * (float *) &n;
лучше, чем
Код:
IMPORT S := SYSTEM;
...
VAR n: INTEGER;
  x: SHORTREAL;
...
x := S.VAL(SHORTREAL, n);
Скорее, наоборот. :D


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 125 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB