Oberon-07M

[Geniepro]

Компилятор TinyC, кстати, забавно оптимизировал эту функцию:

Код: [Выделить]

#define WHILE     for(;;) if (
#define DO        ) {
#define ELSIF     ; } else if (
#define WEND      ; } else break

int gcd(int x, int y)
{
    WHILE x > y DO x = x - y
    ELSIF x < y DO y = y - x
    WEND;
    return x;
}декомпиляция выдала такое:

Код: [Выделить]

int __cdecl sub_401070(int a1, int a2)
{
  while ( 1 )
  {
    while ( a1 > a2 )
      a1 -= a2;
    if ( a1 >= a2 )
      break;
    a2 -= a1;
  }
  return a1;
}Вполне вменяемо. Хотя "if ( a1 >= a2 ) break;" немного смущает.
Вот так было бы лучше:

Код: [Выделить]

int gcd(int x, int y)
{
    do
    {
        while (x > y) x -= y;
        while (x < y) y -= x;
    } while (x != y);
    return x;
}

[igor]

Новые компиляторы по-хорошему нужно прогонять на множестве тестов, специально разработанных для проверки компилятора на соответствие спецификации.
Мне неизвестно есть ли такой набор тестов для Оберон-07. Хорошо бы найти.  
Разработка такого набора тестов - сама по себе нетривиальная задача. Тесты должны обеспечивать полноту проверки (по возможности, конечно).

Rifat, интересно как Вы решали эту проблему? Или тестирование Вашего компилятора пока ещё не проводилось?

[Geniepro]

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

Тестирование доказывает лишь наличие ошибок.
Во французском университете INRIA разработали верифицированный компилятор подмножества Си для PowerPC -- это куда надёжнее, чем просто тестирование на наборе тестов...

[Rifat]

Проблему с циклом Дейкстры решил. Выложил новую версию на сайт.

Насчет тестирования, в процессе работы, я создавал тесты для себя на которых тестировал. Согласен, чтобы было бы хорошо иметь набор эталонных тестов и прогонять на них. Может со временем такой набор тестов появится.

[igor]

Тестирование доказывает лишь наличие ошибок.

Да, конечно. Успешное прохождение всех тестов не гарантирует отсутствие ошибок.

[Geniepro]

3) Вот такой вариант тоже падает на ассерте:

Код: [Выделить]

  PROCEDURE GCDrec(x, y: INTEGER) : INTEGER;
    VAR
      result : INTEGER;
  BEGIN
    IF    x > y THEN result := GCDrec(x-y,  y )
    ELSIF x < y THEN result := GCDrec( x,  y-x)
    ELSE             result := x
    END;

    ASSERT(x = y);

    RETURN result
  END GCDrec;Такое впечатление, что что-то не то с операциями сравнения...

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

[Rifat]

1) Компилятор не ругается на использование неинициализированных переменных.
Это затрудняет отладку программ.

Вообще-то это не является ошибкой с точки зрения компилятора. Согласен, что было бы хорошо выдавать warning, при этом. По сути, этим должен заниматься статический анализатор, который будет статически искать ошибки.
Для C++, существует статический анализатор Lint, который анализирует около 1000 разных ошибочных ситуаций и выдает предупреждения. Было бы хорошо, если кто-нибудь дал ссылку на книгу или сайт, где описывается как можно сделать статический анализатор. Насчет данного конкретного случая, можно просто решить, но затем может появиться другая ситуация, которую тоже надо будет отлавливать, поэтому я хочу решить эту проблему как можно в более общем случае, как это сделано в программе Lint.

[valexey]

В clang (фронтенде для c/c++/objc llvm) тоже есть статический анализатор кода. Все доступно в исходниках под MIT/BSD лицензией. Можно посмотреть.

[Rifat]

Исходники разбирать сложнее, чем прочитать толковую книгу или статью, где это описано.

[valexey]

Да, кстати, clang умеет дампить полный AST в виде xml, что дюже удобно для написания тулзей для анализа кода. Если бы новый Оберон-07М компилятор умел бы нечто подобное, было бы очень здорово, ну и кто-нибудь мог бы написать тулзу (или несколько тулзов) для анализа кода и выявления ошибок потенциальных.

[Rifat]

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

[valexey]

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

Не понял. Дерево разбора однозначно определяется грамматикой языка и даденым исходником. Я слабо себе представляю как можно выдать в виде xml AST не удобный для кого-нибудь. Посмотри как сдампленый AST выглядит у clang'a.

[Rifat]

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

[valexey]

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

Гм. А можно пример?

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

Насколько я знаю, эти дампы делают в первую очередь для того, чтобы иметь больше возможностей отладки компилятора. Чтобы видеть что у него унутре происходит на каждом из этапов. Скажем в gcc подобный дамп именно для этих целей используется в первую очередь.

[igor]

И всё-таки хотелось бы задать парочку "интимных" вопросов 
Например, какое внутреннее промежуточное представление Вы используете? Или Вы транслируете дерево разбора напрямую сразу в машинный код? Вообще, есть какие-нибудь особенности в реализации компилятора, или всё по науке? 
Да, и про оптимизацию пару слов, пожалуйста.