Эка невидаль!

[spamsink]

Так как запускать программы из Паскаля-Автокода неудобно, я решил попробовать перенести программу печати в две колонки в Паскаль-Монитор. Одна известная разница - отсутствие в П-М конструкции "var _IN type" (например, "ch _IN letters", где тип letters определён как 'A'..'Z'), но это легко решается введением функций.

А дальше случилось забавное: я впервые увидел ошибку компилятора. Тестовый пример выглядит так:

 PASCAL COMPILER 15.0 (15.02.82)
 00001    1  0 PROGRAM MAIN(OUTPUT);
 00001    2  1 VAR S: SET OF 0..47;
 00007    3  2 BEGIN
 ******200 SYSTEM=200
 00010    4  2 S := [ORD(’ ’)..ORD(’/’)];
        *****                           0
 00023    5  0 END.

В перенесенном на С++ компиляторе падает с тем же успехом.

Pascal-Monitor in C++ (17.05.2019)
 00001    1  0 program main(output);
 00001    2  1 var s: set of 0..47;
 00007    3  2 begin
Error 200: Internal error 200
 00010    4  2 s := [ord(' ')..ord('/')];
       ^^^^^                            0
 00023    5  0 end.

Если вместо диапазона просто перечисление [ord(' '), ord('/')] - работает. Надо разбираться :)

Comments

[vak]

Качественный компилятор на Си++ получился: достоверно воспроизводит все ошибки. 😀

[spamsink]

Разгадка проста: оператор построения диапазона [a..b], в отличие от других бинарных операторов, анализируется на литеральную константность обоих операндов в процессе построения - это несколько ускоряет компиляцию, поскольку конструкция [const1..const2] довольно частая; и поэтому некто в своей мудрости решил, что в оптимизаторе константных выражений этот оператор не может встретиться.

Однако встроенные функции с константными операндами в литералы немедленно не превращаются, и выражение [ord(' ')..ord('/')] доезжает до оптимизатора константных выражений, где и приводит к фиаско.

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

[spamsink]

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

[vak]

Можно ли малой кровью обработать ord() в оптимизаторе константных выражений?

[spamsink]

Он там уже обрабатывается, поэтому ошибка "неожиданное константное выражение" и вылезает. Можно малой кровью обработать [C1..C2], и тогда не обязательно будет обрабатывать это на лету, что заметно уменьшит размер кода компилятора, но увеличит время его работы.
По-хорошему нужно использовать fuzzer для нахождения dead code (там, похоже, есть сколько-то), выбросить его, и освободится некоторое количество места, чтобы гарантированно поместились оба способа.