Автор Тема: Oberon-07/11: Замечания по результатам использования.  (Прочитано 1104 раз)

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3009
    • Просмотр профиля
Как Вы думаете, в каком случае проще упустить нужную зачистку(и не только)?

Допустим у нас O7. "Зачистки" не так актуальны, потому что 95% зачисток берет на себя GC. В 5% я согласен написать вложенный IF. Но GOTO лучше :) (можно с контролем, что только в конец процедуры, как раз для зачисток).

Дык может сразу лучше finally как в жабе? Т.е. секцию в процедуре которая выполняется всегда при выходе из процедуры.
Y = λf.(λx.f (x x)) (λx.f (x x))

vlad

  • Hero Member
  • *****
  • Сообщений: 1388
    • Просмотр профиля
Дык может сразу лучше finally как в жабе? Т.е. секцию в процедуре которая выполняется всегда при выходе из процедуры.

Да, finally лучше. Но если не трогать O7 совсем, то я все равно считаю, что множествнный RETURN решал бы больше проблем, чем создавал. Вирт его выпили скорее из желания по максимуму нагрузить грамматику, чтоб компилятор проще был.

kkkk

  • Full Member
  • ***
  • Сообщений: 133
    • Просмотр профиля
Допустим у нас O7. "Зачистки" не так актуальны, потому что 95% зачисток берет на себя GC. В 5% я согласен написать вложенный IF. Но GOTO лучше :) (можно с контролем, что только в конец процедуры, как раз для зачисток).
В вашем предложении выбор ложится на программиста, а это открывает путь для ошибок. Специфика применения такова, что если из 5% случаев найдётся 1% случаев, где будет принято неправильное решение, потому что программист скорее всего будет действовать аналогично 95% случаям, то именно эти "невероятные" случаи и будут использованы злоумышленниками.

Естественно, такими особенностями всё не ограничивается, как я уже писал, это лишь часть большой картины.
Возьмём, казалось бы, совсем другую область - критичное к надёжности ПО для встраиваемой электроники, например, автомобильной. И что же мы видим в общепризнанном документе, регламентирующем разработку на Си в этой области - MISRA C:
Цитировать
Rule 14.4 (required):    The goto statement shall not be used.
Rule 14.5 (required):    The continue statement shall not be used.
Rule 14.6 (required):    For any iteration statement there shall be at most one break statement used for loop termination.
Rule 14.7 (required):    A function shall have a single point of exit at the end of the function.
Ни одного advisory, сплошные required.

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 507
    • Просмотр профиля
Это связано с архитектурой x86. Там для сдвигов влево и вправо используются разные команды. При этом, величина сдвига помещается в регистр cl (8 бит), но процессор учитывает только младшие 5 бит. Т. е. величина сдвига всегда в диапазоне 0..31. Не знаю как в ARM, но в реализации Astrobe тоже есть LSR.
Так это можно решить на этапе трансляции. При чтении второго параметра проверить его на знак и в зависимости от знака подставить правильную команду процессора. А в языке программирования будет только одна предопределённая процедура.
Другое дело, что Left Shift на -3 позиции заставляет мозг больше напрягаться...

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3009
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #19 : Декабрь 02, 2016, 05:17:03 pm »
Да, еще вопрос к akron1: где взять актуальную версию компилятора?
Y = λf.(λx.f (x x)) (λx.f (x x))

trurl

  • Full Member
  • ***
  • Сообщений: 131
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #20 : Декабрь 02, 2016, 06:38:10 pm »
Другое дело, что Left Shift на -3 позиции заставляет мозг больше напрягаться...
Это да. Наверное поэтому в Обероне Shift был без указания направления.
Но ведь аргументом может быть и переменная. И все равно ситуацию с LSH(x, -3) придется как-то разруливать.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1949
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #21 : Декабрь 02, 2016, 10:15:15 pm »
Да, еще вопрос к akron1: где взять актуальную версию компилятора?
Вроде вот последняя версия: http://board.kolibrios.org/viewtopic.php?f=33&t=2443&sid=06ed798bbd09a775c48ce781636a1776&start=30#p66481
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3009
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #22 : Декабрь 02, 2016, 10:29:01 pm »
Да, еще вопрос к akron1: где взять актуальную версию компилятора?
Вроде вот последняя версия: http://board.kolibrios.org/viewtopic.php?f=33&t=2443&sid=06ed798bbd09a775c48ce781636a1776&start=30#p66481
Хм. А собирать его чем? В архиве предположительно только исполняемый файл для калибри. А я эльфов хочу...
Y = λf.(λx.f (x x)) (λx.f (x x))

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1949
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #23 : Декабрь 02, 2016, 10:51:48 pm »
Хм. А собирать его чем? В архиве предположительно только исполняемый файл для калибри. А я эльфов хочу...
Ну может предпоследней версией? ))
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3009
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #24 : Декабрь 02, 2016, 11:35:53 pm »
Давно уже можно генерить для Linux, в инструкции написано. Только без библиотек это неудобно. И зачем тестировать на производительность игрушечный компилятор?
Теперь осознал и отвечу: специфика этой задачки такова, что она реально очень похожа на реальные задачи. Т.е. на задачи, где все упирается в IO и продуманность алгоритмов. Твой компилятор не имеет особого смысла тестировать на передыдущей задаче (где мы сортировали пузырьком), но вот на этой - имеет смысл.

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

И также хочется сравнить этот подход (когда все пишем сами) с подходом когда есть язык чуть посложнее, поудобней, считается что компилятор стабилен и писали его вполне профессиональные люди под коммерческие задачи, т.е. с ББ.

Решение базирующееся на твоем компиляторе/языке теоретически может даже выиграть первый раунд по производительности, просто за счет алгоритмов и отсутствия лишних прослоек между программой и системой.
Y = λf.(λx.f (x x)) (λx.f (x x))

akron1

  • Jr. Member
  • **
  • Сообщений: 76
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #25 : Декабрь 03, 2016, 01:40:00 am »
Да, компилятор переехал на KolibriOS. Игрушечная ОС, игрушечный ЯВУ, игрушечный компилятор ). К тому же, там нет никаких IDE/отладчиков для ЯВУ, и в таких условиях проявляются преимущества оберона -- неплохая приспособленность для разработки в блокноте ). Актуальная версия в SVN
http://websvn.kolibrios.org/listing.php?repname=Kolibri+OS&path=%2Fprograms%2Fdevelop%2Foberon07%2F. Возможность кросс-компиляции никуда не делась и компилятор можно собрать из-под любой из трех ОС под любую другую. Но библиотеки теперь только для Колибри, для Windows/Linux осталось только то, что нужно самому компилятору.

Для Linux, в модуле /lib/linux32/API.ob07 есть процедурные переменные для использования системных библиотек
  dlopen*   : PROCEDURE [cdecl] (filename, flag: INTEGER): INTEGER;
  dlsym*   : PROCEDURE [cdecl] (handle, symbol: INTEGER): INTEGER;
и там же можно увидеть, как они используются. Также, есть привязки к некоторым другим системным функциям.

Аналогично, для Windows, \lib\Windows32\API.ob07:
  GetProcAddress*: PROCEDURE [winapi] (hModule, name: INTEGER): INTEGER;
  LoadLibraryA*: PROCEDURE [winapi] (name: INTEGER): INTEGER;

В отличие от Windows и KolibriOS, я не использовал компилятор для практической разработки под Linux. Не знаю, какие там могут быть проблемы, кроме отсутствия библиотек.

Я прикрепил архив, добавил туда бинарники для Windows и Linux, а также файл test.ob07 -- пример консольного вывода для Linux.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3009
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #26 : Декабрь 03, 2016, 01:44:09 am »
Сначала, надо уяснить, что Oberon-07, это язык, предназначенный для быстрой реализации с минимальными затратами и сравнительно эффективного применения в случае простейшей реализации. В связи с этим, все разговоры об умных компиляторах, современных средствах отладки, шаблонах, замыканиях и т. д. лишены смысла. Многие недостатки языка либо упрощают реализацию, либо упрощают отладку в условиях, когда есть только голый компилятор без каких-либо инструментов.
Полностью согласен. Ещё нюанс - до кучи оно еще оптимизировано под то, чтобы писать в одиночку и без IDE. Собственно как Вирт и работает над системой Оберон. В этом плане язык весьма неплохо продуман и довольно удобен.

- ран-тайм проверки (индексы, указатели). Замедляют и так небыстрые программы. Но оказывают неоценимую помощь, позволяют быстро выявить такие ошибки, которые бывает очень трудно найти без пошагового отладчика и прочих средств. Вряд ли я хоть что-нибудь написал бы на O7 без них. Конечно, люди разные, есть и такие, которые могут кодировать сразу без ошибок на любом языке, но я к таким не отношусь.
Это всё же не часть языка, в сообщении о языке про это ничего не сказано. Это часть Оберона как операционки. Ну и, бывает полезно иметь возможность их отключать.

- сильная типизация. Тоже отлавливает очень много ошибок. И да, упрощает реализацию ).
Согласен.

- единственный выход из процедуры, отсутствие прерываний циклов. Спорная фича. Затрудняет кодинг, увеличивает размер и снижает эффективность кода, немного упрощает отладку.
Идея визуализации потока управления через "отступы". Это работает не очень хорошо на таком уровне, мягко говоря.

- обязательная квалификация идентификаторов. На первый взгляд, избыточно. Раздувает и без того не очень компактный оберон-код. Но вот, как-то мне надо было просмотреть одну программу на паскале, так я задолбался искать процедуры по всем модулям. Конечно, эту проблему легко решает IDE, но ведь я говорю о простейшей реализации...
С одной стороны полезная штука, с другой стороны, можно было сделать более человечески - разрешить использовать идентификаторы без квалификации если они в импортах были явным образом перечислены. Т.е. что-то вроде IMPORT (function1, typeT, somthingElse) from MyModule, MyModule; -- тут можно без квалификации будет использовать function1, typeT, somethingElse а все остальное из модуля MyModule придется использовать с квалификатором: MyModule.something .

То есть можно было сделать лучше, можно но не обязательно, ибо ресурсы у реализатора ограничены - всё делаем в одно лицо.


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

- Беззнаковое целое. Я ни разу не пожалел о его отсутствии. Конечно, бывают случаи, когда этот тип был бы полезен, но для 32-битной реализации это бывает нечасто. Для 64-бит, ИМХО, вообще "не стОит выделки".
Стоит выделки. См. задачку например. Т.е. на моей практике регулярно попадается что-то такое, что требует именно беззнакового целого. И не из за того, что оно в два раза более емкое чем знаковое. Т.е. востребованность беззнаковых типов сильно зависит от множества задач решаемых человеком. Некоторым программистам наверняка беззнаковые и не потребуются, но если вдруг потребуются, будет неприятно.
Y = λf.(λx.f (x x)) (λx.f (x x))

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3009
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #27 : Декабрь 03, 2016, 01:49:23 am »
Я прикрепил архив, добавил туда бинарники для Windows и Linux, а также файл test.ob07 -- пример консольного вывода для Linux.

Спасибо! Проверил - компилируется 32битный бинарь, запускается. Пока всё хорошо.
Сборщика мусора ведь нет?
Y = λf.(λx.f (x x)) (λx.f (x x))

akron1

  • Jr. Member
  • **
  • Сообщений: 76
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #28 : Декабрь 03, 2016, 02:52:32 am »
Сборщика мусора ведь нет?
:)
С самого начала разработки компилятора, я решил максимально упростить задачу. Я не был уверен, что у меня на это хватит способностей. Поэтому, получилось то, что получилось. Однопоточный сборщик мусора не ахти какая сложная вещь, но он меня не интересует. Многопоточный, напротив слишком сложен, поэтому я от него отказался. Вообще, я решился опубликовать компилятор, только потому, что Rifat каким-то образом умудрился сделать кодогенерацию еще хуже. А раз так, думаю, то и я могу. Хотя сначала, делал только для себя и не собирался это никому показывать.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3009
    • Просмотр профиля
Re: Oberon-07/11: Замечания по результатам использования.
« Ответ #29 : Декабрь 03, 2016, 02:58:53 am »
Сборщика мусора ведь нет?
:)
С самого начала разработки компилятора, я решил максимально упростить задачу. Я не был уверен, что у меня на это хватит способностей. Поэтому, получилось то, что получилось. Однопоточный сборщик мусора не ахти какая сложная вещь, но он меня не интересует. Многопоточный, напротив слишком сложен, поэтому я от него отказался. Вообще, я решился опубликовать компилятор, только потому, что Rifat каким-то образом умудрился сделать кодогенерацию еще хуже. А раз так, думаю, то и я могу. Хотя сначала, делал только для себя и не собирался это никому показывать.
Не, я не к тому что реализация без GC это что-то плохое :-) Я просто уточнил. Есть туча оберонов без GC. И они без GC, полагаю, ровно по той же причине.
Y = λf.(λx.f (x x)) (λx.f (x x))