Здравствуйте, Cyberax, Вы писали:
C> кстати, а в Oberon'е есть volatile?
Нету.
Если Вам так интересна многопоточность, то есть специально придуманный для нее Оберон под названием Active Oberon. Там объекты активные, то есть объект = поток.
Здравствуйте, Cyberax, Вы писали:
C>Да какой он, нафиг, системный? Он же не умеет работать без GC и C>runtime-системы. Он такой же системный как и Java.
Просто GC+runtime реализуются непосредственно поверх железа, а уже все остальное (включая операционку) пишется на языке высокого уровня. Например, именно так и было сделано в операционке Aos BlueBottle
Кроме того для специальных случаев встроенных систем — тех где динамическая память отсутсвует в принципе, можно использовать обрезанный Оберон без инструкции NEW и без динамической загрузки модулей. http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm#D
За исключением полностью слинкованных приложений, в которых при исполнения не нужно загружать никакие модули, для модулей требуется динамический загрузчик [linking loader]. Встроенные системы являются важными примерами приложений, которые могут быть полностью слинкованы.
Сергей Губанов пишет:
> Кё> А почему тогда не C++? > А потому что: > 1) Полное исчерпывающее описание Оберона занимает 16-30 страниц (в > зависимости от шрифта), а полное исчерпывающее описание С++ занимает > несколько сотен страниц. Проблема обучения.
Не надо народ смешить. Спека "системного" языка занимать 30 страниц не
может.
Где в спеке Оберона описывается взаимодействие с нативным кодом, способы
передачи параметров, расположения структур в памяти, обработку машинных
исключений? Ни за что не поверю, что все вошло в 16 страниц.
> 2) Сколько ресурсов надо затратить чтобы написать новый правильно > работающий компилятор С++ под новый тип чипа просто не сопоставимо с > той же работой для Оберона. В ETH портирование Оберона на новый тип > чипа делают студенты за месяц. >
Берем GCC и добавляем туда поддержку еще одного процессора. Делается
элементарно — сам разговаривал с человеком, который это сделал за пару
недель. Для GCC просто нужно описать систему команд процессора, ну и
портировать runtime (если нужно).
> 3) Сопровождение кода на С++ эффективно может делать только автор > этого кода, любой другой программист лучше заново по своему напишет > чем разбереться с уже написанным. >
Ой, ну конечно. Я спокойно читаю код на С++, если конечно в нем не
используется черная магия в виде многоуровневых шаблонов. Мои коллеги
тоже что-то не испытывают проблем с чтением C/С++.
> 4) С++ — unsafe, Оберон — safe (работа с адресной арифметикой, если > таковая необходима, в Обероне осуществляется через внешние библиотеки).
tarkil пишет:
> C>Системный язык — это С, с натяжкой, С++. > А почему С++ — с натяжкой?
Слишком высокоуровневый для системного программирования в некоторых
случаях (RTTI, исключения). Хотя достоинство С++ в том, что
высокоуровневые фичи можно и не использовать.
Сергей Губанов пишет:
> C> кстати, а в Oberon'е есть volatile? > Нету. > Если Вам так интересна многопоточность, то есть специально придуманный > для нее Оберон под названием Active Oberon. Там объекты активные, то > есть объект = поток.
В качестве эксперимента — пойдет. Для практики нафиг не нужен — даже не
сравним с Erlang'ом.
> Операционка написанная на нем тут: http://bluebottle.ethz.ch/
Чего-то маловато в ней функциональности...
> Так же есть дальний родственник Оберона — Zonnon это переосмысление > Active Oberon for .NET http://www.zonnon.ethz.ch/
Приложение D: Обязательные требования к среде выполнения
Определение Компонентного Паскаля опирается на три фундаментальных предположения.
1) Во время исполнения программ доступна информация, позволяющая проверять динамический тип объекта. Это нужно для реализации проверок типов и охраны типов.
2) Отсутствует процедура DISPOSE <освобождение памяти под более не используемые объекты>. Память <занимаемая объектом> не может быть освобождена по явной инструкции программиста, поскольку это создало бы проблемы безопасности, связанные с потерей памяти [memory leaks] <память, занимаемая объектами, недоступными ни через какие указатели, которую программист забыл освободить> и с висячими указателями [dangling pointers] <доступные указатели, продолжающие указывать на области памяти, по ошибке преждевременно освобожденные>. За исключением таких встроенных систем, где не используется динамическое управление памятью, или где ее можно разместить только однажды и никогда не нужно освобождать, требуется автоматический сбор мусора.
3) Модули и по крайней мере их экспортированные процедуры (команды) и экспортированные типы должны быть доступны динамически. Если необходимо, это может вызывать загрузку модулей. Программный интерфейс, используемый для загрузки модулей или для доступа к указанной мета-информации, не определяется языком, но компилятор должен сохранять эту информацию при генерации кода. За исключением полностью слинкованных приложений, в которых при исполнения не нужно загружать никакие модули, для модулей требуется динамический загрузчик [linking loader]. Встроенные системы являются важными примерами приложений, которые могут быть полностью слинкованы.
Реализация, которая не удовлетворяет этим требованиям к компилятору и среде выполнения, не считается удовлетворяющей определению Компонентного Паскаля.
Сергей Губанов пишет:
> C>Да какой он, нафиг, системный? Он же не умеет работать без GC и > C>runtime-системы. Он такой же системный как и Java. > Просто GC+runtime реализуются непосредственно поверх железа
То есть железо должно быть спроектировано специально для Oberon'а?
Закатайте губы обратно — такого железа не будет.
> а уже все остальное (включая операционку) пишется на языке высокого > уровня. Например, именно так и было сделано в операционке Aos > BlueBottle <http://bluebottle.ethz.ch/>
Здравствуйте, Cyberax, Вы писали:
C>Слишком высокоуровневый для системного программирования в некоторых C>случаях (RTTI, исключения). Хотя достоинство С++ в том, что C>высокоуровневые фичи можно и не использовать.
Вот-вот, и я к тому же. Страуструп одной из задач ставил, чтоб C++ мог использоваться для всех задач C с неменьшей эффективность. Эти фичи не повязаны жёстко друг на друга, можно от чего-то отказаться.
А чего, на мой взгляд, не хватает в компиляторах, так это гибко настроить ограничения на использование разных возможностей языка. Скажем, запретить для системного проекта виртуальные функции. Или для прикладного проекта — арифметику с указателями...
Здравствуйте, Cyberax, Вы писали:
C>То есть железо должно быть спроектировано специально для Oberon'а? C>Закатайте губы обратно — такого железа не будет.
...Бортовой компьютер (получивший, кстати, имя OLGA = Oberon Language Goes Airborne) оказался настолько компактным благодаря компактности и эффективности получившихся программ (использовалось подмножество языка Оберон), что вес машины удалось резко снизить по сравнению с предыдущими версиями конструкции — всего до 15 кг. (Потомки компьютера OLGA используются в компании weControl.)
Здравствуйте, Cyberax, Вы писали:
C>То есть железо должно быть спроектировано специально для Oberon'а? C>Закатайте губы обратно — такого железа не будет.
Сергей Губанов пишет:
> C>То есть железо должно быть спроектировано специально для Oberon'а? > C>Закатайте губы обратно — такого железа не будет. > Это для Си++ такого железа не было и не будет
А чего у меня передо мной стоит такое с монитором? Под С++ НЕ НУЖНО
проектировать железо.
Сергей Губанов пишет:
> C>То есть железо должно быть спроектировано специально для Oberon'а? > C>Закатайте губы обратно — такого железа не будет. > Ага щассс...
И где оно сейчас? Я же не зря написал "не будет". Всякие Lisp-машины
тоже благополучно сдохли...
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Cyberax, Вы писали:
C>>То есть железо должно быть спроектировано специально для Oberon'а? C>>Закатайте губы обратно — такого железа не будет.
СГ>Ага щассс...
<skipped>
Да, ужасно распространённые системы, люди на них миллиарды долларов делают
Здравствуйте, Cyberax, Вы писали:
C>Сергей Губанов пишет:
>> C>То есть железо должно быть спроектировано специально для Oberon'а? >> C>Закатайте губы обратно — такого железа не будет. >> Ага щассс...
C>И где оно сейчас? Я же не зря написал "не будет". Всякие Lisp-машины C>тоже благополучно сдохли...
А, кстати, ничего не можешь сказать, линков кинуть как раз по лиспмашинам? Они совсем сдохли пару десятков лет назад или всё-же есть живые экземпляры?
Курилка пишет:
>>> C>То есть железо должно быть спроектировано специально для Oberon'а? >>> C>Закатайте губы обратно — такого железа не будет. >>> Ага щассс... > C>И где оно сейчас? Я же не зря написал "не будет". Всякие Lisp-машины > C>тоже благополучно сдохли... > А, кстати, ничего не можешь сказать, линков кинуть как раз по > лиспмашинам? Они совсем сдохли пару десятков лет назад или всё-же есть > живые экземпляры?
Ничего не умирает полностью в мире компьютеров — я даже не один
работающий комп с перофокартами видел. Есть какие-то отдельные
Лисп-процессоры — развитие старых образцов, но про новые разработки
что-то не слышно.
Джентельмены, а зачем машины для языка? Мое мнение, что это язык должен оптимально портироваться. И если процессор может выполнять достаточно высокоуровневые команды, то тогда именно язык должен портироваться на них (но не наоборот).
С уважением, Gleb.
PS: Я слышал о отдельных процах в mainframe для байт-кода Java(ито мельком), но кто мешает воспользоваться другим языком для портирования под него?
GlebZ пишет:
> PS: Я слышал о отдельных процах в mainframe для байт-кода Java(ито > мельком), но кто мешает воспользоваться другим языком для портирования > под него?
Есть два подхода для аппаратных процессоров:
1. _Некоторые_ команды JVM микрокодом транслировать в непосредственный
код. Получается не особо быстро, зато сложно и дорог.
2. Использовать аппаратную поддержку для ускорения JIT'а и GC. Именно
так и работают сейчас нормальные Java-процы.
C>2. Использовать аппаратную поддержку для ускорения JIT'а и GC. Именно C>так и работают сейчас нормальные Java-процы.
Специально подчеркнул. Уже давно настали времена, когда софтварно большинство вещей делается намного дешевле (и быстрей если брать отношение стоимости и производительности) чем на аппаратном уровне. Это стало понятно, еще когда была бадяга между пентюхом и risk процами. А под эту аппаратную поддержку, наверняка можно и MSIL навернуть. Не так уж они и концептуально различаются.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Курилка, Вы писали:
К>>А какже сказанное тобою тут про встроенные системы и отсутствие потоков? Как это с универсальностью соотносится?
СГ>Так ведь в Си/Си++ многопоточность тоже появляется только через внешние библиотеки.
GlebZ пишет:
> C>2. Использовать *аппаратную поддержку* для ускорения JIT'а и GC. Именно > C>так и работают сейчас нормальные Java-процы. > Специально подчеркнул. Уже давно настали времена, когда софтварно > большинство вещей делается намного дешевле (и быстрей если брать > отношение стоимости и производительности) чем на аппаратном уровне.
Да, но тот же GC с совсем небольшой аппаратной поддержкой можно сделать
ЗНАЧИТЕЛЬНО эффективнее, как и JIT. Требуется ведь не полная их
аппаратная реализация, а просто несколько особых фич.
> Это стало понятно, еще когда была бадяга между пентюхом и risk > процами. А под эту аппаратную поддержку, наверняка можно и MSIL > навернуть. Не так уж они и концептуально различаются.
