Автор Тема: Oberon-07M  (Прочитано 53181 раз)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Oberon-07M
« Ответ #45 : Март 21, 2011, 07:39:20 pm »
Выложил описание компилятора: http://exaprog.com/userguide.pdf
О! Оперативненько! Заценим.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Oberon-07M
« Ответ #46 : Март 21, 2011, 07:45:40 pm »
2. Differences between Oberon-07M and Oberon-07
...
2) One dimensional arrays are allowed.
По моему, одномерные массивы в Обероне-07 и так были (как и двух, и трех и так далее мерные). Небыло массивов неизвестной на этапе компиляции длины.

Ну и неплохо бы описать что будет при делении на нуль (целочисленно, точкоплавающе), как работать с +inf, -inf, nan значениями для IEEE real'ов. Что будет при выходе за пределы массива. Что будет при арифметическом переполнении (для всех типов).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Oberon-07M
« Ответ #47 : Март 21, 2011, 07:46:04 pm »
2. Differences between Oberon-07M and Oberon-07
...
2) One dimensional arrays are allowed.
По моему, одномерные массивы в Обероне-07 и так были (как и двух, и трех и так далее мерные). Небыло массивов неизвестной на этапе компиляции длины.

Ну и неплохо бы описать что будет при делении на нуль (целочисленно, точкоплавающе), как работать с +inf, -inf, nan значениями для IEEE real'ов. Что будет при выходе за границы массива. Что будет при арифметическом переполнении (для всех типов).
« Последнее редактирование: Март 21, 2011, 08:19:54 pm от valexey »
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Rifat

  • Jr. Member
  • **
  • Сообщений: 62
    • Просмотр профиля
Re:Oberon-07M
« Ответ #48 : Март 21, 2011, 08:00:43 pm »
Да, там в предложении одно слово пропущено. Должно было быть One dimensional dynamic arrays allowed. Сейчас поправлю.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Oberon-07M
« Ответ #49 : Март 21, 2011, 08:18:32 pm »
Еще одним аргументом в пользу динамических массивов было то, что некоторые WinApi функции требуют передачи им указателя на массив, размер которого в общем случае не известен.
А вот это уже да, аргумент. Можно пример такой WinAPI функции? А то на вскидку ничего не припоминается.

Да хоть CreateFile. Путь к файлу может быть больше MAX_PATH. Или там какой-нибудь RegQueryValue может возвращать при "нехватке" буфера размер, который нужен (распространенная практика). Другой вопрос, что можно это все в SYSTEM упрятать... Но в любом случае простой (пусть и SYSTEM) способ получить шмат памяти заданного размера - обязан быть.

P.S. Есть еще более тонкие извращения, не так распространенные в WinAPI, но нормальные для С-интерфейсов: последнее поле структуры - массив нулевой длины, который на самом деле ни разу не нулевой, а вы поняли...

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Oberon-07M
« Ответ #50 : Март 21, 2011, 08:29:31 pm »
P.S. Есть еще более тонкие извращения, не так распространенные в WinAPI, но нормальные для С-интерфейсов: последнее поле структуры - массив нулевой длины, который на самом деле ни разу не нулевой, а вы поняли...
А что мешает тут сделать также? Я ж DIzer'у тут уже все глаза замозолил этим ARRAY 0 OF CHAR :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Rifat

  • Jr. Member
  • **
  • Сообщений: 62
    • Просмотр профиля
Re:Oberon-07M
« Ответ #51 : Март 21, 2011, 08:30:23 pm »
Документ обновил.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Oberon-07M
« Ответ #52 : Март 21, 2011, 08:45:08 pm »
P.S. Есть еще более тонкие извращения, не так распространенные в WinAPI, но нормальные для С-интерфейсов: последнее поле структуры - массив нулевой длины, который на самом деле ни разу не нулевой, а вы поняли...
А что мешает тут сделать также? Я ж DIzer'у тут уже все глаза замозолил этим ARRAY 0 OF CHAR :-)

Не, ARRAY 0 OF CHAR - фигово. Потому что это нифига не CHAR и нифига не ARRAY, а "шмат памяти". Лучше POINTER TO [MEMORY] или еще как, чтобы сразу было видно, что язык здесь кончился и пошел SYSTEM.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Oberon-07M
« Ответ #53 : Март 21, 2011, 08:49:02 pm »
Не, ARRAY 0 OF CHAR - фигово. Потому что это нифига не CHAR и нифига не ARRAY, а "шмат памяти". Лучше POINTER TO [MEMORY] или еще как, чтобы сразу было видно, что язык здесь кончился и пошел SYSTEM.
Чего это? Вполне себе array, просто неизвестного размера (на этапе компиляции). Ты же знаешь зачем это в сях делают? Чтобы структура могла прямо в себе содержать массив любого размера обычно. Голова его сидит в конце, и все что до конца структуры (структура получается переменного размера), то его. И обычно там таки осмысленный тип этого самого массива. То есть это таки реально массив неизвестного на этапе компиляции размера, вполне конкретного типа массив. Это не тупо шмат памяти.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Oberon-07M
« Ответ #54 : Март 21, 2011, 08:56:32 pm »
Не, ARRAY 0 OF CHAR - фигово. Потому что это нифига не CHAR и нифига не ARRAY, а "шмат памяти". Лучше POINTER TO [MEMORY] или еще как, чтобы сразу было видно, что язык здесь кончился и пошел SYSTEM.
Чего это? Вполне себе array, просто неизвестного размера (на этапе компиляции). Ты же знаешь зачем это в сях делают? Чтобы структура могла прямо в себе содержать массив любого размера обычно. Голова его сидит в конце, и все что до конца структуры (структура получается переменного размера), то его. И обычно там таки осмысленный тип этого самого массива. То есть это таки реально массив неизвестного на этапе компиляции размера, вполне конкретного типа массив. Это не тупо шмат памяти.

ИМХО, надо определиться, чего мы хотим от такого описания. Если мы хотим просто поддержки сишных интерфейсов, то POINTER TO - вполне достаточное решение. Особенно если расчитывать на полуавтоматический биндинг. Если мы хотим сами создавать такие извращенные интерфейсы, то да, там можно много чего еще нафантазировать: например мембер структуры, который задает этот размер и т.д. (см. COM'ский IDL).

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Oberon-07M
« Ответ #55 : Март 21, 2011, 09:00:17 pm »
Ой блин. Не, нафиг. Эдак монстро неправильное получится. Я хочу монстро правильное. Хочу писать модули расширения для языка/компилятора писать не правя сам компилятор, о чем я уже писал кстати. Вот там то можно будет в тех самых редких случаях когда оно нужно, воткнуть любое извращение. И будет сразу видно что это именно что извращение и сразу можно будет посмотреть как оно реализовано.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Oberon-07M
« Ответ #56 : Март 21, 2011, 09:42:19 pm »
Цитировать
А что мешает тут сделать также? Я ж DIzer'у тут уже все глаза замозолил этим ARRAY 0 OF CHAR :-)

Это точно.. но зачем - толком обьяснить не получилось... так что нафиг...- все извращения в SYSTEM (для извращенцев)  :) а еще лучше не оберон 07 нужно править, а делать кастратный СИ и мозги не компостировать....

« Последнее редактирование: Март 21, 2011, 09:47:05 pm от DIzer »

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Oberon-07M
« Ответ #57 : Март 22, 2011, 04:33:02 am »
Пара багрепортов от меня:

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

2) Виртовский вариант цикла Дейкстры реализован как-то неправильно. Вот стандартный пример его использования:
MODULE TestGCD;

  IMPORT c := Console;

  PROCEDURE GCD(x, y: INTEGER) : INTEGER;
  BEGIN
    WHILE x > y DO x := x - y
    ELSIF x < y DO y := y - x
    END;

    ASSERT(x = y);

    RETURN x
  END GCD;

BEGIN
  c.Int(GCD(255, 150));
  c.Ln;
END TestGCD.
Программа падает на ассерте, в логе пишется:
TestGCD.GCD
x INTEGER 105
y INTEGER 45
хотя при данных аргументах (255 и 150) обе переменные должны быть равны 15, и сам цикл должен завершаться, когда x = y.

Сишный аналог этой процедуры работает правильно:
#define WHILE     for(;;) if (
#define DO        ) {
#define ELSIF     ; } else if (
#define WEND      ; } else break
#define ASSERT(p) if (!(p)) { printf("Oops in %s at line %d", __FILE__, __LINE__); exit(1); }

int gcd(int x, int y)
{
    WHILE x > y DO x = x - y
    ELSIF x < y DO y = y - x
    WEND;

    ASSERT(x == y);

    return x;
}

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;
Такое впечатление, что что-то не то с операциями сравнения...
to iterate is human, to recurse, divine

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

igor

  • Sr. Member
  • ****
  • Сообщений: 438
    • Просмотр профиля
Re:Oberon-07M
« Ответ #58 : Март 22, 2011, 05:00:10 am »
    WHILE x > y DO x := x - y
    ELSIF x < y DO y := y - x
    END;
...
Такое впечатление, что что-то не то с операциями сравнения...

Похоже, что после выполнения "DO ..." в ветке "ELSIF..." управление передаётся не на начало оператора, а на его конец.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Oberon-07M
« Ответ #59 : Март 22, 2011, 05:58:33 am »
Вообще как-то странно компилирует этот компилятор. Вот, декомпилировал эту функцию:
  PROCEDURE GCD(x, y: INTEGER) : INTEGER;
  BEGIN
    WHILE x > y DO x := x - y
    ELSIF x < y DO y := y - x
    END;
    RETURN x
  END GCD;
Получил страшный ужас:
int __cdecl sub_407971(int a1, int a2, int a3)
{
  signed int v0; // ecx@2
  signed int v1; // ecx@6
  int  r; // [sp+0h] [bp+0h]@1

  dword_409FFC = (int)& r;
  while ( 1 )
  {
    v0 = 1;
    if ( a3 <= a2 )
      v0 = 0;
    if ( v0 != 1 )
      break;
    a3 -= a2;
  }
  while ( 1 )
  {
    v1 = 1;
    if ( a3 >= a2 )
      v1 = 0;
    if ( v1 != 1 )
      break;
    a2 -= a3;
  }
  return a3;
}
Во-первых, какой-то левый неиспользуемый параметр появился у функции.
Во-вторых, самое главное, цикл:
    WHILE x > y DO x := x - y
    ELSIF x < y DO y := y - x
    END;
скомпилировался в что-то типа этого:
    WHILE x > y DO x := x - y END;
    WHILE x < y DO y := y - x END;
Но это же неверное представление цикла Дейкстры!
to iterate is human, to recurse, divine

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