Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Идеальный транслятор

А этот… э… диван?
— Ручной труд, — быстро сказал Роман.
— Безотказен. Конструкции Льва Бен Бецалеля. Бен Бецалель собирал и отлаживал его триста лет…
— Вот! — сказал лоснящийся Модест Матвеевич.
— Вот как надо работать! Старик, а все делал сам.

А. и Б. Стругацкие «Понедельник начинается в субботу»

            У меня есть идеальный транслятор. Только не подумайте, что я продавец очередного «идеального продукта» с рекламой в духе Голливуда. Я не торгую трансляторами, не ищу пользователей и не собираюсь доказывать, что этот транслятор наилучший. Потому, что придерживаюсь мнения: если Вы сами убеждены, что Ваше программное средство лучшее — радуйтесь втихомолку и используйте его, а не участвуйте в очередной компьютерной «религиозной войне». Ведь все равно убедить в чем-либо участников таких войн невозможно. Как выразился один из завсегдатаев компьютерного форума: «на свете нет ничего такого, что заставило бы нас отказаться от нашей системы программирования».

            Речь о другом. Когда-то в компьютерном жаргоне существовало грубоватое выражение «полировать глюкало». Это означало заниматься ерундой — продолжать улучшать и без того работающую программу. При этом программист никак не мог заставить себя прекратить это занятие, поскольку оно доставляло ему эстетическое удовольствие. Некоторые «полировали» неделями, срывая все сроки и вызывая истерику у заказчиков. А если нет срока сдачи программы, можно ли заниматься этим год? А десять лет? А двадцать пять? Ну, это вряд ли, разве что Вы какой-нибудь граф Монте-Кристо, имеющий в камере замка Иф только листинг одной программы. Да и граф, помнится, просидел всего-то 14 лет. Ну, а совершенствовать двадцать пять лет программу на ассемблере, созданную в 1982 году? Это совсем невероятно: и компьютерный мир был другим, да и какая из тогдашних программ имела бы сегодня практический смысл?

            Тем не менее, и такая программа нашлась, и такой программист (я) нашелся. Прежде всего, замечу, что 25 лет для процессоров не так уж и много. Ведь процессор 8086 выпущен ещё в 1978 году, а 80386 — в 1985. Конечно, потом добавлялись команды вроде SSE2, но принципиальных изменений мало, даже 64-разрядные процессоры не сильно меняют картину. Так, что команды, написанные в 80-х, нормально выполняются и сегодня. А разбираться с командами, а не с текстом на языке высокого уровня пришлось потому, что исходный текст был недоступен. И уж конечно и в мыслях не было, что процесс совершенствования одной программы затянется на долгие годы. Это произошло постепенно, само собой. О результатах этого уникального эксперимента я и хочу рассказать и, думаю, вряд ли кому-нибудь удастся в ближайшее время повторить что-то подобное.

            В свое время мне сильно повезло: первая же серьезная программа, в которой я захотел разобраться, на примере которой учился программированию и которой в итоге занимаюсь почти 25 лет, была прекрасно написана выдающимся специалистом. Звали его Гарри Килдэлл. По логике вещей, он вполне мог бы оказаться на месте Билла Гейтса и, на мой взгляд, это было бы справедливее. Ну, уж как вышло — так вышло. Ходят слухи, что IBM в 1981 году просто ограбила Килдэлла, присвоив его операционную систему CP/M под именем MS DOS (и создав для этого подставную фирму MicroSoft). Любителям конспирологии есть, где разгуляться, тем более что сам Килдэлл погиб в 1994 году при неясных обстоятельствах. Но как бы то ни было, в силу многих и не всегда понятных причин одна из его прекрасных программ так и не нашла массового пользователя ни в 1982 году, когда она появилась, ни позже. Хотя, например, ещё Петер Нортон писал положительный отзыв на эту программу для компьютерного журнала.

            В 1987 году эта программа досталась и мне вместе с компьютером IBM PC XT. Собственно в компьютере кроме MS DOS 3.0, текстового редактора SideKick и этой программы вообще больше ничего не было. А являлась эта программа транслятором с языка PL/1 подмножества «G» (подмножество общего назначения).

            Программистам старшего поколения не нужно объяснять, что такое PL/1 и чем он был в 70-80-ые годы. Жаль, что на «персоналках» все пошло кривым путем бейсиков и Си (но это я опять скатываюсь к «религиозной войне»). Одним из объяснений, почему PL/1 не прижился на персональном компьютере, было отсутствие транслятора. Дескать, язык такой сложный, что транслятор не поместится в памяти. Но, во- первых, транслятор для IBM/360 вообще «помещался» в 64 Кбайта (на самом деле он имел оверлейную структуру). А во-вторых, транслятор-то давно уже был, вот этот самый Digital Research PL/I-86 compiler!

            Сначала у меня ничего не получалось, несмотря на энтузиазм, с которым я взялся за изучение новой системы программирования (была отличная документация на английском). Сыпались непонятные ошибки, нельзя было писать по-русски даже комментарии, а системная библиотека была рассчитана на DOS 1.0. Поэтому я решил разобраться, как все устроено, исправить, что нужно и пользоваться. Но сначала получить текст транслятора как результат дисассемблирования. В конце 80-х без опыта и готовых средств это было очень не просто. Даже получить большую распечатку в виде книги в отсутствии лазерных принтеров было нелегким делом.

            Постепенно все стало налаживаться, выработалась и технология: на распечатке пишутся комментарии к понятым фрагментам, затем комментарии переписываются в файлы исходного текста. В конце концов, вся распечатка покрывалась пометками и засаливалась до такой степени, что приходилось создавать новую, разбирать которую было уже проще. Разгадывание оказалось увлекательным занятием, помню, радовался как ребенок, когда удавалось внести небольшое усовершенствование или просто найти ошибку в трансляторе. Кроме того, разбирательство с транслятором принесло огромную пользу в понимании свойств этого языка и языков вообще, их возможностей и даже замыслов их создателей. Я заметил, что количество ошибок и глупых решений в моих собственных программах сократилось. По мере накопления опыта стали возможными более существенные изменения, например, почему бы не использовать команды сопроцессора? Почему бы не вставить не реализованный оператор PUT DATA ? Каждая новая возможность транслятора немедленно применялась в программах, которые ту же переписывались под новые условия. В основном, я занимался инженерными расчетами и не чувствовал ни малейшей необходимости использовать другие системы программирования, которые наконец в начале 90-х в огромном количестве стали появляться и в нашей стране.

            Через несколько лет я с удивлением увидел, что на персональном компьютере PL/1 использую только я (и маленькая группа моих коллег), а остальные работают или на Си или на Паскале и даже не слышали о трансляторе с PL/1, а новое поколение программистов уже и не знает, что это за язык. Честно говоря, я не расстраивался по этому поводу, поскольку уже привык к сладкому вкусу независимости (считая, что программные средства будут работать так, как я сочту правильным, а не так как кто-то там уже сделал!). В это время стали возможны более сложные доработки: переход от 16 к 32 разрядам и от DOS к Win32. Нашлось и удобное время для продолжения работ с транслятором — длительная дорога на работу и обратно. Конечно, кому-нибудь это покажется ненормальным: ездить годами на работу и чуть не каждый день вертеть в руках одну и ту же распечатку. Но мои соседи по транспорту вообще постоянно решают бессмысленные «японские кроссворды» и им же не приходит в голову, что они просто теряют зря время.

            Постепенно для меня прояснилась и задача: я хочу создать «идеальный» транслятор, программу, где каждая из 29 тысяч команд проанализирована на предмет необходимости и простоты. Каждая команда (раз уж так вышло, что у меня текст только на ассемблере) должна получить правильный и внятный комментарий. Я постараюсь убрать все лишнее, а «освободившееся место» использовать для расширения возможностей транслятора. Я не буду ставить себе никакого конечного срока, т.е. никакая версия не является окончательной.

            Создание «идеального» транслятора не является обязательной работой, а скорее годится в рубрику «развлечения не без пользы». Только ошибки в программах по вине транслятора делают его анализ опять приоритетным. Внося расширения, буду стараться оставаться в рамках языка и дорожить тем огромным практическим опытом по использованию PL/1, который уже накоплен.

            Такой подход сделал долгую работу незаметной и необременительной, а многолетний анализ позволил и без исходного текста разобраться в мельчайших деталях транслятора, понять (и задокументировать) его лучше, чем, вероятно, сам Килдэлл. Т.е. я оказался в роли Бена Гана из «Острова сокровищ», который в своих долгих блужданиях по острову нашел клад Флинта и безо всякой карты.

            Новый «исходный» текст, пусть и на ассемблере, дал возможность продолжить совершенствование транслятора с того места, на котором остановился Килдэлл, а иногда убирать шероховатости, оставленные разработчиками языка. Приведу несколько примеров. Как известно, «главная» программа на PL/1 начинается с заклинания PROC OPTIONS(MAIN). Смысл ключевого слова OPTIONS — в возможности задать параметры, относящиеся не к языку, а к «внешней среде». Это, например, начальный размер стека, который с точки зрения языка бесконечен. Но параметр MAIN как раз относится именно к языку, так же как, например, RECURSIVE или EXTERNAL . И они пишутся безо всякой OPTIONS . Я подправляю транслятор, чтобы MAIN можно было писать и так и так. Тексты старых программ менять не надо, зато в новых программах уже не надо вставлять надоедливую OPTIONS . Изменился ли язык? Формально да, а по сути лишь убрана маленькая «неровность» стандарта. В трансляторе это обошлось всего в несколько команд.

            Другой пример. После ключевого слова окончания процедуры или функции можно повторить её имя. Например, F:PROCEDURE;… END F; Если имя указано — транслятор проверяет его на совпадение с именем в заголовке. Если не указано — транслятор ничего не проверяет. Теперь это правило легко расширяется и на циклы:
DO I=1 TO 100
DO J=1 TO 100;
DO WHILE(…);
…
END WHILE;
END J;
END I;
На мой взгляд, дух PL/1 сохраняется, а доработки транслятора просто ничтожны.

            Следующий пример. Разработчики PL/1 перенесли из Алгола «сложные» циклы, т.е. возможность менять в заголовке цикла сам закон изменения параметра, например, DO I=3,5,100, BY -1 TO 0; Признаком смены «формулы» цикла является запятая, а признаком конца всего заголовка — точка с запятой. Я, например, использую такие циклы вместо конструкции UNTIL , когда первую итерацию нужно выполнять всегда:
DO F2=F(X), WHILE(ABS(F1-F2)>EPS);
F1=F2;
X+=DX;
F2=F(X);
END WHILE;
            В трансляторе я решил довести до конца идею «сложных» циклов и разрешить смену не только закона изменения параметра цикла, но и самого параметра, например, вот задание прохождения по «квадратной» траектории:
Y=0;
DO X=0 TO 99, Y=0 TO 99, X=100 TO 1 BY -1, Y=100 TO 0 BY -1;
ПЕРЕМЕСТИТЬ(X,Y);
END;
            Здесь на самом деле 4 цикла с двумя параметрами и когда один параметр меняется, второй — «замораживается» и остается таким, каким был при выходе из предыдущего цикла.

            Подобных дополнений довольно много, но все они необязательны к применению да и, на мой взгляд, без чистки шероховатостей языка нельзя считать транслятор «идеальным».

            Теперь рассмотрим, чего удалось достичь с точки зрения эффективности кода, скорости трансляции и размеров «идеального» транслятора. Не думаю, что при современных средствах эти характеристики так уж важны, если, конечно, они не совсем безобразны. Но я их привожу, как пример, до чего можно «отполировать» программу за много лет.

            Начнем с наименее важной характеристики — размеров транслятора. Я все время стараюсь сделать его как можно меньше, просто потому, что это легко измерить, есть объективный показатель совершенствования. Я отдельно считаю размер команд и статических данных. Это пошло с давних пор, когда ещё было необходимо втискивать команды «прохода» транслятора в 64 Кбайта. Сейчас сокращение на несколько байт не имеет смысла, но все равно приятно, когда при анализе находятся очередные лишние команды. На начало 2011 года размер команд «идеального» транслятора составляет 87091 байт, размер статических данных 182619 байт и, следовательно, весь размер транслятора 269710 байт.

            Я не пытаюсь установить мировой рекорд малости (да и транслятор Лиспа или Форта все равно будет меньше), но уверен, что немного найдется трансляторов с языка такого уровня таких же размеров. Сравните, например, хотя бы с размером файла с данной статьей. Причем, я вовсе не «зажимаюсь» с возможностями транслятора. Он может выдать и распечатку всех имен и результаты трансляции в виде ассемблера (хотя сразу генерирует готовый код объектного модуля) и даже раскрашивает сообщения об ошибках на экране. Т.е. многое можно было бы выбросить без ущерба для функциональности, но тогда какой же это будет «идеальный» транслятор, если нельзя получить, например, распечатку результата анализа в виде обратной польской записи? Для сопровождения это вовсе не роскошь, а необходимость. Несколько портит дело большой размер статических данных, но там львиную долю занимает один буфер внутренних операций (131072 байта). Когда-то он занимал лишь 256 байт, но изящно увеличить его удалось только до 65536 элементов по 2 байта каждый. Одно время я хотел все буфера выделять динамически, но затем махнул рукой. Практического смысла в экономии на данных нет, да и выполняемый модуль у меня один (он включает транслятор, редактор связей, библиотеки и т.п.) размером в полтора мегабайта. Зато для компактности большая часть других статических данных размещена как раз в этом буфере (к моменту его использования эти данные уже не нужны), а остаток места в буфере занимает довольно длинный текст описания ошибок при трансляции, выдаваемый на экран, как справочные данные.

            Обнаружилась любопытная вещь. Оказалось, что «скорость» совершенствования (в данном случае уменьшения размера команд) примерно постоянна уже много лет. Т.е. и здесь действует что-то вроде «первого закона Мура». Но значит, и здесь когда-нибудь сработает «второй закон Мура» — т.е. сокращения закончатся. Можно привести механическую аналогию — сжимание пружины. Увеличивая нагрузку можно заставлять пружину продолжать сжиматься. Но рано или поздно ее витки лягут друг на друга. Дальше можно лишь сломать пружину, но сжать её больше не удастся.

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

            Следующей по важности (точнее, по неважности) характеристикой является скорость трансляции. Когда-то это был очень важный параметр. Помню, первая же более-менее объемная программа транслировалась на IBM PC XT минут шесть. Можно было сходить чаю попить. Конечно, я старался ускорить транслятор, но быстро возросшая скорость самих компьютеров обесценила эти усилия. К тому же мешает отсутствие объективного показателя скорости вроде размера в байтах для предыдущей характеристики. Дело не в том, что хочется засечь микро и наносекунды. Я бы предпочел иметь в процессоре специальную команду типа RDTSC, которая бы считала такты, если управление находится внутри заданного диапазона адресов, а вне этого диапазона такты не меняются. Тогда даже для небольшой конкретной процедуры можно было бы получать некий числовой показатель скорости и смотреть, как на него влияют изменения команд. А так, исправления нескольких команд, обычно никак не ощущаются на скорости работы всей программы. За неимением таких средств, для оценки скорости работы я просто делю объем транслируемой программы на время трансляции и на тактовую частоту процессора. Объем программы можно выразить в байтах или строках. Конечно, строка исходного текста, это очень субъективный показатель, зависящий от стиля программирования, но, тем не менее, почему-то часто принято оценивать объем программы именно в строках.

            На моем компьютере с обычным процессором Intel Core Solo CPU 1.33GHz все 40 модулей программы (моей основной работы) общим объемом 4479812 байт или 148423 строк транслируются за 6382 миллисекунды (время засекает сам транслятор). Это означает, что «идеальный» транслятор работает со средней скоростью 528 байт или 17 строк исходного текста в секунду на каждый мегагерц тактовой частоты процессора. Здесь, правда есть небольшой обман: это время не первой, а второй и последующих трансляций, когда файлы уже попали в кэш Windows. Небольшим обман я считаю потому, что перетрансляции у нас идут десятками с утра до вечера и то, что первая из них проходит медленней, практически незаметно. В указанный объем программы входят, естественно и заголовочные файлы, которые транслятор для каждого модуля разбирает заново, из-за чего объем текста всего проекта становится довольно большим.

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

            Наконец рассмотрим практически единственно важную характеристику современных трансляторов — качество генерируемого ими кода. Но как раз качество кода однозначно оценить сложно. Для разных случаев могут быть разные критерии. Готов признать, что «идеальный» транслятор генерирует не идеальный, а обычный нормальный код. Без сверхсложных оптимизаций, но и без глупых команд типа LEA ESI,[ESI]. Транслятор имеет регистровую модель IA-32, пытается максимально использовать регистры и в сложных случаях распределяет их по алгоритму Биледи. Кстати, в моих прикладных программах до этого алгоритма почему-то дело никогда не доходит. Имеется и поиск часто встречающихся случаев. Поэтому и оператор X=X+1; и оператор X+=1 ; транслятор легко превращает в одну команду инкремента.

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

            Вот так выглядит исходный текст:
TEST:PROC MAIN;
DCL
(I,J,K) FIXED(31),
F ENTRY(FIXED(31),FIXED(31)),
X (100,100) FIXED(31);
DO I=1 TO 100;
DO J=1 TO 100;
F(I,J);
K+=X(I,J);
END J;
END I;
END TEST;
            Вот так выглядит часть программы в обратной польской записи:
…
IID 0 N 1 00 00 I
C4 0 N 0 00 00 #00000001
ILD 1 N 0 01 00
IAS 2 S 0 31 00
WHL 0 N 0 01 00
IID 0 N 1 00 00 I
ILD 1 N 0 31 00
C4 0 N 0 00 00 #00000064
ILD 1 N 0 07 00
ILE 2 N 0 01 00
DOW 1 N 0 01 00
LIO 0 N 1 64 00 N0008
LL4 0 N 0 07 00
FE
IID 0 N 1 00 00 J
C4 0 N 0 00 00 #00000001
ILD 1 N 0 01 00
IAS 2 S 0 31 00
WHL 0 N 0 01 00
IID 0 N 1 00 00 J
ILD 1 N 0 31 00
C4 0 N 0 00 00 #00000064
ILD 1 N 0 07 00
ILE 2 N 0 01 00
DOW 1 N 0 01 00
LIO 0 N 1 65 00 N0009
IID 0 N 1 00 00 I
NID 0 N 1 00 00 #01AEE89B
AST 2 N 0 00 00
            А вот, что получилось у транслятора в итоге:
1 000000 TEST:PROC MAIN;
2 000000 DCL
000000 TEST:
000000 B88C9B4002 mov eax,37788556
000005 E800000000 call ?START
3 00000A (I,J,K) FIXED(31),
4 00000A F ENTRY(FIXED(31),FIXED(31)),
5 00000A X (100,100) FIXED(31);
6 00000A
7 00000A DO I=1 TO 100;
00000A C7050800000001000000 mov I,1
000014 @1:
000014 833D0800000064 cmp I,100
00001B 7F4D jg @2
8 00001D DO J=1 TO 100;
00001D C7050C00000001000000 mov J,1
000027 @3:
000027 833D0C00000064 cmp J,100
00002E 7F32 jg @4
9 000030 F(I,J);
000030 BB589C0000 mov ebx,offset @00009C58h
000035 E800000000 call F
10 00003A K+=X(I,J);
00003A 693D0800000090010000 imul edi,I,400
000044 A10C000000 mov eax,J
000049 C1E002 shl eax,2
00004C 03F8 add edi,eax
00004E 8B8780FEFFFF mov eax,X+0FFFFFE6Ch[edi]
000054 010510000000 add K,eax
00005A FF050C000000 inc J
000060 EBC5 jmps @3
000062 @4:
000062 FF0508000000 inc I
000068 EBAA jmps @1
00006A @2:
11 00006A END J;
12 00006A END I;
13 00006A
14 00006A END TEST;
00006A E800000000 call ?STOPX
15 00006F
CODE 00006F
DATA 009C60
            Как видите, особых изысков нет, но и ужасным такой код назвать нельзя. Обратите внимание на способ передачи параметров I и J внутрь процедуры F через список адресов в памяти, а не через стек. Для рекурсивных процедур это замедляет работу, для не рекурсивных —… ускоряет. Здесь как раз видна противоречивость оценки качества кода. Например, для передачи параметров потребовалось 13 байт (5 байт — засылка адреса списка в EBX и 8 байт на сам список адресов в памяти). Если бы I и J передавались через стек, потребовалось бы всего 12 байт. Однако возврат из процедуры F в данном случае производится командой RET (1 байт), а в случае использования стека RET 8 (3 байта). Какие плюсы, какие минусы перевесят в каждом случае — совсем неочевидно.

            Так можно ли считать этот транслятор «идеальным»? Себе я отвечаю на этот вопрос положительно. Для доказательства и приведены характеристики, которые не получить без многолетней работы. Это буквально «вылизанное» средство, которое постепенно развивалось вместе с эволюцией компьютеров. Сразу такой транслятор создать было бы невозможно. Он уже сильно отличается от исходного: половина команд добавлена вновь, а вторая половина изменена (что ничуть не умаляет заслуг Килдэлла). Новые решения, которые теперь легко добавлять, я сам же проверяю на практике и ими вполне доволен. К тому же, всеохватность языка PL/1 позволила успешно применять его для самых разных задач. «Идеальным» оказался транслятор и для моего руководства: не требуются деньги на лицензионные средства или время на переучивание, а положительные результаты получаются.

            Не всегда транслятор оказывается «идеальным». Например, иногда к результатам его работы с подозрением относятся антивирусы, а программа, которая должна была установить защиту от копирования, вдруг выдала нелепое сообщение: «Ваша программа не предназначена для работы под Windows». Подозреваю, что их сбило с толку отсутствие в программах секции «text». Для тех, кто не знает: когда-то так «умно» назвали раздел EXE-файла, содержащий выполняемые команды. Просто здесь он называется ближе по смыслу: «PROGRM».

            Я с уважением отношусь к советским конструкторам, особенно оружейникам. Их труд и блестящие результаты являются вдохновляющим примером и настоящим, без иронии, идеалом, к которому нужно стремиться. И, на мой взгляд, есть что-то общее между трансляторами для программистов и оружием для военных. При такой аналогии мой транслятор, пожалуй, это пистолет Макарова. Это классическая схема, компактность, надежность и простота. Причем простота конструкции данного пистолета обманчива: за каждой деталью стоит огромный объем поисков и отработок. И статью я хочу закончить цитатой об этом оружии: «С современной точки зрения пистолет Макарова считается устаревшим оружием. Однако и сегодня (через 64 года после создания — прим. мое) он является единственным серийным пистолетом, проходящим [все] комплексные проверки».

Автор: Д.Ю.Караваев. 08.03.2011

Опубликовано: 2018.08.26, последняя правка: 2019.01.29    14:24

ОценитеОценки посетителей
   ██████████████████████████████████████████ 5 (100%)
   ▌ 0
   ▌ 0
   ▌ 0

Отзывы

     2018/09/22 10:02, Автор сайта          # 

Если не секрет, на чём программируете сейчас, неужели по-прежнему на PL/1?

     2018/09/22 11:22, Д.Ю.Караваев          # 

А по поводу PL/1 — да, используем и тоже, как говорится, «и в ус не дуем». Дело в том, что для инженерных задач он очень подходит. Многие вещи в нем и проще и эффективнее и, что очень важно, проверены на практике за очень долгий период.

Кроме этого, а может быть и главное в этом — это доступность транслятора для исправлений. Например, можно ввести новую систему типов: Типы в инженерных задачах, а можно захватывать максимальные ресурсы при выполнении программы: http://files.rsdn.org/122727/pl1ex22.doc

Так что, вполне себе рабочий язык для вполне себе актуальных задач. Незаслуженно и парадоксально получивший ярлык «дико сложного», притом, что нынешнее поколение программистов вообще считает предыдущее чем-то вроде дикарей с луком и стрелами. Честно скажу, за все время моей карьеры программиста никогда не возникало сложностей в части «как это выразить на языке». Все сложности всегда были по части «как найти решение этой задачи?». Поэтому программы на PL/1 постоянно и успешно работают на борту МКС.

     2018/09/22 12:00, Автор сайта          # 

Для меня PL/1 — это такая далёкая история... Конечно, ПО — не скоропортящийся товар, но факт того, что PL/1 до сих пор работает на современной технике — это, конечно, для меня сюрприз. Про лук и стрелы — это Вы красочно живописали. А что ещё как из современного, так и из «древностей» в РКК «Энергия» используют? Просто любопытно.

Ваше письмо подтолкнуло меня к чтению Википедии насчёт PL/1 :) Как правило, все языки имеют свой сайт: java.org, dlang.org, haskell.org, rust.org, golang.org. А вот про pl1.org в Википедии не пишут. Материалов про него мало.

     2018/09/22 12:42, Д.Ю.Караваев          # 

У нас тоже была попытка создать сайт и даже имя было вполне удачное: http://pl1.su но по некоторым причинам он так и остался замороженым в начальной стадии.

Фраза про «лук и стрелы» попалась мне на одном из форумов. Вроде имелся ввиду АЛГОЛ.

РКК — большая организация, то и инструментальные средства используются самые разные. Наше подразделение чисто «прикладное», руководству всё равно, какими инструментами мы пользуемся. Не просим купить лицензионные продукты, успеваем за развитием возможностей компьютеров — ну и слава богу.В общем-то, PL/1, который для IBM/360, вместе с IBM/360 и ушел. А вот для X86 только жить начал после принятия стандарта ANSI X3.74 в 1987 году.

Ещё могу привести байку (на самом деле это правда), что вместе с первой экспедицией на МКС летел и компилятор с PL/1. Не было уверенности, что ПО связи заработает сразу как надо, да и пропускная способность была даже штатно очень слабая. Поэтому в аварийном случае рассматривался вариант: диктуем экипажу исправления в исходных текстах и перетранслируем на борту. К счастью, такая экзотика не потребовалась.

Напоследок компьютерная байка (к сожалению, забыл, у кого её прочел). Почему PL/1 не вытеснил Фортран и Кобол.

В середине 60-х в американском компьютерном сообществе сложились две группы, условно «инженерная» и «экономическая». Одни использовали Фортран, другие — Кобол. К друг другу относились свысока, почти ненавидели (вроде фанатов ЦСКА и Спартака). При создании нового языка была мысль объединить преимущества каждого из языков в одном и, тем самым, объединить обе группы одним инструментом. Разработчики искренне верили, что программисты благосклонно воспримут новый язык, как следующую ступень развития, уж явно совершеннее и Фортрана и Кобола. В действительности получилось обратное. «Инженеры» возмутились, что в их прекрасный простой Фортран воткнули бухгалтерский ввод-вывод (в PL/1 имеется спецификация вывода дебета/кредита). А «экономисты» возмутились тем, что в их простой Кобол был вставлен целиком Фортран. В результате массового перехода на PL/1 не произошло. Фортран и Кобол продолжали оставаться основными инструментами. И только новое поколение в 70-х, уже не связанное этой «вендеттой» начали пользоваться новым инструментом. Уже искренне удивляясь, почему предыдущие поколения не признают преимущества этого языка, а видят только недостатки.

Такая вот непредсказуемая вещь — язык программирования.

     2018/09/22 14:11, Автор сайта          # 

Интересно, какова степень Вашего авторства на данный момент? Это тот самый изначальный компилятор от главы Digital Research, который развивали и развивали и даже сделали 64-разрядную кодогенерацию? Или Вы на определённом этапе взяли и написали компилятор с нуля и это теперь на 100% Ваше детище? Думаю, ответ на этот вопрос будет интересен не только мне, но и читателям. А он вполне логичен, потому что вопрос авторства в Ваших статьях освещён не был.

     2018/09/22 15:33, Д.Ю.Караваев          # 

Для меня вопрос непростой. Сначала формально нет, не разработчик. И такой задачи не ставилось.

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

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

     2018/09/22 16:21, Автор сайта          # 

В целом получается, что и да и нет: и разработчик, и не разработчик.

Но если Вы хотите внести свой транслятор в перечень отечественного ПО, то вопрос об авторских правах надо как-то надо решать.

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

Почему имеет смысл — хотя бы полностью очиститься в вопросе авторских прав :) Но есть другой аспект: если Вы хотите, чтобы Ваш транслятор достался потомкам на века, есть смысл написать его на более понятном языке, нежели ассемблер. Это более лёгкая поддержка — не для Вас, а для потомков. Как вариант, можно переписать транслятор PL/1 на самом PL/1 — дополнительная проверка транслятора.

С проблемой переносимости (с архитектуры x86 на другую) так и не сталкивался

Может, я и не прав, но как мне кажется, что архитектура ARM куда более практична для космоса и вообще бортового оборудования: она энергоэффективнее, на каждую единицу потреблённой электроэнергии приходится наибольшее количество выполненных команд. Архитектура MIPS тоже неплоха в этом плане. И неплохо было бы иметь кодогенератор для LLVM. Но это я сужу со своей колокольни. Вам куда виднее :)

     2018/09/22 17:36, Д.Ю.Караваев          # 

Но раз Вы хотите внести свой транслятор в перечень отечественного ПО, то вопрос об авторских правах надо как-то надо решать.

А стоит ли беспокоиться? Исходный продукт вышел 34 года назад в виде 16-разрядного продукта для MS-DOS 1.0 (для MS-DOS 3.0 уже были нюансы). Он до сих пор доступен в сети под именем PL/I-86. Его потомок генерирует очень отличный от исходного код и совсем для другой среды. Да и международная обстановка облегчает вопросы о правах :)

Если Вы хотите, чтобы Ваш транслятор достался потомкам на века, есть смысл написать его на более понятном языке, нежели ассемблер. Это более лёгкая поддержка — не для Вас, а для потомков. Как вариант, можно переписать транслятор PL/1 на самом PL/1 — дополнительная проверка транслятора.

Будучи представителем действительно универсального языка, тем не менее, я скептически отношусь к таким вещам как «раскрутка компилятора». Вспоминается шутка 90-х: «транслятор с Паскаля нужен, чтобы писать на нем трансляторы с Паскаля». У меня нет ни физических, ни моральных сил переписывать транслятор, особенно учитывая, что сразу на порядок просядет эффективность и быстродействие. Тем более что две трети транслятора занимает генерация x86, т.е. все равно привязка к командам. Дополнительная проверка транслятора — слабая плата за переписывание. Гораздо эффективнее получаются проверки, когда мы находим нового программиста. В его исходных текстах обязательно найдется что-то неожиданное :)

А работу на века обеспечат виртуальные машины. Мне кажется, они раньше закроют все потребности, чем договорятся о едином промежуточном коде вроде LLVM.

Может, я и не прав, но как мне кажется, что архитектура ARM куда более практична для космоса и вообще бортового оборудования: она энергоэффективнее, на каждый ватт электроэнергии приходится наибольшее количество выполненных команд. Архитектура MIPS тоже неплоха в этом плане.

Будучи сторонником универсального языка, я являюсь и сторонником CISC-команд. В защиту таких команд приведу шуточную аналогию. Знаете ли Вы, что в соревнованиях по плаванию теперь есть специальный судья, который следит за тем, чтобы пловцы после стартового прыжка вынырнули ДО середины бассейна? Так как под водой, понятно, они движутся быстрее. При чем здесь CISC ? А они, набрав себе операндов, тоже «ныряют» вглубь кристалла. И пусть действуют там как можно дольше "не барахтаясь на поверхности", т.е. не обращаясь к медленной памяти. Предельный случай — квадратный корень или тригонометрия в FPU. Вы можете написать свою функцию корня, никаких особых, волшебных команд внутри FPU нет, но он все равно сработает быстрее, поскольку не надо читать команды и обращаться к памяти за данными.

RISC команды работают быстрее, но быстрее ли программы из RISC команд? Это не факт, учитывая, что кристаллы все быстрее и быстрее, а память все отстает и отстает. Архитектура, где любая команда может стать командой перехода, сложна в конвейеризации и выделении линейных участков программы.

Но это я сужу со своей колокольни. Вам куда виднее :)

Да я тоже не господь бог. Сейчас наши программы работают на МКС на обычных ноутбуках под Windows. Ну и одна на контроллере AT90S2313. Особой «космической» специфики здесь нет.

     2018/09/22 18:41, Автор сайта          # 

А стоит ли беспокоиться? ... Да и международная обстановка облегчает вопросы о правах :)

Да уж... У нас есть очень хороший рычаг — угроза пересмотра договоров об авторских правах :)

Гораздо эффективнее получаются проверки, когда мы находим нового программиста. В его исходных текстах обязательно найдется что-то неожиданное :)

Вы меня удивили! Даже не подумаешь о подобном. Надо взять себе на заметку :)

RISC команды работают быстрее, но быстрее ли программы из RISC команд? Это не факт, учитывая, что кристаллы все быстрее и быстрее, а память все отстает и отстает. Архитектура, где любая команда может стать командой перехода, сложна в конвейеризации и выделении линейных участков программы.

Да я не про скорость, а про энергоэффективность. Фигурально выражаясь, на вычисление квадратного корня х86 тратит 10 джоулей, а ARM — 1 джоуль. А в космосе (да и вообще, в бортовых системах) — каждый киловатт-час на счету.

 Сейчас наши программы работают на МКС на обычных ноутбуках под Windows.

Значит, там всё неплохо с энергоснабжением :)

Ещё мысль про «очистку» авторских прав. Транслятор PL/1, который вы долго «допиливали», был изначально написан, скорее всего, на Си или на чём-то подобном. Но не на ассемблере. А раз так, то Вы можете предъявить миру текст на ассемблере, а вот наследники Килдэлла если что-то и предъявят, так это текст на Си. И даже после трансляции тексты на 90% будут несовпадающи. Когда-то в далёкие советские времена рассказывали случаи из жизни «загнивающих»: два программиста спорили в суде насчёт авторских прав на одну и ту же программу. Выиграл суд тот, который смог показать суду лишние команды, внесённые в программу специально как тайнопись.

     2018/09/22 20:13, Д.Ю.Караваев          # 

Значит, там всё неплохо с энергоснабжением :)

Каждый ватт экономят на спутниках. Здесь все-таки другие масштабы. Кроме этого, это т.н. «компьютеры экипажа». Поэтому взята обычная и привычная среда и техника, а не что-то специальное.

Транслятор PL/1, который вы долго «допиливали», был изначально написан, скорее всего, на Си или на чём-то подобном. Но не на ассемблере.

Транслятор Килдэлла был написан на PL/M. Это нечто среднее между ассемблером и Си.

Поскольку я не собираюсь продавать транслятор в Америке, думаю до суда не дойдет. Кстати, жена Гарри умерла в 2002, насколько помню, у него сын и дочь. А тексты после многолетней «полировки» не совпадают на 100%. Т.е. вообще ничего общего при похожей функциональности.

     2019/04/29 17:21, VIT1972          # 

Дмитрий Юрьевич, а где можно скачать Ваш транслятор?

     2019/04/29 20:47, kt          # 

Эта юмореска была в журнале downgrade №5 за 2012 год (http://www.dgmag.in). В конце заметки была ссылка на Zip-файл. Версия, правда старовата и ещё 32-х разрядная. Но для знакомства подойдет.

     2019/04/30 00:03, VIT1972          # 

Все же хотелось бы последнюю версию. Транслятор развивается?

     2019/04/30 10:08, kt          # 

Да, развивается. Сейчас вот это рабочая 64-х разрядная версия.

http://files.rsdn.org/122727/PLINK64.EXE

     2019/04/30 11:02, VIT1972          # 

Спасибо, попробую.

     2019/05/01 18:41, Comdiv          # 

Программа с выводом одной строки заняла 89600 байт. Можно ли уменьшить runtime, и что в нём?

     2019/05/01 19:49, kt          # 

Например, встроенный отладчик со встроенным дисассемблером. Он запускается, если в командной строке перед параметрами указать два вопросительных знака подряд: t.exe ??123457

     2019/05/03 06:50, Виктор          # 

К сожалению, по скорости счёта в разы уступает компилятору oт IBM. Аналогичная ситуация с линуксовым проектом iron-spring.com, но там, судя по всему, его окончательно забросили.

     2019/05/03 09:54, RZ          # 

А конкретные примеры можно? Ну, чтобы "в разы" время счета отличалось. Можно же посмотреть, в какие команды программа перевелась и понять, какие команды дают такой волшебный эффект.

     2019/05/03 13:10, Виктор          # 

https://cloud.mail.ru/public/4PzN/2GJZVJb4J

История такова: у меня в ЖЖ возникла дискуссия на тему ошибок программ с IBM-овского компилятора при антипереполнении. Собеседник обратился к уважаемому Д.Ю. с просьбой адаптировать тестовую программу под свой компилятор. В корневом каталоге в архиве по ссылке — результат Д.Ю., в папке IBM — результат компиляции моей программы стандартным транслятором. Программка, конечно, примитивная, с более сложными результаты могут отличаться.

Сам по себе IBM-транслятор даёт код где-то на уровне gcc/gfortran или даже лучше по скорости, но проигрывает на подобных вычислительных задачах PGI-компилятору иногда в 2-3 раза и выше при счёте в один поток.

     2019/05/07 14:54, kt          # 

Любопытно. Оказывается, я принял участие в состязании. Мне тоже хотелось бы найти волшебные команды, которые увеличивают скорость в разы. Давайте разберёмся.

Я подправил выдачу в тестовой программке, поскольку оператор TIME в стандарте «G» выдает строку в формате ЧЧ:ММ:СС и нет тысячных, они записываются отдельно в системную переменную ?M_TIME. Кстати, замечу, что время не обязательно измерять дважды, достаточно запоминать предыдущее. В общем, теперь программа выглядит так:
A1:PROC OPTIONS (MAIN);
//---- ОСОБЕННОСТИ КОНКРЕТНОЙ СИСТЕМЫ ----
DCL
?MEMORY FIXED(31) EXT INIT(-1), // РАЗМЕР РЕЗЕРВИРУЕМОЙ ПАМЯТИ
?MASK_87 BIT(8) EXT, // МАСКА FPU
?M_TIME FIXED(31) EXT,
?TST387 ENTRY;

?MASK_87='00001101'B; // МАСКА ИСПРАВЛЯЮЩАЯ АНТИПЕРЕПОЛНЕНИЕ НА НОЛЬ
?TST387; // УСТАНОВИЛИ СОСТОЯНИЕ FPU БЕЗ АНТИПЕРЕПОЛНЕНИЯ

//---- СОБСТВЕННО ПРОГРАММА ----
DCL
T(5000,5000) FLOAT(53) BASED(P), // ЧТОБЫ МАССИВ БЫЛ НЕ В ФАЙЛЕ
P PTR,
MATRIX FILE, // ЧТОБЫ ОТВЕТ ВЫДАВАЛСЯ НЕ НА ЭКРАН
T1 FLOAT(53),
DTM FLOAT(53),
(I1,I2) FIXED(*),
(I,J,L,N,M,DD) FIXED(*),
(TIME1,TIME2) CHAR(8);
ALLOCATE T;
ON ERROR PUT SKIP LIST('ERROR STEP',L,STOP);
T=0;
DO I=LBOUND(T) TO HBOUND(T); T(1,I),T(I,1)=1; END I;
N=5000;

DO L=1 TO 10000;
DTM=0;
DO I=2 TO N-1;
I1=I-1; I2=I+1;
DO J=2 TO N-1;
T1=(T(I1,J)+T(I2,J)+T(I,J+1)+T(I,J-1))/4;
DTM=MAX(ABS(T1-T(I,J)),DTM);
T(I,J)=T1;
END J;
END I;

M=?M_TIME; // ПРЕДЫДУЩИЕ ТЫСЯЧНЫЕ
TIME2=TIME1; // ПРЕДЫДУЩЕЕ ВРЕМЯ
TIME1=TIME; // ТЕКУЩЕЕ ВРЕМЯ
//---- ВЫЧИСЛЯЕМ, СКОЛЬКО ТЫСЯЧНЫХ ПРОШЛО ----
IF TIME2=TIME1 THEN DD=?M_TIME-M; ELSE DD=1000-M+?M_TIME;
PUT SKIP EDIT(L,DTM,DD)(F(5),X(1),E(14),F(5));
END L;

PUT SKIP(2) LIST(TIME,'ЗАПИСЫВАЕТСЯ ОТВЕТ В ФАЙЛ MATRIX.TXT');
OPEN FILE(MATRIX) PRINT TITLE('MATRIX.TXT') LINESIZE(250);
PUT FILE(MATRIX) DATA (T);
END A1;
Увы, запуск на процессоре Intel core i5-3210M 2.50 GHz дал время одной итерации 624 тысячных, а у транслятора IBM около 220, т.е. почти в три раза быстрее. Если посмотреть на получившиеся команды основного цикла по I и J, то у IBM их 39, а у PL-KT целых 104. Казалось бы, вот и разгадка. Никаких волшебных команд нет, но оптимизатор IBM превратил двумерный массив в одномерный, заменил деление на 4 умножением на 0.25, выровнял данные и команды на 16.

Для себя я различаю оптимизацию стратегическую, оперативную и тактическую. Стратегическую оптимизацию решения задачи в целом может провести только программист: кроме самых простых примеров, транслятор не может понять смысл всей задачи. Пример оперативной оптимизации — это как раз результат работы транслятора IBM. Он вынес все повторяющиеся действия из циклов, убрал индексы I и J и вообще не стал создавать таких переменных. Сам заменил деление умножением. А в маленьком PL-KT вообще нет оперативной оптимизации, а есть только тактическая — в пределах нескольких команд, например, использование SIB-адресации. Тактическая оптимизация часто позволяет распараллеливать независимые друг от друга команды, поскольку процессоры имеют несколько внутренних каналов ввода и исполнения.

Но вернемся к нашим баранам, т.е. к тесту. Я попытался вручную повторить некоторые приемы оптимизации. Замена деления умножением, к моему удивлению, совершенно ничего не изменила. Похоже, процессор сам оптимизирует случаи вроде деления на степень двойки. А вот выравнивание данных на 16 привело не к ускорению, а к замедлению работы. Выравнивание данных здесь вообще выглядит не очень. Я рассчитываю, что будет использовано 5000х5000х4=100 000 000 байт, а транслятор IBM реально использовал 400 миллионов. Для 32-х разрядной системы это значительная разница. Ожидаемо самый большой вклад времени дает запись в массив (чуть ли не половина времени), что ещё более снижает вклад остальных оптимизаций.

Меня могут ехидно спросить: ну и что ты тут разглагольствуешь о тактической оптимизации, когда твой код все равно в три раза медленнее? Я часа три пытался найти, что же приводит к такой большой разнице. Последним действием, на всякий случай привел в соответствие начальное заполнение массива. В исходном примере было
T=1E-30;
А у меня
T=0;
поскольку в PL-KT нет присваиваний массивов константе, кроме нуля. Пришлось дописать программу:
 DO I=LBOUND(T) TO HBOUND(T);
DO J=LBOUND(T) TO HBOUND(T);
T(I,J)=1E-30;
END J;
END I;
И вдруг скорость почти удвоилась. Неоднократные повторные проверки подтвердили: время итерации стало не 624, а примерно 365. Ну, раз пошла такая пьянка, тогда уж сравнивать надо не с 64-разрядной версией, а тоже с 32-х разрядной, как у IBM. И переменные FLOAT брать 4-байтные, т.е. FLOAT(24), а не FLOAT(53). Транслирую старой версией транслятора (http://files.rsdn.org/122727/PLINK.EXE) и получаю результат ещё чуть лучше — 343 миллисекунды. Таким образом, в одинаковых условиях, PL-KT проигрывает IBM не в три, а в полтора раза (в 1.51), что тоже немало, но все-таки не «в разы»...

У меня нет разумной гипотезы, почему заполнение массива не нулями так влияет на скорость. Казалось бы, наоборот, заполнение нулями памяти, к которой вообще ранее не обращались, может игнорироваться. Поскольку в примере нулевые значения в массиве постепенно исчезают, скорость итераций должна была бы со временем падать, но этого не наблюдается.

Некоторые итоги.
  • Оптимизатор IBM творит чудеса, но на современных процессорах это дает всё меньший эффект. Например, честное вычисление индексов двумерного массива дало лишь 50% замедление. Отчасти это связано с тем, что при сильной оптимизации осталось мало независимых команд, которые могут выполняться в параллель.
  • Транслятор IBM не использовал базово-индексную адресацию, которая также выполняется параллельно. Замена деления на 4 умножением не дает вообще ничего.

    Конкретный пример очень специфический, но, вероятно, имеет смысл, поскольку напоминает моделирование распространения чего-то в чем-то (привет институту Радио!). В этом простом случае нет претензий к оптимизации, но в более громоздких задачах такая оптимизация может затруднять отладку. Например, в PL-KT я могу в отладчике посмотреть текущие I и J, поскольку они честно вычисляются. У IBM попытка вывести эти значения приведет к изменению самого кода, так как тогда придется считать индексы, даже если они и не нужны.
  • Нашлось и место, где оптимизация превратилась в противоположность. Присвоение
    T(I,J)=T1;
    в трансляторе IBM превратилось в
    fld     tbyte ptr [ebp-50h]
    fstp tbyte ptr [edx-13890h]
    а в PL-KT в громоздкие
    MOV    EDI,[0040B428] .P
    IMUL EAX,[0040B440],00004E20 .I
    ADD EDI,EAX
    MOV EAX,[0040B444] .J
    LEA EDI,[EDI+EAX*4]+FFFFB1DC
    MOV ESI,0040B42C
    MOVSD
    которые, тем не менее, работают быстрее, так как не задействуют FPU, а загрузка ESI может выполняться параллельно с EDI.

     2019/05/08 08:58, kt          # 

К сожалению, подтвердилось ожидаемое, но печальное обстоятельство. 64-разрядная кухня работает медленнее 32-разрядной, чтобы там не писали разработчики этой архитектуры. В данном случае на 9%. Я допускаю, что команды работают так же быстро, но поскольку часть команд стала длиннее, код получается менее плотным и кэш менее эффективен. Правда, кроме снятия барьера в 4 Гбайт (ради чего и затевалась эта архитектура), тест продемонстрировал и дополнительный бонус: работа с FLOAT(53) идет так же быстро, как с FLOAT(24), а в 32-разрядной среде — заметно медленнее, хотя бы из-за того, что невозможно одной командой MOVSQ пересылать такие данные.

     2019/05/08 11:18, VIT1972          # 

Потихоньку тестирую. Получил вот это. Что это значит?
PLINK64.exe count_sort.pli
╔═════════════════════════════════════════════╗
║ LINK-KT РЕДАКТОР СВЯЗЕЙ Версия 4.0 ║
║ (C) Караваев 1992-2019 04.05.2019 г. ║
╚═════════════════════════════════════════════╝

В ФОРМАТЕ OMF 8086/87 ОШИБКА 9
ФАЙЛ COUNT_SORT.PLI
ЗАПИСЬ # 0001
АТОМ # 0001

d:\My Downloads>PLINK64.exe count_sort.pli D
╔═════════════════════════════════════════════╗
║ LINK-KT РЕДАКТОР СВЯЗЕЙ Версия 4.0 ║
║ (C) Караваев 1992-2019 04.05.2019 г. ║
╚═════════════════════════════════════════════╝

ОШИБКА ВЫЗОВА
count_sort.pli D?
Отвечаю себе сам. Компилятор не понимает расширение .PLI. И ведет себя при этом неадекватно.

Пока никак не могу понять, как все же вывести в файл листинг всей программы с результатами компиляции. В консоли неудобно. Вот такой вывод неполон, неудобен и непонятен:
РL/1-KT (версия 1.1 от 04.05.19) КОМПИЛЯЦИЯ ФАЙЛА count_sort.pl1D: ВЫВОД ПРОТОКОЛА В .PRN
I: ВЫВОД ПСЕВДОАССЕМБЛЕРА И ВЫВОД ИСХОДНОГО ТЕКСТА
O: ОТКАЗ ОТ .OBJ
P: ВКЛЮЧЕНИЕ ВСЕХ ИМЕН В OBJ
Q: КОНТРОЛЬ ПЕРЕПОЛНЕНИЙ
R: ОТЛАДКА
S: ВЫВОД РАСПРЕДЕЛЕНИЯ ПАМЯТИ
T: КОНТРОЛЬ ИНДЕКСОВ И СТРОК
X: ВЫВОД НЕИСПОЛЬЗУЕМОГО

3 b declare (min, max) fixed;
ЕСТЬ В ПЛ ? ?
13 c declare t(min:max) fixed;
СИНТАКСИС ?
?FL = 'count_sort.pl1'
?VR = '1.1 от 04.05.19'
?MD = 'COUNT_SORT'
?VER = '1.1'
ДA = '1'B1
HET = '0'B1
?X = 64

     2019/05/08 13:28, Автор сайта          # 

64-разрядная кухня работает медленнее 32-разрядной

В случае «наивной» реализации в позиционных системах счисления двухразрядный сумматор работает медленнее одноразрядного, трёхразрядный — медленнее двухразрядного и т. д. Конечно, реализация процессоров далеко не «наивна», но с возрастанием разрядности их сложность (число логических вентилей) нелинейно растёт. Для борьбы с этим ростом процессоры упрощают, что сказывается на скорости.

P.S. Простите, я тут немного начудил с сообщениями. Но теперь восстановил, как было.

     2019/05/08 14:25, kt          # 

для VIT1972:
PLINK64.EXE это не компилятор, а контейнер со всеми утилитами (в том числе и компилятором). Что нужно вызвать — распознается по расширению или по спец. значкам перед именем. Если просто запустить контейнер без параметров, выдается подсказка. Файл с расширением PLI можно оттранслировать так:
PLINK64 * TEST.PLI

     2019/05/08 15:59, VIT1972          # 

Спасибо, а документации к нему нет. А то сложно идти на ощупь.

     2019/05/08 18:18, kt          # 

А вот ссылка в Downgrade #5, которую я давал выше. Там в zip-файле и документация в PDF-файлах.

     2019/05/08 22:57, VIT1972          # 

А то, что документация десятилетней давности, это верно? Новее нет? А то сам компилятор новый...

     2019/05/09 09:39, kt          # 

Не компилятор новый, а просто очередная сборка проведена. Поиск ошибок и недочетов идет непрерывно, поскольку мы сами активно эти средства используем и на недостатки сами наталкиваемся. Документация на 95% соответствует текущему состоянию. Вот для примера кусок протокола изменений компилятора за 2017-18 гг.

15.04.17 ОШИБКА ПОВТОРНОЙ ОПТИМИЗАЦИИ IMUL И ПОВТОРНОЙ EINTO
22.04.17 НОВАЯ КОМАНДА POP32 ЭМУЛИРУЕТСЯ ЧЕРЕЗ FLD32/FST32P
23.04.17 ОПЕРАЦИИ COP СКЛЕИВАЮТСЯ ПО 10 БАЙТ
13.05.17 "*" В FIX/BIT/FLOAT/DEC - МАКС.ЗНАЧЕН, ?X-РАЗРЯДНОСТЬ 64
25.08.17 ПЕРВАЯ ВЕРСИЯ ФИЗИЧЕСКИХ ТИПОВ
23.09.17 ПРОВЕРКИ ПАРАМЕТРОВ В ПРИСВАИВАНИИ ENTRY VARIABLE
19.10.17 ОШИБКА ОКРУГЛЕНИЯ ДО БАЙТА В C5D10, НЕВЫЗОВ ?IAB63
25.12.17 ОШИБКА INIT БЕЗ STATIC В СТРУКТУРАХ
04.01.18 ОПЕРАТОР RESIGNAL
05.01.18 ДОПУСТИМ END ON;
18.02.18 ВВЕДЕНЫ КОНСТАНТЫ FIXED BINARY(63)
10.03.18 ВОССТАНОВЛЕНА ОПТИМИЗАЦИЯ LEA С УЧЕТОМ REX-ПРЕФИКСОВ
31.05.18 РАЗРЕШЕНЫ ОПЕРАТОРЫ ВИДА I**=2;
15.06.18 ДОБАВЛЕНО VALUE
18.06.18 ДОБАВЛЕНЫ ПСЕВДОНИМЫ ПРОЦЕДУР EXTERNAL('<ПСЕВДОНИМ>')
18.07.18 VALUE ВСЕГДА INT, А НЕ EXT
17.11.18 ВВЕДЕН КЛАСС ПАМЯТИ CONTROLLED, ALLOCATION(ADDR(X));
08.12.18 ВВЕДЕНA LENGTH ОТ СТРУКТУРЫ
10.12.18 ИСПРАВЛЕНА ОШИБКА В CMP <>,КОНСТАНТА
31.12.18 ОШИБКА ИНИЦИАЦИИ АДРЕСОВ И МЕТОК

     2019/05/10 22:31, VIT1972          # 

Идеальный транслятор с точки зрения пользователя.

Результаты моих тестов оказались противоречивы. Мы прочитали точку зрения на такой транслятор со стороны разработчика. Со стороны пользователя картина такова. Разумеется, она не претендует на истину в последней инстанции и субъективна.

Достоинства.

1. Сделан в России. Может быть и недостатком (см. ниже).

2. Разработчик доступен и реагирует на замечания.

3. Бесплатность. Есть компиляторы IBM, Raincode, Micro Focus их стоимость $10-30k. Компилятор Iron Spring бесплатен, но пока не завершен. Остальные работают в экзотических экосистемах типа OpenVMS или Stratus. Может быть, стоит установить символическую цену, сажем, $5-10?

Факты, оценку которым дать не могу — для размышлений.

1. Написан на ассемблере. Быстрый, но абсолютно непортабелен. Последние лет 20-25 компилятор IBM, например, пишется на ПЛ же.

2. В целом следует стандарту subset G, но есть средства как из полного стандарта, так и дополнительные, не входящие в эти стандарты.

3. Русскоязычные операторы. Были бы очень полезны, но после реализации полного стандарта языка, или хотя бы уровня компилятора IBM.

4. Из более чем 50 протестированных мной программ почти все выдали ошибки. В силу лапидарности диагностики очень трудно понять, в чем дело. Примеры:
     26 a            DCL (I, J, LI, N, NP, L, N2, P, POL) BIN FIXED INIT(0B),
СИНТАКСИС ?
60 b S1: PROC(POL, J, M, TETA) RETURNS(CPLX(16));
СИНТАКСИС ?
Не нравятся стандартные сокращения, или что-то иное?


Недостатки и пути их устранения.

1. Сделан в России, где, главное процесс, а не результат. Большинство нижеупомянутых недостатком вызваны именно этим. Тут ничего не поделаешь.

2. Делается одним человеком в соответствии с его личными вкусами и возможностями. Ещё одна причина ряда недостатков. Максимально популяризовать, прривлекая сторонних разработчиков, пусть не самого компилятора, так его окружения.

3. Отсутствуют средства разработки. Нет редактора, отладчик в зачаточном состоянии. Нет среды. А сейчас даже у Julia, которому лет 10 от силы, имеется среда разработки. Это может оттолкнуть развращенных такими средствами программистов. Попытаться «влезть» в какую-либо открытую среду, например, Code Blocks, Geany, Eclipse.
4. Не реализованы некоторые важные и необходимые средства языка. Меня больше всего удивило практическое отсутствие CONTROLLED памяти. Мне отец рассказывал, что у них в почтовом ящике, ещё в 80-х, приказом директора было запрещено программирование на Фортране именно по причине отсутствия такой памяти и наличия ее в ПЛ. Использование Фортрана не позволяло находить ошибки типа выхода индекса массива за допустимые пределы и, вообще, вынуждало нерационально использовать память. В тех примерах, что я тестировал, примерно в половине случаев используется CONТROLLED память. Реализовать, хоть и сложно.

5. Диагностика компилятора лапидарна и, потому мало информативна. Я так и не смог вывести полный листинг программы с результатами компиляции в файл. Я понимаю, когда Intel Visual Fortran выводит ошибки вниз экрана и можно щелкнув на них выйти сразу в то место исходника, где они возникают, но тут... Увы, только детализация.

6. Документация отстает от версии транслятора на 10 лет. Т.е. новых средств за это время не добавилось, был лишь поиск ошибок и их устранение? Тут все ясно. Минимально внести описания изменений в документацию.

7. Надежды на исправление этих недостатков мало, т.к. сам автор пишет «Я не торгую трансляторами, не ищу пользователей...». Такая позиция останавливает энтузиастов, которые бы могли помочь. И тут ничего не поделать.

8. Сообщения только на русском языке. Сразу отсекает почти всех иностранцев. Лучше бы создать отдельные языковые файлы, или хотя бы возможность их подключения.

9. Хорошо бы иметь сайт, посвященный компилятору. Нет хорошо известного места, где можно скачать компилятор.

10. Поддержка только Windows.

11. Запоздалость его выхода, точнее его популяризации. Сейчас есть масса языков и сред программирования. Популяризовать. Есть сайт cyberforum.ru, там много программистов.

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

     2019/05/11 12:48, kt          # 

Никаких обид и не может быть. А конструктивная критика всегда может только приветствоваться. На некоторые вопросы попробую показать свое видение.

1. Не согласен, что главное был процесс, а не результат. Как раз главное был результат, для этого в силу сложившихся тогда условий пришлось разбираться со средствами. А потом это стихийно превратилось в хобби. Но главная программа для меня и сейчас это не компилятор, а ПО комплекса средств поддержки экипажа. На него все нацелено, этим определяется и выбор ОС. И средства приходится развивать по мере развития аппаратных средств.

2. Никогда не ставил цели реализовать «полный» стандарт и не считаю его идеалом (да и существует ли он вообще?)
Почитайте самого автора компилятора: http://rsdn.org/forum/flame.comp/6550274.1
он делал транслятор потому, что ему понравился новый язык и не нравился как раз «стандартный».

3. Мелких отличий от IBM360 полно и для тех, кто привык к этим мелочам, все это должно раздражать. Например, битовые константы пишутся не 0B, а ’0’B или не CMPLX(16), а FLOAT DECIMAL(16) CMPLX. Кстати, вопросительный знак при ошибке ставится посреди последней считанной лексемы, что может стать дополнительной подсказкой. А расширенные сообщения об ошибках можно почитать, набрав PLINK64 /?
И вывод «полного листинга программы с результатами компиляции в файл» был характерен для пакетной обработки и перфокарт. Гораздо продуктивнее иметь отдельное окно с текстом, пусть даже и редактор FAR, а второе — для запуска на компиляцию. Запустил, получил одно сообщение на экран, переключился на текст, исправил, переключился. Нажал клавишу, получил следующее сообщение и т.д. Обычно после первой же ошибки лучше исправить и все заново запустить, чтобы не возиться с наведенными ошибками. Получается как в IDE, но без всякого IDE.

4. Контроль индексов и Controlled память, по-моему, ортогональные понятия. И мы всегда старались ввести дополнительные проверки: http://rsdn.org/article/pl1/PL1ex10/pl1ex10-2.xml
Управляемую память ввели недавно, с некоторыми упрощениями: http://compiler.su/o-razmeschenii-peremennyh-v-steke.php

5. Сайт, возможно, в ближайшее время оживет. Но там «движущая сила» не я.

В конце концов, все перечисленное не главное. Главное, как я понял, предложение приложить усилия, чтобы «выйти на рынок». К возможности успеха, тем более, коммерческого, я отношусь скептически. Хотя в свете шума об импортозамещении шансы не нулевые. Например, в реестре зарегистрированного российского ПО в разделе «компиляторы» по-прежнему пусто. Но заниматься всем этим должен, конечно, не один человек.

     2019/05/11 14:16, VIT1972          # 

По пунктам:

1. Пусть для Вас главное это ПО комплекса. Но тут и на rsdn.org Вы пишете о компиляторе! Он как-то развивается, но это никак не отражено, например, в документации.

2. Так и не надо реализовывать полный стандарт! Стандартом де факто является компилятор IBM. Все остальные сейчас стремятся ориентироваться на него. Пусть не все его возможности будут реализованы сразу. И, простите, но в конце первой четверти XXI века Килдалл не может быть окончательным авторитетом. Может, как-то помошников поискать-привлечь? Тот же Iron Springs...

3. Вот эти мелкие отличия и портят всю картину. Хорошо бы иметь ключ, который бы включал или стандарт, или Ваш подход. Отсутствие полного листинга я упоминал только в связи с отсутствием средств разработки. Заметьте, это пишу я, который лет 20 назад работал в примерно таком же окружении, которое Вы описали! Что говорить о молодежи? Да, можно обходиться FARом, но тогда совсем непонятно, зачем созданы десятки IDE? Кроме того, мелкие отличия затрудняют переход от того же IBM компилятора, т.е. создают проблему, где ее быть не должно!

4. Я, в силу своей малограмотности, не разделяю понятий контроль индексов (что это такое?) и управляемая память. Но вот, посмотрите, пожалуйста, на простую программу, которая типична (по крайней мере, для моих случаев):
 tctl: proc options(main);
declare (i,j) fixed initial(50),
a(*,*) float controlled;
allocate a(i,j)
free a;
end;
Она у меня компилироваться не хочет. Более того, есть один из вариантов обхода использования управляемой памяти (см. http://rosettacode.org/wiki/Gaussian_elimination#PL.2FI). Но и его компилятор не принимает. Кстати, обратите внимание, что Вы отсылаете не к документации, а к различным рассеянным источникам.

5. Дай, Бог! Будет единое место для всей информации.

6. "Выйти на рынок", наверное, громко сказано. Я бы начал с популяризации. Самыми важными, на мой взгляд, действиями будут "англоизация" компилятора и встраивание его в какую-либо бесплатную IDE (Eclipse, CodeBlocks). Оптимально в Visual Studio, но насколько это реально?
А установить символическую стоимость (с пожизненными обновлениями), возможно и стоит. Это позволит хотя бы как-то окупить расходы на тот же сайт или интеграцию в IDE. Кроме того, не забывайте про стоимость компиляторов и такие деньги платятся! Вот бы привлечь внимание, тех, кто платит!

     2019/05/11 15:09, kt          # 

Контролем индексов я называю автоматическую проверку выхода индексов массивов за заданные границы. В процессоре даже была специальная команда HBOUND, которую потом, правда, выкинули. Попытка запустить вот такую программу с контролем индексов:
TEST:PROC MAIN;
DCL X(10,20) FLOAT,
(I,J) FIXED(31);
I=5;J=20;
X(I+1,J+1)=1E0;
END TEST;
Приведет вот к такому результату:
ОШИБКА (16) A:0040125F 0005 TE, ИНДЕКС ВНЕ ГРАНИЦ
(0040120A) СТЕК: 00402201 00000000 # 00402071 00000000
Конец программы
Обратите внимание, что в данном случае выхода за пределы памяти массива нет, но единица запишется не туда, если контроля индексов нет.

А пример, который Вы привели — это т.н. динамический массив. В стандарте «G» его нет, границы индексов массивов должны быть константами. В свою очередь, динамический массив может иметь или не иметь контроль выхода индексов за границы. От класса выделяемой памяти напрямую это не зависит. Динамический массив должен иметь так называемый «паспорт», т.е. текущие значения границ индексов. Поэтому работа с динамическими массивами идет медленнее, чем со статическими. Из одномерного массива можно сделать некоторый аналог динамического, если задать в описании одну границу, а память выделить, сколько нужно. Например:
DCL X(1_000_000_000) FLOAT BASED(P), P PTR;
ALLOCATE(1000*4) SET(P);
Здесь памяти выделено только на 1000 элементов, а не на миллиард. Управляемая же память CTL — это автоматическое создание отдельного стека для каждой переменной.

     2019/05/11 16:45, VIT1972          # 

Так контроль индексов это же состояние SUBRG! И сделайте, пожалуйста, где-нибудь в облаке что ли ссылку на последнюю версию компилятора с документацией. Ну, и обновлять ее надо.

     2019/05/11 16:53, VIT1972          # 

Специально посмотрел Iron Spring. Он все же стремится к поддержке полного стандарта. CTL реализован с незначительным ограничением: длины и границы должны быть объявлены, т.е. не могут быть константами. И, что просто удивительно, пишут, что среди клиентов уже сейчас есть госучреждения.

     2019/05/11 18:53, kt          # 

Ну да, состояние SUBSCRIPTRANGE, оно же здесь ERROR(16). Но ведь само по себе оно не возьмется, нужно проверки включать в код. А для многомерного массива каждый индекс отдельно проверять приходится, сумма адресов может не показать выход за границы всего массива.

Ссылку на РСДН пока считаю достаточной, это нормально поддерживаемый сайт, кстати российский. Напоминаю, компилятор не основная моя деятельность, а основное средство программирования разнообразного прикладного ПО. Продвигать компилятор по серьёзному нет ни сил, ни времени. Да и отношение к этому языку пренебрежительное. Зачем же сразу становиться в проигрышную позицию: дескать, попробуйте, ну пожалуйста... А вот для тех, кто и без упрашивания заинтересовался, прятать ничего не буду.

Нет ничего удивительного, что в США на этот язык спрос ещё остается. Там ещё много специалистов и пользователей с огромным опытом. Например, его используют внутри IBM (сын одного из коллег, там работающий, подтвердил). Iron ведет практически один энтузиаст. Я сталкивался с этим продуктом:
http://rsdn.org/forum/flame.comp/7002004.1
и после этого добавил в компилятор объекты Value

     2019/05/11 20:19, VIT1972          # 

А, кстати, где можно найти стандарт G? Нигде не могу найти...

     2019/05/11 21:56, kt          # 

ANSI X3.74-1987 (R1998), он же ISO/IEC 6522:1992 можно скачать на сайте ISO, но он там стоит $250. Поэтому ни у кого из любителей этого стандарта (как выяснилось на форуме https://groups.google.com/forum/#!forum/comp.lang.pl1) не оказалось. Но вот реализация фирмы «Wang» любезно включала раздел отличий от IBM. Этот раздел и «выдает» все особенности стандарта «G». Это раздел 24 в имеющейся документации PL-KT.

     2019/05/12 00:22, VIT1972          # 

Жаль, а то полный есть, а G нету...

     2019/05/12 10:15, Виктор          # 

У меня нет разумной гипотезы, почему заполнение массива не нулями так влияет на скорость.

Видимо UNDERFLOW не возникает и не тратится время а его обработку.

     2019/05/12 10:18, Виктор          # 

Оптимизатор IBM творит чудеса, но на современных процессорах это дает всё меньший эффект.

Ну тут все относительно. Ещё на ЕС-1045 он на максимальной оптимизации чуть выигрывал у стандартного Фортрана, но проигрывал раза в полтора-два Фортрану VS2.

Сейчас с PG Фортраном ситуация примерно та же, хотя возраст, конечно, продуктов не сравнить.

     2019/05/12 11:17, kt          # 

Интуитивно кажется, что замена внутри FPU исчезновения порядка нулем не должна вызывать таких временных потерь. Но поскольку у меня и такой гипотезы нет — принимаю Вашу. Вы же можете провести разные проверки с IBM транслятором. Интересно, какой код он сгенерирует, если добавить
ON SUBSCRIPTRANGE BEGIN; PUT SKIP LIST('ERROR’,I,J); STOP; END;
Будет ли он тогда «честно» считать индексы? И, к слову, Ваш ЖЖ — это какой?

     2019/05/12 11:26, Виктор          # 

Конкретный пример очень специфический, но, вероятно, имеет смысл, поскольку напоминает моделирование распространения чего-то в чем-то

В общем-то решение стацинарного уравнения теплопроводности методом Либмана.

Специально посмотрел Iron Spring. Он все же стремится к поддержке полного стандарта.

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

Есть компиляторы IBM, Raincode, Micro Focus их стоимость $10-30k.

Демо-версия IBM с фикспаками лежит открыто у них на сервере, любой фикспак превращает триал в полноценный продукт. Хотя, возможно, есть какие-то ограничения в лицензионном соглашении на коммерческое использование.

     2019/05/12 11:29, Виктор          # 

И, к слову, Ваш ЖЖ это какой?

https://theriodont.livejournal.com/14007.html#comments

     2019/05/12 11:45, Виктор          # 

Интересно, какой код он сгенерирует, если добавить
ON SUBSCRIPTRANGE BEGIN; PUT SKIP LIST('ERROR’,I,J); STOP; END;
Будет ли он тогда «честно» считать индексы?

Залил ассемблерный текст:

https://cloud.mail.ru/public/Jv8a/5bKyNaxd4

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

     2019/05/12 12:27, Виктор          # 

Поправка: просто включение почти ничего не изменило, а вывод индексов сразу затормозил в три раза.

     2019/05/12 12:50, VIT1972          # 

Демо-версия IBM с фикспаками лежит открыто у них на сервере

Это очень старый продукт. IBM компилятор для Windows не обновлялся, думаю с 1995. Максимум, что для него делали — это добавляли новые средства языка. Ни о каких оптимизациях там речи не идёт. А вот те, что для мейнфреймов, по отзывам просто великолепны. Я просил знакомых прогнать мою задачу (у меня считалась на паре E5-2698) на z14. Даже со скидкой на более быстрые процессоры z14 разницу в 28 раз только процессорами не объяснить. Там просто совсем другой компилятор.

     2019/05/12 13:13, kt          # 

Спасибо. Да, можно заставить считать. И тогда всякие выкрутасы с лишними командами начинаются, вроде вот этого:
	movsx	ebx,word ptr [ebp-0186h];	J
movsx edx,bx
Такие несуразные команды мне знакомы :) Впрочем, мне хвастаться тоже нечем. Хотя в моем варианте индексы и так считались, и код увеличился несильно, проверки сразу нарушают свертку в SIB-адресацию и все замедляется не в три, а раз в пять.

А вот совет использовать только для отладки неоднозначный. Как и вообще концепция двух трансляторов. Получается, что отлаживаемся на одних командах, а «штатная» работа совсем на других. На своем основном ПО мы плюем на замедления и включаем все проверки. Отладка и работа идет строго на одних и тех же командах. Иначе концов ошибки не найдешь.

     2019/05/12 14:29, Виктор          # 

Это очень старый продукт. IBM компилятор для Windows не обновлялся, думаю с 1995.

Да там судя по всему и с 70-х в принципе мало что поменялось, кроме архитектуры.

     2019/05/12 16:32, Автор сайта          # 

Чтобы поддерживать планку «на уровне», надо целиком посвятить себя своему детищу. Надо, чтобы этим занимался хотя бы один человек — и не на полставки, и тем более не на 5%. Чтобы обеспечить кусок хлеба единственному человеку (который и программист, и тестировщик, и маркетолог, и технический писатель, в т.ч. на английском языке!), нужно постоянно продавать компилятор на сумму, превышающую зарплату этого единственного работника.

Российский рынок сбыта не обеспечит таких продаж. Неоднократно читал такое, что «зарубежные продажи моего программного продукта дают на порядок больше, чем российские».

Вот бы привлечь внимание, тех, кто платит!
нет ничего удивительного, что в США на этот язык спрос ещё остается.

Вывод: хочешь добиться успеха — выходи на этот рынок.

Продвигать компилятор по серьёзному нет ни сил, ни времени.

Дмитрию Юрьевичу нужен «толкач». Как в своё время Наталья Касперская дотолкала антивирус имени себя и мужа до мирового лидерства. Без неё этот продукт остался бы на уровне Dr.Web. Но это если верится в перспективу, что с этим компилятором можно чего-то добиться.

     2019/05/13 16:53, kt          # 

Вот тебе раз! Проверил тест на процессоре AMD A6-9220 RADEON R4 2,50 GHz. И там совсем не такие результаты!
IBM транслятор (файл HEATU.EXE) — 597 миллисекунд
PL-KT 32 разряда — 616
PL-KT 64 разряда — 636
Т.е. разница стала незначительной. Но при этом заполнение 1E-30 для ускорения не требуется! И без этого заполнения даже чуть быстрее — 610 миллисекунд. Т.е. результаты сильно зависят от типа процессора и, вероятно, от типа памяти.

     2019/05/14 12:19, VIT1972          # 

Замечания по последним ремаркам:

1. Вызывает удивление фраза

А вот совет использовать только для отладки неоднозначный. Как и вообще концепция двух трансляторов. Получается, что отлаживаемся на одних командах, а «штатная» работа совсем на других. На своем основном ПО мы плюем на замедления и включаем все проверки. Отладка и работа идет строго на одних и тех же командах. Иначе концов ошибки не найдешь.

Т.е. рабочая программа должна быть ЗАВЕДОМО неэффективной? А почему практически в всех современных компиляторах есть режимы отладки и рабочей программы (Debug/Release)?
SUBRG именно для этого и создан.

2. В этой же связи. В том числе отсутствие CTL памяти и вызывает описанные в п.1 вещи. Ибо, когда границы массива описаны точно и это проверено на этапе отладки, зачем их проверять всегда?

3. Ссылки на Subset G.

3.1. Так он и был создан для реализации языка на PC. В то время — это IBM PC XT в лучшем случае. Уже 486 превосходил по скорости и памяти S360 и EC. А даже там был реализован иной стандарт языка.

3.2. Сама ссылка на какой-либо стандарт при наличии в компиляторе массы уникальных нововведений некорректна.

4. Честно говоря, мне непонятны сравнения скорости работы со старым компилятором IBM. Мало того, что он старый, так в https://groups.google.com/forum/?fromgroups#!forum/comp.lang.pl1 было обсуждение, что в нём ещё и ошибки есть. Обогнать программой, написанной в 2019, написанную (причём без небрежно) в 1995. Где здесь интерес-то?

5. Очень жаль, что Дмитрию Юрьевичу достался для переработки компилятор Килдалла, а не IBM :)

6.

Сейчас с PG Фортраном ситуация примерно та же, хотя возраст, конечно, продуктов не сравнить.

Думаю, что Intel Visual Fortran обыграет PG везде, кроме режимов Cuda (которые он просто не поддерживает).

7. Безо всякой подначки. Дмитрий Юрьевич, а сколько людей используют Ваш компилятор? В скольких организациях?

8. Насчёт "толкача". Не думаю, что Дмитрию Юрьевичу понравится наличие человека, указания которого будут обязательны к исполнению. А менеджер проекта как раз и должен обладать такими правами. Да его ещё и найти надо.

     2019/05/14 16:28, theriodont          # 

Думаю, что Intel Visual Fortran обыграет PG везде, кроме режимов Cuda (которые он просто не поддерживает)

На данной тестовой задаче оно (PG) быстрее IBM само по себе раза в полтора, но использование конструкции forall вместо вложенных циклов дает плюсом выигрыш ещё минимум раза в 2, причем без использования многопоточости или GPU. Интел заполучить всем желающим, увы, не так просто.

Кстати, нормально распараллелить в Фортране программу с чуть более сложной логикой (например с явной схемой предиктор-корректор), используя только OpenMP или OpenACC уже сложнее, чем вручную подключая потоки на IBM PL/I — там всё делаешь как тебе угодно, а не как решит компилятор.

     2019/05/15 17:14, kt          # 

Замечания на замечания.

1. Задачи бывают совершенно разные. Например, наша главная программа — отображение полётной обстановки — характерна тем, что её состояние в любой момент времени уникально. И если в маленьком тесте всё повторяется, то здесь нужно быть готовым к регистрации любых ошибок и к постоянным проверкам, иначе придется анализировать не сами ошибки, а их последствия, что бывает очень трудно.

2. Так и не понял, причем здесь CTL-память. А проверяются не границы массива, а попадание в них текущего индекса, который может вычисляться сложным и потенциально ошибочным образом, а не монотонно и предсказуемо, как в тесте.

3. Если расширения не противоречат исходному стандарту, ссылка на него корректна. Стандарт G разрабатывался до появления PC, я давал ссылку на книгу Килдэлла. Одна из целей нового стандарта — создание более компактного языка. Сейчас бы стандарт G засчитали бы как новый язык.

4. Приёмы трансляции и оптимизации разрабатывались с конца 50-х, компилятор IBM впитал очень много и получился очень высокого качества. Это качество сохраняется и для IA-32. «Старость» — это очень условно. Пользуетесь же Вы полиномами Чебышева (внутри FPU) или совсем древними синусами — и ничего, не жалуетесь на их древность. Маленький тест, на котором сравнивались трансляторы, написан нормально, а не небрежно. И результат получился поучительный. Например, я не предполагал, что используемый режим FPU такой затратный по времени в процессорах Intel. Теперь буду знать.

5. Транслятор IBM не мог оказаться у меня в 1987 году, поскольку для PC его тогда еще не было, а Килдэлл уже 4 года продавал свой PL/I-86. Который, кстати, имел микроскопические размеры и был вполне познаваем одним человеком, новичком в х86.

7. Понятия не имею, сколько и где используют PL-KT. Они же у меня не регистрируются. Например, число скачиваний с DownGrade неизвестно, да и новое скачивание — это вовсе не новый пользователь. В РКК как средство программирования его используют лишь 5 человек по трём темам. Но не жалуются, а наоборот, хвалят за то, что есть обратная связь и устранение ошибок.

8. Тут надо, прежде всего, определиться с целью. Например, если цель — коммерческий проект, это одно. Если эксперимент по развитию языка — другое. Разумеется, мы и дальше будем его применять и развивать, как считаем нужным, независимо от появления новых участников и пользователей. Но это и не значит, что я буду диктовать всем своё видение как окончательное и непререкаемое.

     2019/05/15 17:54, VIT1972          # 

Отвечаю по порядку.

1. Это я все писал к тому, чтобы ввести два режима: Debug/Release.

2. Имеется в виду, что при описании a(50000, 50005) всегда используется вся заявленная память. При этом для реальной задачи, где требуется только NБ<<50000, все Ваши проверки выхода индекса бесполезны. В случае dcl a (n, n+5); allocate a; они очевидно имеют смысл.

3. Хорошо, стандарт G создавался для миникомпьютеров. Что это меняет, если их мощности выросли на порядки? Все работающие ныне компиляторы поддерживают полный стандарт. Что Вам мешает сделать тоже самое, кроме личных пристрастий?

4. Именно этот IBM компилятор для Windows на протяжении всей своей истории (20+ лет!) содержал ошибки (что-то с комплексными числами). Он генерирует код максимум для Pentium 1, даже не Pro. Что интересно, компилятор для мейнфреймов таких ошибок не имеет минимум лет 15. Сможете дать пример столь долгоживущей ошибки в компиляторе? Это много говорит об отношении к нему разработчика, которому впервые указали на ошибки в 1995.

5. Понимаю, но он может оказаться у Вас сейчас... Почему бы из него не сделать конфетку? Он всё же ближе к современности, чем PL-86.

7. Жаль, очень интересно знать. Но это, скорее для информации.

8. Так можно и объединить цели. В любом случае хорошо сделать такое, чем бы пользовались и развивали потом... Сейчас это во многом вещь в себе.

Дополнение.
1. Есть ли надежда, что управляемая память будет введена?
2. Что будут распознаваться сокращения операторов?
3. Что-нибудь для среды делается?
4. Вы не пытались связываться с автором Iron Springs? Есть еще умерший проект на GCC, с ним тоже нет? Может стоит как-то объединить усилия? Пусть даже не сливаясь в один проект.

     2019/05/16 12:47, kt          # 

Ну, что же. Отвечу на ответы. Получается уже как в частушке: «из ракеты по антиракете анти-антиракеты летят...»

1. Режимы отладки в PL-KT задаются ключами Q, R, T и X. Их можно использовать по отдельности, самый дорогой, разумеется, контроль индексов Т.

2.

все Ваши проверки выхода индекса бесполезны.

В результате ошибок в больших программах может портиться память, а это значит, например, что индекс «сам собой» обнулится, или какая-нибудь граница цикла испортится, или ещё что-нибудь весёлое произойдет. Кстати, в этом случае IDE обычно бесполезны, для них такие ошибки всегда из серии «не может быть никогда».

3. Стандарт G создавался не для миникомпьютеров, а просто д-р Фрайбургхаус хотел создать более совершенный язык. Он пригласил на заседания специалиста №1 по микропроцессорам, поскольку ошибочно посчитал, что тот уже реализовал PL/1. На самом деле, придуманный Килдэлом ассемблер был назван похоже: PL/M. И это сбило всех с толку, даже Википедию.

Не все работающие компиляторы поддерживают «полный» стандарт и я тому пример. Стандарт G, кстати, международный, и создан также для того, чтобы на его базе создавалось ПО.

Что Вам мешает сделать то же самое, кроме личных пристрастий?

Так ведь и Вам ничего не мешает :) А вообще-то мешает то же самое, что Э. Маску сделать ракету для пилотируемого полета на Марс: чудовищные затраты при сомнительном результате.

4.

Сможете дать пример столь долгоживущей ошибки в компиляторе

Конечно, например, записывая сегодня тест (который ниже) я обнаружил, что не могу написать
RETURN(ADDR(...
Этот ляпсус не заметил Килдэл в 1984 году, я никогда до этого так не писал. Любой сложный компилятор содержит ошибки, на которые программисты, возможно, так никогда и не выйдут.

5.

Почему бы из него не сделать конфетку?

Понятие «конфетка» очень субъективно. По мне язык безо всякой ерунды вроде индексно-последовательных файлов (современные БД лучше и проще), без возможности неописанных переменных (бешеный источник ошибок) и, например, с необязательным ключевым словом «CALL» гораздо вкуснее.

8.

Сейчас это во многом вещь в себе.

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

Есть ли надежда, что управляемая память будет введена?

Чего все так прицепились к этой памяти? Переменные класса CTRL я недавно ввел с некоторыми упрощениями. Это приведено здесь же, в заметке «о размещении переменных в стеке». Но Вам же, насколько я понимаю, нужны массивы с задаваемыми границами? Я вот простейшим образом смоделировал такой массив для исходного теста (текст программы ниже).
Ну и просела скорость раза в три. Пусть даже при таком моделировании часть времени расходуется на вызов подпрограмм и передачу параметров — всё равно динамический массив
объективно раздувает код и снижает скорость доступа по сравнение со статическими границами, как бы хорошо он не был реализован.

Что будут распознаваться сокращения операторов?

Это о чем? Сокращенная форма ключевых слов или множественные присваивания? Или что?

Что-нибудь для среды делается?

Конечно, FAR ставится на все компьютеры :)

Вы не пытались связываться с автором Iron Springs?

С Петером Флассом мы живем в разных вселенных. Поэтому ничего не получится. Кстати, австралийско-калифорнийское сообщество любителей PL/1 весьма кисло восприняло весть, что кто-то там из дикой России пытается что-то делать с их любимым и непревзойденным средством.

Далее текст программы, где двумерный массив T, заменен одномерным X с моделированием динамических границ. Компилятору придется генерировать похожие команды.
A1:PROC OPTIONS (MAIN);

//---- ОСОБЕННОСТИ КОНКРЕТНОЙ СИСТЕМЫ ----
DCL

?MEMORY FIXED(31) EXT INIT(-1), // РАЗМЕР РЕЗЕРВИРУЕМОЙ ПАМЯТИ
?MASK_87 BIT(8) EXT, // МАСКА FPU
?M_TIME FIXED(31) EXT, // ТЫСЯЧНЫЕ ВРЕМЕНИ
?TST387 ENTRY; // УСТАНОВКА FPU

?MASK_87='00001101'B; // МАСКА ИСПРАВЛЯЮЩАЯ АНТИПЕРЕПОЛНЕНИЕ НА НОЛЬ
?TST387; // УСТАНОВИЛИ СОСТОЯНИЕ FPU БЕЗ АНТИПЕРЕПОЛНЕНИЯ

//---- СОБСТВЕННО ПРОГРАММА ----
DCL
X(1_000_000_000) FLOAT(24) BASED(P), // ЧТОБЫ МАССИВ БЫЛ НЕ В ФАЙЛЕ
F FLOAT(24) BASED,
P PTR,
MATRIX FILE, // ЧТОБЫ ОТВЕТ ВЫДАВАЛСЯ НЕ НА ЭКРАН
T1 FLOAT(24),
DTM FLOAT(24),
(I1,I2) FIXED(*),
(I,J,L,N) FIXED(*),
TIME1 CHAR(8),
(DD2,DD1) FIXED(31);

N=5000;

ALLOCATE (N*N*4) SET(P);

T:PROC(I,J) RETURNS(FLOAT);
DCL (I,J) FIXED(*);
RETURN(X((I-1)*N+J));
END T;

T2:PROC(I,J) RETURNS(PTR);
DCL (I,J) FIXED(*);
DCL P PTR;
P=ADDR(X((I-1)*N+J));
RETURN(P);
END T2;
DO I=1 TO N;
DO J=1 TO N;
T2(I,J)->F=1E-30;
END J;
END I;

DO I=1 TO N; T2(1,I)->F=1; T2(I,1)->F=1; END I;

DO L=1 TO 10000;
DTM=0;
DO I=2 TO N-1;
I1=I-1; I2=I+1;
DO J=2 TO N-1;
T1=(T(I1,J)+T(I2,J)+T(I,J+1)+T(I,J-1))/4;
DTM=MAX(ABS(T1-T(I,J)),DTM);
T2(I,J)->F=T1;
END J;
END I;

DD2=DD1;
TIME1=TIME;
DD1=SUBSTR(TIME1,1,2)*3600_000+
SUBSTR(TIME1,4,2)* 60_000+
SUBSTR(TIME1,7,2)* 1_000+?M_TIME;
PUT SKIP EDIT(L,DTM,DD1-DD2)(F(5),X(1),E(14),F(5));

END L;

PUT SKIP(2) LIST(TIME,'ЗАПИСЫВАЕТСЯ ОТВЕТ В ФАЙЛ MATRIX.TXT');
OPEN FILE(MATRIX) PRINT TITLE('MATRIX.TXT') LINESIZE(250);

END A1;

     2019/05/16 13:36, kt          # 

Для theriodont

Разница во времени теста между Intel и AMD по моему мнению может быть обусловлена двумя причинами:

1. Дольше обращение к памяти. Тогда разница между 40 и 100 командами цикла теста снижается из-за того, что не они дают главный вклад по времени.

2. Дольше выполнение команд FPU. У транслятора IBM они идут подряд, а у PL-KT между ними расчет индексов. По результату похоже, что в AMD индексы успевают сосчитаться до окончания очередной команды FPU. Но зато у AMD выключение антипереполнения в FPU ничего не стоит :)

     2019/05/16 19:13, VIT1972          # 

Ещё ответы.

1. Это я писал, сидя в Visual Studio. Там так, и я привык. Так значит, контроль индексов всё же можно отключить?

2. Я писал немного про иное. Если брать размер массива заведомо больше реального, то отладка усложнится. Существенно.

3. Т.е. язык без динамической памяти, более совершенен, чем с ней? Тогда Fortran 4 просто убивает всех! Вот только на нём никто уже не пишет.

Да, в смысле поддержки стандарта G? исключение. Кроме PL на умерших VAX и Itanium я никого не вспоминаю. Сегодняшние коммерческие поддерживат все.

Мне мешает полное отсутствие опыта в создании и модификации компиляторов. Тут я всего лишь пользователь. Но если взять и раздраконить IBM компилятор... то тут у нас уже есть специалисты.

4. Т.е. ошибка в арифметике(!) для компилятора, обычное явление?

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

8. Т.е. Вам совсем не хочется привлекать новых пользователей? Имеете право.

Насчет управляемой памяти я вроде тут один пишу. Просто, понимаете, есть задачи, в которых в исходные данные входят несколько массивов с неизвестными заранее границами.

Я имел в виду сокращенную форму ключевых слов. У меня куча ошибок высыпалась...

Шутку насчет FAR я оценил. Совершенство минималистично, но не аскетично.

Насчет отношения иностранцев к Вашей работе я думаю, что проблема здесь в языке. Как бы Вы отнеслись к компилятору на китайском? Просто надо им показывать то, что они могут использовать. Жаль, что очень хорошие специалисты не могут пользоваться Вашей замечательной программой. Они могут дельное посоветовать.

Вашу модельную программу посмотрю. Т.е. Вы в принципе знаете, как реализовать управляемую память?

     2019/05/17 03:24, theriodont          # 

Именно этот IBM компилятор для Windows на протяжении всей своей истории (20+ лет!) содержал ошибки (что-то с комплексными числами).

Там неверно считает действительную часть в выражениях типа A=A+B, если A и B - complex float (с complex fixed все ок).

https://cloud.mail.ru/public/zuCo/5CoBZ7Z7F

Причем говорят, что это свойственно всем компиляторам IBM, где есть complex, не только PL/I.

Кстати, использование controlled с переменными границами вместо static замедляет программу процентов на 20.

Шутку насчет FAR я оценил.

FAR-овский редактор кстати один из немногих, который умеет парсить PL/I, (почему-то только если расширение *.pli набрано строчными буквами). Тоже пользую FAR + скрипт на rexx-е, поскольку родное IDE там жесть жестяная.

     2019/05/17 05:58, kt          # 

Кроме PL на умерших VAX и Itanium я никого не вспоминаю.

PL/I фирмы Wang на одноименных компьютерах у нас использовали до начала 90-х.

Т.е. ошибка в арифметике(!) для компилятора, обычное явление?

Это не арифметика (функция ADDR, а не ADD). Вот так можно:
P=ADDR(X(I,J)); RETURN(P);
А вот так ошибка:
RETURN(ADDR(X(I,J));
И никто из нас не наталкивался до вчерашнего дня. Невозможно придумать тесты, покрывающие все случаи. Со временем исправлю, раз уж нашёл.

     2019/05/17 10:12, VIT1972          # 

Это не арифметика (функция ADDR, а не ADD).

Все же арифметика. Посмотрите тут
https://groups.google.com/forum/?fromgroups#!topic/comp.lang.pl1/7yhgU-08hQs
В компиляторах для z/OS её нет. Кстати, само её такое долгое наличие говорит о частоте использования языка в научных расчетах.

И никто из нас не наталкивался до вчерашнего дня. Невозможно придумать тесты, покрывающие все случаи. Со временем исправлю, раз уж нашёл.

Это Вы про IBM? Вы утверждаете, что не тестировать элементарную арифметику нормально?

Тоже пользую FAR

На безрыбье... Но никто же не будет утверждать, что FAR лучше VS или какой-либо Geany?

     2019/05/17 11:32, kt          # 

Я говорю не об ошибке комплексной арифметики в трансляторе IBM, а об ошибке адресного выражения в PL-KT

     2019/05/17 13:52, theriodont          # 

На безрыбье... Но никто же не будет утверждать, что FAR лучше VS или какой-либо Geany?

К Geany и так при желании можно хоть что прикрутить.

     2019/05/17 14:17, VIT1972          # 

К Geany и так при желании можно хоть что прикрутить.

Как, впрочем, и к VS

     2019/05/17 14:29, kt          # 

Я имел в виду сокращенную форму ключевых слов. У меня куча ошибок высыпалась...

Отсутствующие сокращения можно добавлять и самому в начале текста, например:
%REPLACE 
FIX BY FIXED,
ALLOC BY ALLOCATE,
...
Тогда, по крайней мере, сами тексты трогать не требуется.

     2019/05/17 14:33, theriodont          # 

В компиляторах для z/OS её нет. Кстати, само её такое долгое наличие говорит о частоте использования языка в научных расчетах.

В OS/2 кстати та же фигня. Хотел проверить что там у Iron Sring на этот предмет, но он, оказывается, ещё не умеет в комплексные выражения.

Для научных расчетов всегда был и есть Фортран, на практике PL/I для этого использовали только очень большие любители прекрасного.

     2019/05/17 20:26, VIT1972          # 

theriodont
В OS/2 тоже? Такое ощущение, что все IBM продукты с косой чертой уходяи в маргинальную область...

В какой-то теме в google-группе писали, что в z/OS нет, да и мои результаты это подтверждают. Они даже петицию в IBM составляли, ответ: "Windows-компилятор не поддерживатся". Iron Spring это точно обойдёт, он дискуссию видел. И компилятор у него во многом на исходниках Multics, и сам он вроде в разработке PL/I на Multics участвовал. Вот только когда... Лет ему уже много...

Дмитрий Юрьевич! Спасибо, так можно, просто столько переделок уже тянет на перевод на другой язык. Помимо Фортрана, который по возможностям лет 10 как обогнал PL (последняя нереализованная в Фортране возможность PL, с которой я сталкивался, это вывод по PUT DATA CTL-массива, реализована лет 5 назад), еще и Julia хвалят, но не пробовал.

     2019/05/20 12:48, theriodont          # 

Помимо Фортрана, который по возможностям лет 10 как обогнал PL (последняя нереализованная в Фортране возможность PL, с которой я сталкивался, это вывод по PUT DATA CTL-массива, реализована лет 5 назад)


Вроде ALLOCATABLE было еще в Ф90, а NAMELIST так и вообще при царе-горохе, или я чего-то не понял?

В современном фортране есть всё, что нужно растениям, но нет той красоты и целостности. Чем-то путь его развития сходен с C++.

     2019/05/20 14:51, VIT1972          # 

Вроде ALLOCATABLE было еще в Ф90, а NAMELIST так и вообще при царе-горохе, или я чего-то не понял?

Это так, но сочетание
A(N)CTL; 
ALLOCATE A;
GET DATA(A);
не имело перевода на Фортран (даже по стандарту) года до 2010.

В современном фортране есть всё, что нужно растениям, но нет той красоты и целостности. Чем-то путь его развития сходен с C++.

Т.к. я C не знаю, судить не могу, хотя мне всегда казалось, что он как раз становится ближе к PL. Взять тот же ALLOCATABLE или форматный ввод-вывод...
Он стал более эклектичным, но то же самое можно сказать и о PL.

     2019/05/20 14:52, VIT1972          # 

и еще правку своего сообщения добавить бы неплохо.

     2019/05/20 17:00, theriodont          # 

Ну вот так скажем:
REAL, ALLOCATABLE:: A(:)
NAMELIST/BAA/A
ALLOCATE (A(N))
READ(*,BAA)
С разницей только что в списке придется ставить заголовок и конец.

Т.к. я C не знаю, судить не могу, хотя мне всегда казалось, что он как раз становится ближе к PL.

Я имею в виду, что на изначально простой и небольшой язык лепили потом кто во что горазд и как попало. ПЛ/1 тоже менялся, но в гораздо меньшей степени. Фортран сначала в общем-то тоже стал ближе к ПЛ/1, но потом ушёл дальше. Но вот даже вот эти двоеточия уже сами по себе выглядят коряво.

     2019/05/20 17:21, VIT1972          # 

Ну вот так скажем:

REAL, ALLOCATABLE:: A(:)
NAMELIST/BAA/A
ALLOCATE (A(N))
READ(*,BAA)

С разницей только что в списке придется ставить заголовок и конец.

Сейчас пройдёт, а на Intel до 2010 — нет. Я даже в стандарте это находил, мне надо было перевести как раз с PL. Двоеточия и меня бесят. Именно этот вариант на PL и сейчас выглядит лучше. Фортран просто часто менялся, разными людьми, даже поколениями разными. Потом они стремятся сохранить поддержку старых версий языка (вот как NAMELIST). Одна история с FORALL чего стоит — сегодня ввели, завтра убрали (кстати, потому, что трудно реализуемо в компиляторе!)

     2019/05/21 20:13, theriodont          # 

Ну пока не убрали, а перевели в разряд нерекомендуемых, поскольку много ограничений — то есть в общем случае (в т.ч. и в моем примере) код нужно переписывать, чтобы заменить циклы на forall и оно работало. Do concurrent теперь по идее делает то же самое, но без ограничений. Еслм так оно и есть, то смысла в нем действительно не осталось.

     2019/05/22 10:22, Автор сайта          # 

австралийско-калифорнийское сообщество любителей PL/1 весьма кисло восприняло весть, что кто-то там из дикой России пытается что-то делать с их любимым и непревзойденным средством.

Гм… Интересно, а как выглядели кислые мины?

Понятия не имею, сколько и где используют PL-KT

Думаю, прямо на эту страницу можно поставить URL для закачки со счётчиком. Тогда бы хоть какая-то статистика собиралась.

RETURN(ADDR(...
Этот ляпсус не заметил Килдэл в 1984 году, я никогда до этого так не писал. Любой сложный компилятор содержит ошибки, на которые программисты, возможно, так никогда и не выйдут.

С одной стороны, слышишь призывы делать компиляторы «по науке», тогда и ошибок будет меньше. Мнение Дейкстры:

В шестидесятые годы она [наука] разработала теорию синтаксического разбора, необходимую для поднятия уровня компиляторов выше уровня поделок, напичканных ошибками, и превратив её в предмет, пригодный для обучения. Это было главное достижение: я, например, помню весьма отчетливо, как в 1962 те из нас, кто действительно написал компилятор, выглядели в глазах остальных как некие полубоги. В связи с этим достижением я бы хотел подчеркнуть, что этого никогда бы не произошло, если бы мы со временем не научились давать формальное определение синтаксиса компилируемого языка: без этого формального определения слишком сложно было бы определить существование проблемы компиляции.


С другой стороны, Зуев Евгений Александрович делал свой компилятор C++ «по науке» (lex/yacc), но и он пишет о трудноуловимых ошибках и большой роли тестов, которые должны покрывать весь синтаксис языка. Вероятно, для PL1-KT нет таких всеобъемлющих специально написанных тестов.

P.S. Добавлена кнопка «Предварительный просмотр».

     2019/05/23 09:08, kt          # 

Гм… Интересно, а как выглядели кислые мины?

Это надо искать на форуме группы PL/1 Гугла. Когда Земнов объявил, что в России есть ещё один компилятор, Робин (это он, кажется, из Австралии), ответил, что, да, он слышал, что в России «испортили язык», и в свой обновляемый список ответов и вопросов никаких ссылок добавлять не стал. Ссылка на российские ресурсы там одна древняя и не действующая.
И кстати о компиляторах: поскольку появились ПК с Эльбрусом, а на Эльбрусе PL/1 был неслабо реализован, эти наработки, вероятно, можно будет опять использовать.

Думаю, прямо на эту страницу можно поставить URL для закачки со счётчиком. Тогда бы хоть какая-то статистика собиралась.

Да, конечно, хотя такая статистика хороша только для истерик об «упущенной выгоде», которую так любят считать миллиардами некоторые фирмы :)

Вероятно, для PL1-KT нет таких всеобъемлющих специально написанных тестов.

Проблема, по-моему, ещё и в том, что кроме ПРАВИЛЬНЫХ тестов, которые проверят хотя бы раз каждую ветку транслятора, нужны ещё и НЕПРАВИЛЬНЫЕ тесты, которые подтвердят имеющиеся ошибки. А таких тестов принципиально бесконечное множество.
Тесты PL-KT состоят из группы специально написанных тестов и множества реальных программ, которые накопились за все эти годы. При изменениях компилятора эти программы или не должны меняться или изменения будут заранее понятны и тогда за эталоны берутся новые объектные модули.
Кроме этого, основная программа нашей деятельности сама является хорошим тестом для нас :)

     2019/05/23 09:54, kt          # 

Вот реальные примеры ошибок для «правильных» и «неправильных» тестов:
ошибку
RETURN(ADDR 
я исправил за несколько минут, такое сочетание было просто пропущено во внутренней таблице компилятора. «Правильный» тест нашел бы эту ошибку.

Если я напишу в программе
M1: …
….
M1:…
То компилятор укажет, что такая метка уже была.
А вот если написать метки с индексами:
M1(25): …
….
M1(25):…
То исходный компилятор не выдавал ошибки и лепил неправильные адреса. И «правильный» тест, проверяющий метки с индексами, здесь бы не помог.

     2019/05/23 16:44, VIT1972          # 

Это надо искать на форуме группы PL/1 Гугла. Когда Земнов объявил, что в России есть ещё один компилятор, Робин (это он, кажется, из Австралии), ответил, что, да, он слышал, что в России «испортили язык»,

Нашел:
https://groups.google.com/forum/?fromgroups#!searchin/comp.lang.pl1/Russian%7Csort:date/comp.lang.pl1/LYfbKqBVK28/Ove8fz4cBAAJ

И что же там есть? Вот что:
1. Вам говорят спасибо, стараясь сделать это по-русски. Вы им предлагаете (или нет?) компилятор на русском языке.
2. У Вас спрашивают, доступен ли он? В ответ четырехлетняя (!) тишина.
3. Пытаются найти инженера из России, чтобы заинтересовать его(!)
4. Дословный перевод Вовельса: Русские использовали PL с самого начала. Думаю, этот компилятор не отличается от компиляторов фирмы IBM.
5. Тема пока оканчивается тем, что у Вас уже русскоговорящие спрашивают о доступности в конце 2016 года. В ответ опять тишина.

Скажите, где здесь хоть гран негатива? И если есть, то откуда он идет7 Вы пишете, что Вовельс на поместил Вас в FAQ. А Вы его просили? Или Вы всерьез считаете, что узнав о русскоязычном компиляторе все немедленно изучат язык и станут домогаться Вас? Нет, это Вы сосвсем не умеете продвигать свой компилятор! И не говорите, что у Вас нет такой цели, ибо что Вы тогда делаете здесь?

Более конструктивно:
1. Привести компилятор и документацию к виду, пригодному для использования, скажем, индийцем. Вести опцию, переключающую режимы языка. Вообще, сделать файл языковых ресурсов, тогда любой желающий переведет его на свой язык.
2. Ввести опцию, отключающую все неописанные в subset G возможности, разделяя (возможно) Ваши нововведения и вещи из стандарта F.

     2019/05/23 20:00, MihalNik          # 

И не говорите, что у Вас нет такой цели, ибо что Вы тогда делаете здесь?

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

     2019/05/23 20:28, VIT1972          # 

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

Простите, не понял, что логично? Рассказать что есть то и то и все? Для чего (кого) делается компилятор? Если для себя, тогда логично (хотя и сюр). Но даже если для себя, зачем о нем рассказывать?

Добавить свой отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Каким должен быть язык программирования?

Анализ и критика

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Двадцать тысяч строк кода, которые потрясут мир?

Почему владение/заимствование в Rust такое сложное?

Масштабируемые архитектуры программ

Почему Хаскелл так мало используется в отрасли?

Бесплатный софт в мышеловке

Исповедь правового нигилиста

Русской операционной системой должна стать ReactOS

Почему обречён язык Форт

Программирование без программистов — это медицина без врачей

Электроника без электронщиков

Программисты-профессионалы и программирующие инженеры

Статьи Дмитрия Караваева

●  Идеальный транслятор

●  В защиту PL/1

●  К вопросу о совершенствовании языка программирования

●  О реализации метода оптимизации при компиляции

●  О реализации метода распределения регистров при компиляции

●  О распределении памяти при выполнении теста Кнута

●  Опыты со стеком или «чемпионат по выполнению теста Кнута»

●  О размещении переменных в стеке

●  Сколько проходов должно быть у транслятора?

●  Чтение лексем

●  Экстракоды при синтезе программ

●  Об исключенных командах или за что «списали» инструкцию INTO?

●  Типы в инженерных задачах

●  Непрерывное компилирование

●  Об одной реализации специализированных операторов ввода-вывода

●  Особенности реализации структурной обработки исключений в Win64

●  О русском языке в программировании

●  Формула расчета точности для умножения

●  Права доступа к переменным

●  Заметки о выходе из функции без значения и зеркальности get и put

●  Ошибка при отсутствии выполняемых действий

●  Скорость в попугаях

●  Крах операции «Инкогнито»

●  Предопределённый результат

Компьютерный юмор

Новости и прочее

Последние комментарии

2019/05/23 20:28 ••• VIT1972
Идеальный транслятор

2019/05/16 17:27 ••• Неслучайный читатель
К вопросу о совершенствовании языка программирования

2019/05/14 16:10 ••• utkin
Обработка ошибок

2019/05/09 18:05 ••• евгений
Русский язык и программирование

2019/04/28 14:08 ••• Автор сайта
Статьи Дмитрия Караваева

2019/04/22 16:19 ••• Автор сайта
Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

2019/04/03 22:24 ••• Антон
Все голосования

2019/04/02 12:28 ••• Автор сайта
Шестнадцатиричные и двоичные константы

2019/04/02 12:25 ••• Автор сайта
Выбор кодировки для компилятора

2019/03/24 14:55 ••• Автор сайта
Реализация двухстековой модели размещения данных

2019/03/23 19:01 ••• Автор сайта
Размещение объектов переменной длины с использованием множества стеков

2019/03/20 14:37 ••• rst256
Реализация параметрического полиморфизма