мысли об оберонах

[sa_t_an]

Также добавил кнопку для моего ТВ-ПДУ на раз-два

И на это ушло 3 часа? Не.. я не стебаюсь, просто мне интересно как быстро найти что то в 2 миллионах строк исходного кода, может я какими то не правильными редакторами пользовался? Да не в этом дело. Я ж говорю, для меня интересен процесс изучения с минимума, линукс как пример. Ну надоедает ждать все его сборки и замуты. А Колибри ОС на половину непонятен код (да какой там половину), в Обероне понятно процентов 90-95, всё по минимуму, можно напечатать и совместить духовное и естественное допустим в сортире под папироску.

[Mikhail]

Также добавил кнопку для моего ТВ-ПДУ на раз-два

И на это ушло 3 часа? Не.. я не стебаюсь, просто мне интересно как быстро найти что то в 2 миллионах строк исходного кода, может я какими то не правильными редакторами пользовался? Да не в этом дело. Я ж говорю, для меня интересен процесс изучения с минимума, линукс как пример. Ну надоедает ждать все его сборки и замуты. А Колибри ОС на половину непонятен код (да какой там половину), в Обероне понятно процентов 90-95, всё по минимуму, можно напечатать и совместить духовное и естественное допустим в сортире под папироску.

Нужно знать где смотреть, очевидно. А еще неплохо прочитать Танненбаума, хотя бы.

[sa_t_an]

Нужно знать где смотреть, очевидно. А еще неплохо прочитать Танненбаума, хотя бы.

Ага, вот мы и пришли к логическому выводу, что в миллионах строк исходного кода просто так не разобраться. Надо что бы, хотя бы Танненбаум, тыкнул носом для начала, причем на английском или корявом русском после перевода. На это уходит немножко время разработки, месяцы или годы (кто ж их считает то), вот поэтому меня и привлекают маленькие системки, на маленьких компиляторах, но которые удобочитаемы и понимаемы для меня, и не надо дополнительных многотомных мануалов почему. Оберон в этом случае и примеры к нему удовлетворяют мою жажду любопытства на все 100%.
Ну может быть на 98%, потому как DOS заглушка в PE файле всё таки описана в болшинстве мануалов как DOS заглушка и точка, а не как программа под дос, которая выводит на экран некое сообщение!

[Mikhail]

Ага, вот мы и пришли к логическому выводу, что в миллионах строк исходного кода просто так не разобраться. Надо что бы, хотя бы Танненбаум, тыкнул носом для начала, причем на английском или корявом русском после перевода. На это уходит немножко время разработки, месяцы или годы (кто ж их считает то), вот поэтому меня и привлекают маленькие системки, на маленьких компиляторах, но которые удобочитаемы и понимаемы для меня, и не надо дополнительных многотомных мануалов почему. Оберон в этом случае и примеры к нему удовлетворяют мою жажду любопытства на все 100%.
Ну может быть на 98%, потому как DOS заглушка в PE файле всё таки описана в болшинстве мануалов как DOS заглушка и точка, а не как программа под дос, которая выводит на экран некое сообщение!

Эта книжка есть на русском языке. И она не про Линукс, а о проектировании ОС вообще. Там разбирается пример разработки игрушечной ОС, примерно так же как разбирается построение компилятора Оберон в книге Вирта. Ничего сложного, уверяю Вас. И кода тоже немного.

В общем, от простого к сложному, как всегда.

[Mirror]

http://www.oberoncore.ru/wiki/%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F

Интересно, спасибо.

Нужно знать где смотреть, очевидно. А еще неплохо прочитать Танненбаума, хотя бы.

Вообще-то Танненбаум очень ругал Линукс, и как раз за его монолитность (т.е. стремление запихнуть как можно больше функций в одно ядро).

меня и привлекают маленькие системки, на маленьких компиляторах, но которые удобочитаемы и понимаемы для меня

Извините за оффтопик, а что кто думает про Plan 9 from Bell Labs?

[Mikhail]

Вообще-то Танненбаум очень ругал Линукс, и как раз за его монолитность (т.е. стремление запихнуть как можно больше функций в одно ядро).

Ядро Линукс модульное, т.е. с точки зрения читаемости вполне обозримо. Проблема в другом, все находится в одном контексте, поэтому сбой в любой из подсистем (драйвере например) приведет к отказу всего ядра.

[Kemet]

P.S. Давно хотел познакомиться с Обероном, на самом деле. Кто посоветует хороший компилятор Оберона для Линукса, который а) компилируется в нативный код или в Си, б) позволяет легко использовать Сишные библиотеки.

Optimizing Oberon-2 Compiler

Добавлено спустя 8 минут 11 секунд:
холиварить не имеет смысла - тем, кого устраивает ОбжектПаскаль на нём пусть и пишут, никто на него не покушается, тем, кому, в силу специфики решаемых задач, требуется более безопасные и предсказуемые средства, типа Модулы-3 или Оберонов, успешно решают свои задачи используя именно эти средства. Обычно эти области никак не пересекаются. Ну разве что в форумных баталиях.

[debi12345]

И на это ушло 3 часа? Не.. я не стебаюсь, просто мне интересно как быстро найти что то в 2 миллионах строк исходного кода,

Возможно, потому что имею большой уже многолетний опыт Линукса. Сперва ищещь зацепки и константы в (маленьких) хэдер-файлах, затем детали - в обычных.
Иногда приходится пересобирать ядро до 15..20 раз за день. На современных компах траты времени на это незаметны, даже если врубишь почти все опции.

Добавлено спустя 41 минуту 31 секунду:

Проблема в другом, все находится в одном контексте, поэтому сбой в любой из подсистем (драйвере например) приведет к отказу всего ядра

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

ПС: Линус писал как-то что основная причина сбоев ядра - использовнаие низкоуровневого С с его неизбежным ручным упрвленеим всеми операцими памяти - а таковых в чистом С очень много и обязательно что-то упустишь. Как пример на чем нужно писать ядра, он привел Паскаль - с его счтечиками ссылок, легкостью работы со строками разынх кодировок, обработкой исключений... Часть кода можно было бы сделать объектно-ориентировнной без ущерба для производительнсти - DCАLС, как показали здешние тесты, например ничуть не уступает по скрости низкуровневой реализации работы с контпйнерами. Есно уже огромное наработанное ядро линукса на другй язык не перепишень. А вто новые (с нуккля) ядра новых оепрационок - очень даже.

[Mikhail]

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

ПС: Линус писал как-то что основная причина сбоев ядра - использовнаие низкоуровневого С с его неизбежным ручным упрвленеим всеми операцими памяти - а таковых в чистом С очень много и обязательно что-то упустишь. Как пример на чем нужно писать ядра, он привел Паскаль - с его счтечиками ссылок, легкостью работы со строками разынх кодировок, обработкой исключений... Часть кода можно было бы сделать объектно-ориентировнной без ущерба для производительнсти - DCАLС, как показали здешние тесты, например ничуть не уступает по скрости низкуровневой реализации работы с контпйнерами. Есно уже огромное наработанное ядро линукса на другй язык не перепишень. А вто новые (с нуккля) ядра новых оепрационок - очень даже.

Согласен, производительность ниже.

Это одна из причин. В любой программе всегда есть ошибки. Изоляция одной части программы от другой, при прочих равных, увеличивает ее надежность.

[Kemet]

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

Видимо, он просто ничего не знал об Обероне )))
И речь, все-таки, шла о Паскале, а не об Object Pascal'е.

[Mirror]

ПС: Линус писал как-то что основная причина сбоев ядра - использовнаие низкоуровневого С с его неизбежным ручным упрвленеим всеми операцими памяти - а таковых в чистом С очень много и обязательно что-то упустишь. Как пример на чем нужно писать ядра, он привел Паскаль - с его счтечиками ссылок, легкостью работы со строками разынх кодировок, обработкой исключений... Часть кода можно было бы сделать объектно-ориентировнной без ущерба для производительнсти

А можно ссылку? Я ничего похожего нагуглить не могу.

Добавлено спустя 10 минут 32 секунды:

Optimizing Oberon-2 Compiler

Что-то у меня оно не компилируется.

make выдаёт такое:

Код: Выделить всё

gcc -g -O2  -Ilib/src -I./obj -I./lib/obj -c ./lib/src/RT0.c -o ./lib/obj/RT0.o
./lib/src/RT0.c:86:21: error: unknown type name ‘GC_PTR’
./lib/src/RT0.c:86:33: error: unknown type name ‘GC_PTR’
./lib/src/RT0.c: In function ‘RT0__NewObject’:
./lib/src/RT0.c:130:9: error: ‘HandleFinalize’ undeclared (first use in this function)
./lib/src/RT0.c:130:9: note: each undeclared identifier is reported only once for each function it appears in
./lib/src/RT0.c:130:57: error: ‘GC_PTR’ undeclared (first use in this function)
./lib/src/RT0.c:130:65: error: expected expression before ‘)’ token

Наверное, проблема с libgc, будет не лень — попробую разобраться.

[Kemet]

Что-то у меня оно не компилируется.

А чего ты хотел - Линукс же!
У меня под OpenSuse 11 всё компилировалось - из репы ставил gc и gc-devel. Вполне возможно, что с новыми версиями gc оно не взлетит без правок, можно поставить версию 6. Ну или пути смотреть, мэйкфайл лопатить.

Добавлено спустя 1 минуту 2 секунды:
А вообще, configure нашел gc?

[Mirror]

Помогла сборка последней libgc из исходников. До того я пробовал использовать ту libgc, которая в репозитории (у меня Ubuntu 12.04, если что; configure её находил, но что-то шло не так). Вроде работает. Буду ознакамливаться с Обероном. :D

[Mirage]

DCАLС, как показали здешние тесты, например ничуть не уступает по скрости низкуровневой реализации работы с контпйнерами

Что за DCALC? Надеюсь, не Decal имелся в виду?
Да и от ссылки где Линус Паскаль хвалит тоже не отказался бы.
Раз упомянул про счетчики ссылок, то это не старый добрый Паскаль.

[Mikhail]

DCАLС, как показали здешние тесты, например ничуть не уступает по скрости низкуровневой реализации работы с контпйнерами

Что за DCALC? Надеюсь, не Decal имелся в виду?
Да и от ссылки где Линус Паскаль хвалит тоже не отказался бы.
Раз упомянул про счетчики ссылок, то это не старый добрый Паскаль.

Был такой наброс на ЛОРе. Но это не совсем правда.

Под Паскалем тут понимается в том числе и Модула и Оберон и, даже, Ада.