Oberon space

General Category => Общий раздел => Тема начата: akron1 от Ноябрь 29, 2016, 06:39:03 pm

Название: Oberon-07/11: Замечания по результатам использования.
Отправлено: akron1 от Ноябрь 29, 2016, 06:39:03 pm
Итак, я написал несколько десятков тысяч строк некачественного, но работающего кода на этом языке. Кратко расскажу об этом опыте.

Сначала, надо уяснить, что Oberon-07, это язык, предназначенный для быстрой реализации с минимальными затратами и сравнительно эффективного применения в случае простейшей реализации. В связи с этим, все разговоры об умных компиляторах, современных средствах отладки, шаблонах, замыканиях и т. д. лишены смысла. Многие недостатки языка либо упрощают реализацию, либо упрощают отладку в условиях, когда есть только голый компилятор без каких-либо инструментов.

Перечислю некоторые особенности языка/реализации, которые можно считать недостатками:

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

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

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

- обязательная квалификация идентификаторов. На первый взгляд, избыточно. Раздувает и без того не очень компактный оберон-код. Но вот, как-то мне надо было просмотреть одну программу на паскале, так я задолбался искать процедуры по всем модулям. Конечно, эту проблему легко решает IDE, но ведь я говорю о простейшей реализации...

Операторы:

- CASE. Вероятно, использование этого оператора для проверки типа указателя (как в поздних ревизиях) вполне оправдано. Для проверки целочисленных значений позволяет сделать более эффективный и компактный машкод, чем серия IF. Без ELSE практически бесполезен.

- FOR. Лучше, если бы переменная-счетчик создавалась при входе в цикл и уничтожалась при выходе.

- WHILE ... DO ... ELSIF ... DO. "Цикл Дийкстры" - почти бесполезен, хотя и не мешает. Одно из немногих применений:
PROCEDURE Scroll (value: INTEGER);
BEGIN
  value := 2 * value;
  WHILE value > 0 DO
    Down;
    DEC(value)
  ELSIF value < 0 DO
    Up;
    INC(value)
  END
END Scroll;
Конечно, здесь можно сделать по-другому, но мне показалось, что "цикл Дийкстры" подходит лучше.

Типы:

- SET. Применяется нечасто, но бывает полезен, когда надо упаковать несколько булевских значений в одну переменную, чтобы не раздувать список параметров.
- Беззнаковое целое. Я ни разу не пожалел о его отсутствии. Конечно, бывают случаи, когда этот тип был бы полезен, но для 32-битной реализации это бывает нечасто. Для 64-бит, ИМХО, вообще "не стОит выделки".
- ANYREC, ANYPTR. Лучше бы были.
- Динамические массивы. Без них плохо.
- POINTER TO. Здесь желательно ослабить типизацию, как это сделано в КП.
- Псевдонимы типов. Лучше бы были. В поздних ревизия они есть.

Встроенные процедуры:

- ORD(BOOLEAN): INTEGER. Используется довольно часто, странно, что в AO ее нет.
- BITS(INTEGER): SET. Такой процедуры в O7 нет. Пришлось добавить в дополнение к ORD(SET): INTEGER.
- LSR. Такой процедуры нет, но она однозначно нужна. Тоже добавил в дополнение к LSL.
- LENGTH(ARRAY OF CHAR): INTEGER. Используется часто, лучше, когда она встроена в язык. Тоже добавил.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Ноябрь 29, 2016, 06:45:11 pm
В свете задачки из соседней ветки ( http://oberspace.dyndns.org/index.php/topic,695.0.html ), вопрос - твой компилятор не научился кодогенерить для *nix'ов? Может какой-то еще есть компилятор который уже вменяемо держит язык и умеет компилить консольные *nix приложения?

А то из компиляторов которые умеют генерить нативный x86 или AMD64 *nix бинарь приходится выбирать из XDS, BB и A2. При этом у двух последних имеется некоторый геморрой на тему создания консольного stand alone приложения и автоматизации сборки.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: akron1 от Ноябрь 29, 2016, 07:41:15 pm
Давно уже можно генерить для Linux, в инструкции написано. Только без библиотек это неудобно. И зачем тестировать на производительность игрушечный компилятор?
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Ноябрь 29, 2016, 07:43:50 pm
Давно уже можно генерить для Linux, в инструкции написано. Только без библиотек это неудобно. И зачем тестировать на производительность игрушечный компилятор?
Ну я же описал проблему. И, что-то мне кажется, что узким местом в той задаче будет не производительность сгенерированного кода :-)
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: trurl от Ноябрь 29, 2016, 07:57:59 pm
- LSR. Такой процедуры нет, но она однозначно нужна. Тоже добавил в дополнение к LSL.
А разве нельзя вместо LSR(x, n) использовать LSL(x, -n)?
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: akron1 от Ноябрь 29, 2016, 08:32:36 pm
Это связано с архитектурой x86. Там для сдвигов влево и вправо используются разные команды. При этом, величина сдвига помещается в регистр cl (8 бит), но процессор учитывает только младшие 5 бит. Т. е. величина сдвига всегда в диапазоне 0..31. Не знаю как в ARM, но в реализации Astrobe тоже есть LSR.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: kkkk от Ноябрь 29, 2016, 10:20:14 pm
- единственный выход из процедуры, отсутствие прерываний циклов. Спорная фича. Затрудняет кодинг, увеличивает размер и снижает эффективность кода, немного упрощает отладку.
А вот я склонен считать это сильной стороной. Всегда так пишу вне зависимости от выбранного языка. Если не привыкать к обратному, то и не возникает желания писать неструктурно. В MISRA C есть похожие, но не доведённые до логического конца требования.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: Geniepro от Ноябрь 30, 2016, 05:03:07 am
Итак, я написал несколько десятков тысяч строк некачественного, но работающего кода на этом языке.
Смотрел я исходники твоего fb2-ридера, толком не разглядывал, но выглядит куда лучше, чем у Вирта, так что нормлаьный код, нечего себя принижать )))
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: vlad от Ноябрь 30, 2016, 05:41:13 am
Если не привыкать к обратному, то и не возникает желания писать неструктурно. В MISRA C есть похожие, но не доведённые до логического конца требования.

Во-первых, оно только у труЪ оберонщиков считается "неструктурно", за пределами оберон-сообщества никто не комплексует по поводу множественного RETURN.
Во-вторых, я целый компилятор написал и так и не привык. Будет еще одно расширение в ебероне.
В-третьих, единственный RETURN порождает объективную проблему - увеличивает вложенность кода, что крайне хреново сказывается на читабельности.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: kkkk от Ноябрь 30, 2016, 09:29:23 am
Зачем же Вы с плеча так рубите про труЪ Оберонщиков? Это ценится не только у них, но и, например, у людей, пишущих защищённый код. В таких задачах нередко возникает потребность в зачистке важных данных в уже неиспользуемых переменных https://www.securecoding.cert.org/confluence/display/c/MEM03-C.+Clear+sensitive+information+stored+in+reusable+resources (https://www.securecoding.cert.org/confluence/display/c/MEM03-C.+Clear+sensitive+information+stored+in+reusable+resources). Угадайте, где больше шансов пропустить очистку. Это, конечно, лишь частный случай большой картины, но переубеждать не берусь, я за свободу религий.

Цитировать
Во-вторых, я целый компилятор написал и так и не привык
Вы это серьёзно? А сколько до, во время и после написания транслятора Вы написали кода не так? Привычка подразумевает стабильность и отсутствие предубеждённости, естественно.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: vlad от Ноябрь 30, 2016, 01:08:05 pm
Зачем же Вы с плеча так рубите про труЪ Оберонщиков? Это ценится не только у них, но и, например, у людей, пишущих защищённый код. В таких задачах нередко возникает потребность в зачистке важных данных в уже неиспользуемых переменных https://www.securecoding.cert.org/confluence/display/c/MEM03-C.+Clear+sensitive+information+stored+in+reusable+resources (https://www.securecoding.cert.org/confluence/display/c/MEM03-C.+Clear+sensitive+information+stored+in+reusable+resources). Угадайте, где больше шансов пропустить очистку.

Вы сами читали там по ссылке? :) Там постоянно упоминатеся некий /* Handle error */, а вот что там внутри очень интересно применительно к "структурности". Cудя по коду внутри там или goto (привет линукс-стайл) или какой-нибудь abort (аварийное завершение программы) или return :) Четвертого не дано, потому что оно крэшиться будет сразу после такого if'а :)

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

Картина такая, что люди пытаются избежать многоуровневых if'ов. В разных языках по-разному. В С с помощью goto. В С++ RAII. В джавах/шарпах return/finally. И только в оберонах влолженные if'ы готовый считать чем-то хорошим, лишь бы не множественый return.

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

До компилятора тоже пытался пару недель соблюдать в рамках работы (C++). Убедился что не, херня получается.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: kkkk от Ноябрь 30, 2016, 02:20:58 pm
Вы сами читали там по ссылке? :) Там постоянно упоминатеся некий /* Handle error */, а вот что там внутри очень интересно применительно к "структурности". Cудя по коду внутри там или goto (привет линукс-стайл) или какой-нибудь abort (аварийное завершение программы) или return :) Четвертого не дано, потому что оно крэшиться будет сразу после такого if'а :)
Наверно, нужно было прояснить для чего была ссылка, ведь как говорится в одной из вариаций закона Мерфи, если есть малейшая возможность, что поймут неправильно, то обязательно кто-то поймёт неправильно. А я оставил не просто малейшую возможность, а большущую  ;D и наводящий вопрос не оправдание - не тот случай.
Ссылка была дана для показа реальной, хотя и довольно неочевидной потребности. То, как предлагают её решать на этом ресурсе - это отдельная песня, скажу только, что они составляли свой список правил из раздельного анализа выявленных уязвимостей, целостного решения они не предлагают.
Ну а я повторю заданный ранее наводящий вопрос, может быть в этот раз получится лучше. Как Вы думаете, в каком случае проще упустить нужную зачистку(и не только)?
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: kkkk от Ноябрь 30, 2016, 02:25:20 pm
Картина такая, что люди пытаются избежать многоуровневых if'ов. В разных языках по-разному. В С с помощью goto. В С++ RAII. В джавах/шарпах return/finally. И только в оберонах влолженные if'ы готовый считать чем-то хорошим, лишь бы не множественый return.
А вот это вообще умора. Сначала люди придумывают отступы, чтобы сделать поток управления более наглядным, а затем уничтожают наглядность с помощью неструктурных переходов, и даже считают, что всё в порядке. Если так не нравятся лишние отступы, может просто их не делать :) ?
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: kkkk от Ноябрь 30, 2016, 02:26:59 pm
Цитировать
Во-вторых, я целый компилятор написал и так и не привык
Вы это серьёзно? А сколько до, во время и после написания транслятора Вы написали кода не так? Привычка подразумевает стабильность и отсутствие предубеждённости, естественно.

До компилятора тоже пытался пару недель соблюдать в рамках работы (C++). Убедился что не, херня получается.
Такой богатый опыт заслуживает апплодисментов.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: vlad от Ноябрь 30, 2016, 06:23:19 pm
Как Вы думаете, в каком случае проще упустить нужную зачистку(и не только)?

Допустим у нас O7. "Зачистки" не так актуальны, потому что 95% зачисток берет на себя GC. В 5% я согласен написать вложенный IF. Но GOTO лучше :) (можно с контролем, что только в конец процедуры, как раз для зачисток).
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Ноябрь 30, 2016, 06:25:54 pm
Как Вы думаете, в каком случае проще упустить нужную зачистку(и не только)?

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

Дык может сразу лучше finally как в жабе? Т.е. секцию в процедуре которая выполняется всегда при выходе из процедуры.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: vlad от Ноябрь 30, 2016, 06:50:17 pm
Дык может сразу лучше finally как в жабе? Т.е. секцию в процедуре которая выполняется всегда при выходе из процедуры.

Да, finally лучше. Но если не трогать O7 совсем, то я все равно считаю, что множествнный RETURN решал бы больше проблем, чем создавал. Вирт его выпили скорее из желания по максимуму нагрузить грамматику, чтоб компилятор проще был.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: kkkk от Ноябрь 30, 2016, 07:18:59 pm
Допустим у нас 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.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: Valery Solovey от Ноябрь 30, 2016, 08:57:48 pm
Это связано с архитектурой x86. Там для сдвигов влево и вправо используются разные команды. При этом, величина сдвига помещается в регистр cl (8 бит), но процессор учитывает только младшие 5 бит. Т. е. величина сдвига всегда в диапазоне 0..31. Не знаю как в ARM, но в реализации Astrobe тоже есть LSR.
Так это можно решить на этапе трансляции. При чтении второго параметра проверить его на знак и в зависимости от знака подставить правильную команду процессора. А в языке программирования будет только одна предопределённая процедура.
Другое дело, что Left Shift на -3 позиции заставляет мозг больше напрягаться...
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Декабрь 02, 2016, 05:17:03 pm
Да, еще вопрос к akron1: где взять актуальную версию компилятора?
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: trurl от Декабрь 02, 2016, 06:38:10 pm
Другое дело, что Left Shift на -3 позиции заставляет мозг больше напрягаться...
Это да. Наверное поэтому в Обероне Shift был без указания направления.
Но ведь аргументом может быть и переменная. И все равно ситуацию с LSH(x, -3) придется как-то разруливать.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: Geniepro от Декабрь 02, 2016, 10:15:15 pm
Да, еще вопрос к akron1: где взять актуальную версию компилятора?
Вроде вот последняя версия: http://board.kolibrios.org/viewtopic.php?f=33&t=2443&sid=06ed798bbd09a775c48ce781636a1776&start=30#p66481
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Декабрь 02, 2016, 10:29:01 pm
Да, еще вопрос к akron1: где взять актуальную версию компилятора?
Вроде вот последняя версия: http://board.kolibrios.org/viewtopic.php?f=33&t=2443&sid=06ed798bbd09a775c48ce781636a1776&start=30#p66481
Хм. А собирать его чем? В архиве предположительно только исполняемый файл для калибри. А я эльфов хочу...
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: Geniepro от Декабрь 02, 2016, 10:51:48 pm
Хм. А собирать его чем? В архиве предположительно только исполняемый файл для калибри. А я эльфов хочу...
Ну может предпоследней версией? ))
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Декабрь 02, 2016, 11:35:53 pm
Давно уже можно генерить для Linux, в инструкции написано. Только без библиотек это неудобно. И зачем тестировать на производительность игрушечный компилятор?
Теперь осознал и отвечу: специфика этой задачки такова, что она реально очень похожа на реальные задачи. Т.е. на задачи, где все упирается в IO и продуманность алгоритмов. Твой компилятор не имеет особого смысла тестировать на передыдущей задаче (где мы сортировали пузырьком), но вот на этой - имеет смысл.

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

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

Решение базирующееся на твоем компиляторе/языке теоретически может даже выиграть первый раунд по производительности, просто за счет алгоритмов и отсутствия лишних прослоек между программой и системой.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: akron1 от Декабрь 03, 2016, 01:40:00 am
Да, компилятор переехал на KolibriOS. Игрушечная ОС, игрушечный ЯВУ, игрушечный компилятор ). К тому же, там нет никаких IDE/отладчиков для ЯВУ, и в таких условиях проявляются преимущества оберона -- неплохая приспособленность для разработки в блокноте ). Актуальная версия в SVN
http://websvn.kolibrios.org/listing.php?repname=Kolibri+OS&path=%2Fprograms%2Fdevelop%2Foberon07%2F (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.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Декабрь 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-бит, ИМХО, вообще "не стОит выделки".
Стоит выделки. См. задачку например. Т.е. на моей практике регулярно попадается что-то такое, что требует именно беззнакового целого. И не из за того, что оно в два раза более емкое чем знаковое. Т.е. востребованность беззнаковых типов сильно зависит от множества задач решаемых человеком. Некоторым программистам наверняка беззнаковые и не потребуются, но если вдруг потребуются, будет неприятно.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Декабрь 03, 2016, 01:49:23 am
Я прикрепил архив, добавил туда бинарники для Windows и Linux, а также файл test.ob07 -- пример консольного вывода для Linux.

Спасибо! Проверил - компилируется 32битный бинарь, запускается. Пока всё хорошо.
Сборщика мусора ведь нет?
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: akron1 от Декабрь 03, 2016, 02:52:32 am
Сборщика мусора ведь нет?
:)
С самого начала разработки компилятора, я решил максимально упростить задачу. Я не был уверен, что у меня на это хватит способностей. Поэтому, получилось то, что получилось. Однопоточный сборщик мусора не ахти какая сложная вещь, но он меня не интересует. Многопоточный, напротив слишком сложен, поэтому я от него отказался. Вообще, я решился опубликовать компилятор, только потому, что Rifat каким-то образом умудрился сделать кодогенерацию еще хуже. А раз так, думаю, то и я могу. Хотя сначала, делал только для себя и не собирался это никому показывать.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Декабрь 03, 2016, 02:58:53 am
Сборщика мусора ведь нет?
:)
С самого начала разработки компилятора, я решил максимально упростить задачу. Я не был уверен, что у меня на это хватит способностей. Поэтому, получилось то, что получилось. Однопоточный сборщик мусора не ахти какая сложная вещь, но он меня не интересует. Многопоточный, напротив слишком сложен, поэтому я от него отказался. Вообще, я решился опубликовать компилятор, только потому, что Rifat каким-то образом умудрился сделать кодогенерацию еще хуже. А раз так, думаю, то и я могу. Хотя сначала, делал только для себя и не собирался это никому показывать.
Не, я не к тому что реализация без GC это что-то плохое :-) Я просто уточнил. Есть туча оберонов без GC. И они без GC, полагаю, ровно по той же причине.
Название: Re: Oberon-07/11: Замечания по результатам использования.
Отправлено: valexey_u от Декабрь 03, 2016, 03:01:24 am
И да, правильно сделал, что открыл компилятор. По крейней мере он получился таким.. Очень ручным что-ли. Одна фишка безгеморройной кросскомпиляции дорогого стоит.