В MIPS 20-летней и более давности, например. Борьба со сбросом конвеера при переходе.
Вид для печати
В MIPS 20-летней и более давности, например. Борьба со сбросом конвеера при переходе.
Для понятности можно написать по=другому
(ERRor eXIT - выход по ошибке, временная метка тут как-то не очень, если не делать .ENABLE LSB, то она почти наверняка окажется недоступной, ибо стандартная область действия временных меток - между двумя постоянными.)Код:TST #261
ERRXIT = .-2
RTS PC
- - - Добавлено - - -
А вот прием для обслуживания кучи одинаковых устройств. Пример - несколько терминалов, подключенных через обычные ВП1-065, допустим, на плате КТЛК-6. Программу обслуживания их прерываний (код), обычно, пользуют одну и ту же, а переменные данные (кольцевые буферы и текущие адреса в них, всякие счетчики, флажки и пр.) располагают в таблице, для каждого терминала - своей. В этом случае программа обслуживания конкретного прерывания от терминала должна поместить в какой-то заданный регистр адрес этой таблицы, перед этим сохранив его, и уйти на общую программу обслуживания прерывания от терминалов. Так вот, можно воспользоваться следующим приемом, допустим, адрес таблицы нужен в R0 (подсмотрено в ядре ДИАМСа.):
Вектора же заполняем указателями на команду JSR R0,@(PC)+, то есть на смещение -4 от начала таблицы, каждому терминалу - своей. Таким образом, прерывание от терминала этой командой сохранит R0 в стеке, поместит в этот R0 адрес начала таблицы и уйдет на общую программу обслуживания терминалов.Код:INTn: JSR R0,@(PC)+ ; смещение -4 от начала таблицы. Команда.
.WORD TRMINT ; Смещение -2 от начала таблицы. Адрес общей программы обслуживания
; прерываний от терминала.
nTABLE: ; Собственно таблица, ее начало
.........
Обычно эти таблицы генерятся динамически в занятом для них куске свободной памяти при запуске программы. При этом сначала берут адрес этого участка памяти для таблицы, записывают его в вектор конкретного терминала, потом в память по этому адресу пересылают с автоинкрементом сначала код 4037 (тот самый JSR), затем адрес программы обслуживания терминалов, получившийся после этих двух пересылок адрес сохраняем в качестве адреса начала таблицы для этого терминала, после чего генерим собственно таблицу в ее начальном состоянии.
Итого, накладные расходы на занесение в R0 адреса таблицы конкретного терминала и переход к общей программе обслуживания всего два слова (4 байта) на каждый терминал.
Ну что, вроде ожили? Чего было-то? Форум в воскресенье висел или лежал?
Пардон, месье, я вижу — Вы в нашем деле новичок и ещё не успели познать всю радость извращений! :) А что Вы скажете на пару_строк кода 8080?:
Как Вы думаете, куда будет передано управление по метке error и какой такой метод адресации использован в команде по метке noerror?Код:error EQU noerror+1
noerror: CPI 37h
RET
Правда, у 80-го процессора есть однобайтные команды условного возврата из подпрограмм, так что ему будет дешевле написать условный возврат, нежели вышеприведённый код. А с вызовом подпрограмм уже не так: у 11-го процессора вызов занимает 4 байта, а у 8080 — три, что, казалось бы, даёт ему экономию кода в 25%. Но!!! Вы верно заметили про "такие методы адресации"! В 11-м процессоре есть такие методы адресации, которые требуют при вызове подпрограммы всего 2-х байтов кода, так что при их использовании 8080 уже отстаёт по краткости кода, причём на 33%. Однако и это не всё!
Практическая польза при программировании в среде RT-11 на ассемблере заключается в возможности вызовов подпрограмм вообще без команд вызова подпрограмм, а просто по именам! Вот пример такого кода, который типа печатает на экране результат А*В+D/F:
Где-то поодаль находятся коды подпрограмм F_MUL, F_DIV, F_ADD (она же F_SUB) и F_TYPE, а также переменные.Код:F_MUL А, В, С ; вызов подпрограммы умножения А и В с занесением результата в С
F_DIV D, E, F ; вызов подпрограммы деления D на E с занесением результата в F
F_ADD C, F, G ; вызов подпрограммы сложения C и F с занесением результата в G
F_TYPE G ; вызов подпрограммы печати G на экране
Программистская фишка здесь заключается в настройке регистра (например, R4) на начало такого блока "данных" и завершении каждой из подпрограмм командой не RET, a JMP @(R4)+, так что указанный регистр выполняет функцию как бы счётчика команд, если считать F_MUL (и прочие) командами, а не именами подпрограмм. Но поскольку и эти "команды", и данные к ним находятся вперемежку, то этот же регистр выполняет функцию и как бы указателя стека, только растущего не вниз, а вверх, как и счётчик команд. Как Вам, месье, понравится такое извращение?
На самом деле я всего лишь привёл упрощённый пример куска фортрановского кода от RT11, который, впрочем, без упрощений не стеснялся применять и в своих ассемблерных программах. Понятно, что в вычислительных задачах количество вызовов наиболее ходовых подпрограмм (+, -, * и /, а также присвоения и преобразования данных) столь велико, что экономия по одному слову памяти на каждый вызов, а, главное, экономия времени от неиспользования обычного стека (как это было бы при обычных вызовах CALL) получается весьма заметной.
Ну не всегда - зависит от того как вызывать :)
- - - Добавлено - - -
Кстати, повторюсь - где-то уже писал, но напомнить фичу не помешает :)Правильно, это сохранение регистров в стеке, при том не меняя C,V,Z,N в PSW :)Код:JSR R0,@PC
JSR R1,@PC
JSR R2,@PC
...
Сложные вопросы можно даже в RT-11 организовать :)А мой любимый "сложный" вопрос - про фортран: CALL SUB(1) - объяснить что делает данный оператор :)Код:.TY TEST.MAC
.TITLE TEST
.MCALL .EXIT,.PRINT
.PSECT CODE,I
TEXT: .ASCIZ /I=D/ ;XXX EVEN
START: .PRINT #TEXT ;PRINT
.EXIT ;EXIT
.PSECT DATA,D
.ASCIZ /I<>D/
.END START
.MAC TEST
.LIN TEST/RUN
I=D
.LIN TEST/RUN/ID
I<>D
.
Большинство знакомых программеров (даже тех кто знает фортран с далеких времен) отвечает неправильно (хотя с появлением всякого дерьма вроде g77 их ответ можно принять) :D
Холмс и Ватсон летят на воздушном шаре, поднялись уже высоко - за облака. Ватсон не выдержал и спрашивает:
- Холмс, как Вы думаете, где мы находимся?
- В корзине воздушного шара, дорогой Ватсон, - невозмутимо ответил Холмс.
Вот у Вас как код написан неряшливо, так же неряшливо Вы и вопрос пытаетесь задать. Обратите внимание: он у Вас даже не заканчивается вопросительным знаком! А ведь известно: какой вопрос, такой и ответ. По-моему, такая неаккуратность нехороша для программиста, выглядит как неуважение к остальным...
Я попытку ответа сделаю основываясь на опыте ПАСКАЛЬ + МАКРО11 и сторонние obj библиотеки,
такая команда вызывает глобальную процедуру (функцию) SUB и передаёт ей входящий параметр = 1.
- - - Добавлено - - -
в чём вы видите неряшливость кода? вы листинги Корчагина видели ? )))
Что правильно если внимательно прочитать как он написан ;)
- - - Добавлено - - -
Здесь и заключается ошибка :)
То есть конечно 1 в качестве параметра передается, но есть нюанс - у фортрана аргументы векторные. С точки зрения паскаля можно считать, что они всегда var, а это уже совсем другая песня :)
- - - Добавлено - - -
Разумеется не неряшливый код "был, но дискеты потерялись, а потому примеров не дам"? ;)
Ты в теме ПАСКАЛЬ И МАКРО-11 когда обсуждался опрос клавиатуры и системная библиотека фортрана уже
упоминал об этом. На самом деле, если Фортран под RT-11 такой мощный, почему до сих пор отдельной темы нет?
Исходники на нём так или иначе (для примеров) в архиве и сети есть, от простых до сложных.
Я вот помню одного Фортранщика заядлого, это был пожилой преподаватель в Универе,
он на каком-то фортране под MS DOS там что то вроде турбо-среды писал на фортране кроссворд или программу для составления кроссвордов. Типа хобби наверное. Причём фортрана в программе вузовской не было. )))
Не секрет, что языки программирования заточены для написания вполне определённых задач.
Ну как пример - Delphi это базы данных, ассемблер - это драйвера, Си - что бы троллить Паскальщиков )))
Макро-11 - просто очень правильный ассемблер, а вот Фортран? Что именно проще реализовать именно
с его помощью?
- - - Добавлено - - -
в том числе я просматривал их и видел там процедуры и функции графических примитивов в духе бейсика (круги, линии, точки), вот как с ними? Где и в каких условиях они рассчитаны на использование под RT-11?
Я в досе на борландском паскале как-то драйвер делал :)
Точнее драйвер-программу - можно было и как device= подключать и как программу запускать. Правда внутри было много asm'ов - спасибо TP 6.0 и более новым - добавили возможность :)
Принято считать, что это язык для инженеров, но в целом - просто язык высокого уровня на мой взгляд. Но в DEC системах (как уже писал) он выделяется именно тем, что для него есть полная поддержка вызова системных директив. То есть поддержка прямо в системе, а не в пакете языка. Поставишь ты фортран в RSX/RT/RSTS или не поставишь - это твое дело, но в системной библиотеке изначально есть полный набор подпрограмм для системных вызовов, а в системной документации они подробно описаны.
- - - Добавлено - - -
Были специальные наборы на тему графики - где-то таже книги валялись про некую библиотеку ГРАФОР - кажется выкинул давно. Вопрос только что считать графикой - в союзе например не видел ни одного живого примера где бы использовалась DECовская аппаратура для этой цели (точнее в пост-советское время уже увидел живую железяку - Andrey_Ak вроде 100/25 взял с такой или еще на каком 100/25 видел). Каждый лепил свой вариант, считал его самым лучшим и делал все под него :)
есть такое, на двух 400кб дискетах для RT-11 )
grafor1, grafor2 в архиве (подробности)
Описание увесистое как и сама библиотекаКод:************************************************************
* *
* *
* ОБ'ЕДИНЕННЫЙ ИНСТИТУТ ЯДЕРНЫХ ИССЛЕДОВАНИЙ *
* ОТДЕЛ НОВЫХ МЕТОДОВ УСКОРЕНИЯ *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* ПАКЕТ ПРОГРАММ НА ФОРТРАНЕ IV *
* *
* С М Г Р А Ф О Р *
* *
* ДЛЯ ПРЕДСТАВЛЕНИЯ ГРАФИЧЕСКОЙ ИНФОРМАЦИИ *
* НА МИНИ-ЭВМ MERA 60/30,СМ3,CM4 *
* *
* *
* *
* *
* *
* *
* ОПИСАНИЕ ПРИМЕНЕНИЯ *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* *
* ДУБНА,1983 *
* *
* *
************************************************************
http://savepic.net/8629461.png
Содержимое пакета
GRFOR1.DSK
GRFOR2.DSKКод:Volume ID: RT11A
Owner :
GRT .FOR 1 25-Jan-1988 14 PCALL .FOR 3 24-Jan-1988 15
GRAFOR.FTN 257 18-Jan-1988 18 GRAFOR.TXT 124 19-Jan-1988 275
FIND .BAS 1 25-Jan-1988 399 GRT4 .FOR 1 26-Jan-1988 400
GRT2 .FOR 1 25-Jan-1988 401 GRT1 .FOR 1 26-Jan-1988 402
GRT3 .FOR 1 14-Jan-1988 403 TPF .FOR 2 26-Jan-1988 404
GCALL .FOR 2 26-Jan-1988 406 GRT5 .FOR 2 26-Jan-1988 408
GRT3 .SAV 88 27-Jan-1988 410 PR .FOR 1 01-Feb-1988 498
DEMO .SAV 77 23-Feb-1988 499 < UNUSED > 224 576
15 Files, 562 Blocks
224 Free blocks
DEMO .SAV 77 - вот где её надо запускать, что бы что то увидеть?Код:Volume ID: RT11A
Owner :
GRAFOR.OBJ 766 25-Jan-1988 14 VCL .MAC 3 25-Jan-1988 780
PIX .MAC 3 22-Jan-1988 783 MOVE .FOR 2 24-Jan-1988 786
PLOT .FOR 2 24-Jan-1988 788 VCSUBR.MAC 3 23-Jan-1988 790
PAGE .FOR 3 25-Jan-1988 793 ENDPG .FOR 2 25-Jan-1988 796
DEMO .FOR 2 25-Jan-1988 798
9 Files, 786 Blocks
0 Free blocks
[свернуть]
В общем легко ищется в архиве и (я могу ошибаться), но похожие
граф. наработки и для UNIXового Си есть в рамках ПО для ОС РАФОС.
- - - Добавлено - - -Код:Ed Post
Wilsonville, Orezon
В прошлом, во времена золотой эры ЭВМ было легко отличать
мальчика от мужа (иначе их называют "сосунки" и "настоящие
мужчины", соответственно). Тогда настоящие мужчины были те, кто
понимал в программировании, с сосунки - те, кто не понимал.
Настоящий программист легко произносил такие фразы, как "DO 10
I = 1, 10" или "АВОСТ", а все остальные нечто вроде "ЭВМ слиш-
ком сложна для меня" и "Я не могу полагаться на ЭВМ - они слиш-
ком безличны". Предыдущая работа, B. Feirstein, "Настоящие муж-
чины не употребляют фруктовый пирог", издание PocketBook, 1982,
отмечает, что настоящие мужчины ни на что не полагаются и не
боятся быть обезличенными.
Но времена меняются. Сегодня мы живем в мире, в котором
маленькие старые дамы могут приобрести компьютезированную
микроволновую печь, 12-летние пацаны могут выбить из колеи
настоящих мужчин при игре на ЭВМ в астероиды и в очко и, вообще,
любой человек может купить и понять свой собственный персональ-
ный компьютер. Настоящий программист в опасности, он может быть
заменен студентами высшей школы.
Однако, существует разница между студентом-первокурсником,
освоившим на ЭВМ игру в очко и настоящим программистом. Знание
этих различий может помочь детям познать к чему стремиться -
модель поведения, стереотоп отца. Это также поможет сохранить
рабочие места для настоящих программистов.
Самый простой способ определить, кто является настоящим про-
граммистом - по используемому языку программирования. Настоящие
программисты используют Фортран. Сосунки используют Паскаль.
Никлауса Вирта, разработчика Паскаля, однажды спросили: "Как вы
произносите свою фамилию?". "Вы можете обращаться ко мне по
фамилии, произнося ее 'Вирт', или обращаться ко мне по значению,
'Ворт'", - ответил он. [Игра слов : Nicklaus Wirth произносится
так же, как английское слово Worth - стоящий, ценный]
Исходя из этой ремарки, любой сразу поймет, что Никлаус Вирт
- сосунок. Единственный механизм передачи параметров, принима-
емый настоящим программистом - это передача параметров по зна-
чению, как это реализовано в компиляторах Фортрана G и H для
ЭВМ IBM/370. Настоящим программистам для выполнения работы не
нужны абстрактные концепции: для счастья им достаточно перфора-
тора, компилятора Фортран-IV и пива. Настоящие программисты
пишут программы работы со списками, обработки строк, учета ре-
сурсов (если они вообще это делают) и искусственного интелекта
на Фортране.
Если вы не можете выполнить эти работы на Фортране, выполни-
те их на ассемблере. Если же их нельзя выполнить на ассемблере,
их не стоит делать вообще.
В последние несколько лет академиков от вычислительной тех-
ники вовлекли на стезю структурного программирования. Они
утверждают, что программы становятся более понятными, если
используются специальные языковые методы и конструкции. Они,
конечно, не могут договориться между собой, какие точно кон-
струкции следует использовать, а примеры, иллюстрирующие их
точку зрения, всегда помещаются на одной страничке неизвестных
журналов. Когда я окончил школу, я считал себя самым лучшим
программистом в мире. Я мог написать непобедимую программу игры
в крестики-нолики в трехмерном пространстве на пяти различных
языках программирования, а также написать программу, состоящую
из 1000 строк, которая бы работала. Затем я попал в реальный
мир. Моей первой задачей было прочитать и понять фортрановскую
программу емкостью 200000 строк, а затем увеличить скорость ее
работы в 2 раза. Любой настоящий программист скажет вам, что
все структурированное программирование мира не поможет вам
решить проблемы вроде этой - решение этой задачи требует
настоящего таланта.
Несколько наблюдений о настоящих приграммистах и структурном
программировании:
- настоящие программисты не боятся использовать GOTO;
- настоящие программисты могут без смущения написать цикл DO
на пяти страницах;
- настоящие программисты любят арифметические операторы IF,
т.к. их использование делает программу более интересной;
- настоящие программисты используют самомодифицирующий код,
особенно в тех случаях, когда это экономит 20 наносекунд в
середине очень короткого цикла;
- настоящие программисты не нуждаются в комментариях : текст
программы все объясняет;
- поскольку в Фортране отсутствуют структурные операторы IF,
REPEAT ... UNTIL или CASE, настоящим программистам не
нужно беспокоиться, что они их не используют; кроме того
эти операторы можно при необходимости симулировать с
помощью присваиваемых GOTO.
В последнее время в прессе муссируются структуры данных.
Абстрактные типы данных, структуры, указатели, списки и строки
стали популярны в определенных кругах. Вирт, сосунок, написал
даже целую книгу ("Алгоритмы + Структуры данных = Программы",
Prentice Hall, 1976 [русский перевод - изд. "Мир", 198?]), в
которой утверждает, что можно написать программу на базе струк-
тур данных, не используя другие способы. Как все настоящие
программисты знают, единственной полезной структурой данных
является массив. Строки, списки, структуры и наборы - это все
разновидности массивов и их можно рассматривать как массивы без
усложнения вашего языка приграммирования. Хуже всего с этими
хитрыми типами данных то, что вы должны их описывать, а
настоящие языки программирования, как мы все знаем, обладают
возможностью неявного задания типа, основанного на первой букве
6-символьного имени переменной.
В какой операционной системе работает настоящий программист?
В CP/M ? Боже сохрани! Помимо всего прочего, это в основном иг-
рушка, а не операционная система. Даже маленькие старые дамы и
абитуриенты могут работать в CP/M и понять ее.
UNIX, конечно, более сложная система - типичный последова-
тель UNIX'а никогда не может запомнить, как на этой неделе на-
зывается команда PRINT - но когда он наконец доберется до нее,
UNIX становится восхитительной видеоигрой. Люди не делают серь-
езных работ в системе UNIX, они рассылают шутки по всему миру
по USENET или пишут приключенческие романы и научные статьи.
Нет, настоящий программист использует OS/370. Хороший про-
граммист может найти и понять описание только что полученного
сообщения об ошибке IJK305I в руководстве по JSL. По-настоящему
знаменитый программист может найти ошибки в распечатке 6-мега-
байтной области памяти, не используя калькулятор шестнадцати-
ричной системы счисления.
OS/370 по настоящему удивительная система. В ней можно
уничтожить работы стоимостью несколько человеко-дней с помощью
одного неправильно помещенного пробела, так-что штат програм-
мистов всегда должен быть на чеку. Наилучший способ общения с
системой - через перфоратор. Некоторые утверждают, что в OS/370
существует система разделения времени, но после внимательного
изучения я пришел к выводу, что они ошибаются.
Какие инструменты использует настоящий программист в своей
работе? Теоретически, настоящий программист может запускать
свои программы, набирая их на передней панели ЭВМ. В добрые
старые времена, когда ЭВМ имели передние панели, этот метод ис-
пользовался время от времени. Типичный настоящий программист
знал наизусть начальный загрузчик в шестнадцатиричной системе и
восстанавливал его с пульта, когда он разрушался его програм-
мой. Более того, память была памятью - ее содержимое не пропа-
дало при выключении питания. В настоящее время память либо за-
бывает факты, когда вы этого не хотите, либо помнит о вещах,
которые давно следовало бы забыть. Ходит легенда, что Seymour
Cray, изобретатель супер-ЭВМ Cray-1 и большинства ЭВМ фирмы
Control Data, ввел с пульта наизусть первую операционную систе-
му ЭВМ CDC 7600 при первом включении этой ЭВМ. Конечно, Cray -
настоящий программист.
Одним из моих любимых настоящих программистов был Джим -
системный программист фирмы Texas Instruments. Однажды, ему по
междугородному телефону позвонил пользователь, чья система раз-
рушилась в процессе очень важной работы. Джим исправил систему
по телефону, заставляя пользователя набирать на передней панели
ЭВМ команды обращения к диску, исправлять системные таблицы в
шестнадцатиричной системе и считывать ему по телефону содержи-
мое регистров. Мораль этой истории: хотя настоящий программист
обычно включает в набор своих инструментов перфоратор и АЦПУ,
он может в экстренных ситуациях обойтись передней панелью ЭВМ и
телефоном.
В некоторых фирмах редактирование текстов программ больше не
представляет собой очередь из 10 инженеров, ожидающих освобож-
дения перфоратора 029. Более того, здание где я работал не
содержит вообще ни одного перфоратора. Настоящий программист в
таких условиях должен выполнять работу с помощью текстового
редактора. Большинство систем предлагают на выбор несколько
текстовых редакторов, но настоящий программист должен быть
очень осторожен в выборе, отражающего его индивидуальность.
Многие думают, что наилучшие текстовые редакторы в мире
написаны в исследовательском центре фирмы Xerox в Palo Alto для
работы с ЭВМ марок Alto и Dorado. К сожалению, ни один настоя-
щий программист не будет работать на ЭВМ с операционной систе-
мой под названием Smalltalk (короткий разговор) и конечно же не
будет беседовать с ЭВМ с помощью "мышки".
Некоторые из концепций этих редакторов фирмы Xerox были реа-
лизованы в редакторах, работающих в операционных системах с бо-
лее солидными названиями, такими как EMACS и VI. Дело в том,
что настоящий программист считает плохим следующий принцип ре-
дактора: "То, что вы видите, то вы и получите". Настоящий прог-
раммист желает редактор с принципом: "Вы это просили, вот вам";
т.е. редактор, который был бы сложным, шифрованным, мощным,
непрощающим и опасным. Редактор TECO - чтобы быть точным.
Было замечено, что последовательность команд TECO более на-
поминает помехи в линии передачи, чем читаемый текст. Одна из
самых развлекательных игр с TECO - напечатать в качестве ко-
мандной строки свою фамилию и попытаться догадаться, что она
сделает. Точно так же любая случайная опечатка при работе с
TECO может разрушить вашу программу, или, хуже того, внести не-
уловимые и мистические ошибки в уже работающую программу.
Из-за этого настоящие программисты неохотно редактируют уже
работающие программы. Они считают более простым непосредственно
латать двоичный объектный код, используя прекрасную программу
под названием SuperZap (или ее эквивалент на не-IBM машинах).
Этот метод настолько хорош, что многие программы, работающие на
ЭВМ фирмы ИБМ, не имеют ничего общего со своим собственным
текстом на Фортране. В большом количестве случаев первоначаль-
ный символьный текст программы вообще не существует. Когда
наступает время подправить такого рода программу, никакой
администратор даже не думает послать на эту работу кого-либо,
кроме настоящего программиста - никакой сосунок (структурный
программист) не будут знать даже с чего начать. Это называется
защита от несанкционированного доступа.
Некоторые не используемые настоящим программистом средства
программирования включают:
- препроцессоры Фортрана, такие как Mortran и Ratfor; эти
кулинарные рецепты в программировании хороши для выпечки
фруктового пирога;
- отладчики для работы с текстом программы; настоящие про-
граммисты могут свободно читать распечатку оперативной
памяти;
- компиляторы с проверкой границ массива; эти компиляторы
душат творчество, запрещая наиболее интересные варианты
оператора EQUIVALENCE и препятствуют модификации операци-
онной системы с помощью отрицательных индексов массивов.
Кроме всего прочего, контроль границ массива не эффективен;
- системы сопровождения и архивизации символьных текстов
программ; настоящий программист хранит текст своих
программ в закрытом на замок ящике (на перфокартах), т.к.
владелец не может оставить свои программы без охраны.
Где же работает типичный настоящий программист ? Какие про-
граммы достойны таких талантливых индивидумов ? Вы можете быть
уверены, что настоящий программист не умрет за написанием про-
граммы "Зарплата" на Коболе или сортируя список почтовых
отправлений журнала People. Настоящий программист желает задачи
с важностью землетрясения.
Настоящие программисты работают на национальную лабораторию
в Лос-Аламосе, создавая программы на супер ЭВМ Cray-1, модели-
рующие атомную бомбу. Они так же работают на Агенство по Наци-
ональной Безопасности, расшифровывая передачи русских.
В большой степени из-за усилий тысяч настоящих программистов,
работающих в NASA, наши ребята добрались до Луны и вернулись
обратно, опередив космонавтов. ЭВМ в космическом корабле "Шатл"
были запрограммированы настоящими программистами, и эти же
истинные профессионалы работают на фирму Боинг, создавая опера-
ционные системы для крылатых ракет.
Одна из приводящих в благоговейный трепет работ настоящих
программистов выполнена в Лаборатории реактивного движения,
Калифорния. Многие знают всю операционную систему космических
кораблей "Пионер" и "Вояджер" наизусть. С помощью симбиоза
больших наземных фортрановских программ и маденьких бортовых
ассемблерных, они могут совершать невероятные чудеса в нави-
гации и импровизации - такие, как попасть в окно шириной 10 км
в кольце Сатурна после 6-ти лет полета в космосе и починить или
обойти неисправные сенсорные платформы, радиопередатчики или
аккумуляторы. Утверждают, что один настоящий программист умуд-
рился засунуть прграмму распознавания образов в несколько сот
байт неиспользованной памяти корабля "Вояджер", которая осу-
ществляла поиск, обнаружила и сфотографировала новую луну
Юпитера.
Одна из планируемых задач для корабля "Галлилей" - использо-
вать притяжение Марса на траектории полета к Юпитеру. Эта
траектория проходит в 80 +/- 3 км от поверхности Марса. Никто
не собирается доверить паскалевской программе или программисту
такую навигационную задачу.
Многие из настоящих программистов всего мира работают на
правительство США, в основном в Министерстве Обороны. Так и
должно быть. Однако, недавно на небосклоне настоящих програм-
мистов появилась черная туча. Кажется, что кто-то из высоко-
поставленных сосунков в Министерстве Обороны решил, что все
оборонные программы должны быть написаны на некоем великом
унифицированном языке ADA. Некоторое время казалось, что ADA
была предназначена стать языком, который шел вразрез со всеми
правилами настоящего программирования. Это язык со структурой,
типами данных, строгим синтаксисом и точками с запятой. Короче,
он был разработан для сдерживания творчества типичного насто-
ящего программиста. К счастью, язык одобряемый Министерством
Обороны, обладает достаточно интересными свойствами, которые
делают его приемлемым - он невероятно сложен, включает в себя
способы порчи операционной системы и перераспределения памяти,
и Эдгар Дейкстра (Edsgar Dijkstra) не любит его. Дейкстре, как
вы должны знать, автору краеугольной работы по методологии
программирования "GOTO - считать вредными", апплодируют про-
граммисты на Паскале и подобные им сосунки. Да и потом, закоре-
нелый настоящий программист может написать фортрановскую про-
грамму на любом языке.
Настоящий программист может пойти на компромис со своими
принципами и работать над вещами немного более тривиальными,
чем распад жизни, при условии, что здесь достаточно платят.
Например, существует несколько настоящих программистов,
разрабатывающих видео-игры в Atari. Но они сами в игры не
играют. Настоящий программист знает, как выиграть у машины, и в
этом нет пряного удовольствия. Каждый работающий в LucasFilm
является настоящим программистом, потому, что нужно быть
сумасшедшим, чтобы отвергнуть деньги 50-ти милионов поклонников
Звездных войн (Star Wars).
Доля настоящих программистов, занятых машинной графикой,
несколько ниже нормы в основном потому, что никто пока не нашел
ей применения. С другой строны, вся машинная графика выполнена
на Фортране, так что существует определенное число людей,
занимающихся графикой для того, чтобы избежать программирования
на Коболе.
В общем случае настоящий программист развлекается так же,
как и работает - с помощью ЭВМ. Он не перестает удивляться
тому, что его работодатель платит ему за то, что он все равно
бы делал для развлечения, хотя он достаточно осторожен, чтобы
высказать это мнение вслух. Иногда настоящий программист
выходит из конторы, чтобы глотнуть свежего воздуха или кружечку
-другую пива. Существует несколько признаков, по которым можно
узнать настоящего программиста за пределами машинного зала :
- на вечеринке настоящие программисты это те, кто сидит в
углу, обсуждая защиту операционных систем и как ее обойти;
- на футбольном матче настоящий программист сравнивает ход
игры с "проигровками", распечатанными на фальцованной 11-
или 14-дюймовой бумаге;
- на пляже настоящий программист рисует блок-схемы на песке;
- настоящий программист ходит в диско-клуб, чтобы посмотреть
мигание лампочек;
- на похоронах настоящий программист изрекает : "Бедный
Джордж. А ведь он почти заставил работать программу
сортировки, когда его хватил инсульт";
- в бакалейном магазине настоящий программист настаивает
на собственноручной проверке банок на лазерном аппарате,
т.к. он не верит, что операторы могут правильно отперфо-
рировать данные с первого раза.
В каких условиях лучше всего работается настоящему програм-
мисту ? Это очень важный вопрос для начальников настоящих
программистов. Учитывая высокую стоимость содержания одного
такого в штате, лучше создать ему или ей оптимальные условия.
Типичный настоящий программист живет перед дисплеем ЭВМ.
Вокруг этого дисплея расположены листинги программ, над
которыми он когда-либо работал. Они складированы в кучи
приблизительно в хронологическом порядке на каждой плоской
поверхности конторы. Вы так же обнаружите полдюжины, или около
того, наполовину выпитых чашек с холодным кофе. Иногда в кофе
можно обнаружить плавающие "хабарики" сигарет. В некоторых
случаях в чашках находится выжатый апельсин. И только в тех
случаях, когда программист не очень хорош, вы увидите
экземпляры руководства OS JSL и принципов работы, открытых на
особо интересных страницах. Приклеенный клейкой лентой, на
стене висит распечатанный на АЦПУ календарь с собачкой Снуппи
за 1969 год. На полу разбросаны обертки от хлеба с сыром и
земляными орехами (такого, который становится черствым уже в
пекарне, так что не может стать хуже в торговых автоматах). И,
наконец, в верхнем левом ящике стола, под коробочкой Oreos,
находится линейка-шаблон для вычерчивания блок-схем, оставлен-
ная предыдущим владельцем стола. Настоящие программисты пишут
программы, а не документацию, которую они оставляют штату
сопровождения.
Настоящий программист может работать по 30, 40 и даже 50
часов непрерывно, под интенсивным нажимом. На самом деле, он и
предпочитает так работать. Плохое время отклика не беспокоит
настоящего программиста; он получает возможность вздремнуть
между трансляциями. Если график выполнения работы не очень
жесткий, то настоящий программист предпочитает делать свою
жизнь более захватывающей, работая первые 9 недель над
маленькой, но интересной частью проблемы. Затем, он заканчивает
выполнение всей остальной части за 2 или 3 50-часовых марафона.
Это не только впечатляет начальника, но и создает удобное
оправдание не делать документацию. В общем случае, ни один
настоящий программист не работает с 9 до 5, за исключением тех,
кто работает в ночную смену. Настоящие прграммисты не носят
галстуков. Настоящие программисты приходят на работу вовремя -
к обеду. Настоящий программист может знать, а может и не знать
имя своей супруги. Он, однако, знает наизусть таблицу ASCII
(или EBCDIC) символов. Настоящие программисты не умеют готовить.
Бакалейные магазины не часто открыты в 3 часа ночи, так что они
должны уметь выживать на печенье и кофе.
Заглядывая в будущее, некоторые настоящие программисты
считают, что новейшее поколение программистов имеет не такие же
взгляды на жизнь, как их старшие товарищи. Многие из них
никогда не видели передней панели ЭВМ. Едва-ли кто-либо из
выпускников в наши дни может производить вычисления в
шестнадцатиричной системе без калькулятора. Сегодняшние
выпускники колледжей слабы - они защищены от реальностей жизни
символьными отладчиками, редакторами текстов, которые подсчиты-
вают скобки, и лояльными к пользователю операционными системами.
Хуже того, некоторые из этих патентованных ученых умудрились
"защититься" без изучения Фортрана ! Неужели нам предписано
свыше стать отраслью фанатиков UNIX'а и паскалевских програм-
мистов ?
Из собственного опыта, я думаю, можно смело сказать, что
будущее прекрасно для настоящих программистов. Ни OS/370, ни
Фортран не высказывают ни каких признаков отмирания, несмотря
на усилия программистов на Паскале. Даже такие изощренные
уловки, как добавление конструкций структурного программиро-
вания в Фортран, провалились. Да, конечно, некоторые изготови-
тели ЭВМ выпустили компиляторы Фортрана-77, но каждый из них
оставил возможность перейти в режим компилятора Фортрана-66 с
помощью удаления одной перфокарты - чтобы компилировать циклы
DO как предписано богом.
Даже UNIX может быть не так уж плох для настоящих програм-
мистов, как в прошлом. Последняя реализация UNIX'а обладает
потенциальными возможностями, ценными для любого настоящего
программиста. Она имеет два различных и слегка несовместимых
пользовательских интерфейса, аркан и сложный драйвер терминала,
и виртуальную память. Если пренебречь тем, что он структурный,
то даже программирование на языке "C" может быть по достоинству
оценено настоящим программистом. В конце концов, в нем нет
проверки типов, имена переменных имеют 7 (10 ?, 8 ?) символов в
длину и введен полезный тип данных "указатель" (pointer).
Получается, как будто соединены воедино лучшие части языка
Фортран и Ассемблера, не говоря уже о более творческих примене-
ниях оператора #DEFINE.
Нет, будущее не так уж и мрачно. В последние несколько лет
даже популярная пресса сообщала о новом урожае блестящих
фанатиков, выпущенных из таких мест, как Стенфорд и Массачусет-
ский Технологический Институт, в реальный мир. По всему видно,
что дух настоящего программирования живет в этих молодых юношах
и девушках. Пока существуют плохо поставленные задачи, странные
ошибки и нереалистичиские расписания машинного времени, будут
находится настоящие программисты, желающие взять на себя и
решить проблему, оставив документацию на потом.
Да здравствует Фортран !
Перевод : Пяткин А.С. -- Ленинград
Верно сказано ;)Цитата:
Если вы не можете выполнить эти работы на Фортране, выполни-
те их на ассемблере. Если же их нельзя выполнить на ассемблере,
их не стоит делать вообще.
- - - Добавлено - - -
God is REAL, unless declared INTEGER. Это про фортран :)Цитата:
а настоящие языки программирования, как мы все знаем, обладают
возможностью неявного задания типа, основанного на первой букве
6-символьного имени переменной.
- - - Добавлено - - -
Можно и TST #SEC - все мнемоники определены: BR=400, MOV=10000 итд...
Я довольно много программировал на Фортране на ЕС ЭВМ (отечественные клоны Системы-360) и был поражен, как легко и непринужденно удалось перейти на Фортран RT-11. Не считая, конечно, доступных объемов памяти: на ЕС-ках тогда 100-200Кбайт было без вопросов, а постоять в очереди, так можно было и мегабайтную задачу прогнать. А тут Э-60 с центральным процессором М2 и 56К оперативки...
Вычисления. Очень удобный язык для всяких расчетов.
Он был очень удобный в 60-х. За неимением ;-) И то, шли дискуссии о недостатках Алгола и PL/1 в сравнении с Фортраном.
2hobot: в данном случае мы имеем дело с "трудно старого коня заставить ходить в новой упряжке" ;-) Привязка к языку со старинных времён. На сегодняшний день всё самое вкусное из Фортрана реализовано в любом языке программирования. Есть и развитие Фортрана - Fortress.
hobot, AFZ, вероятно со мной не согласится, но я тебе отвечаю. Возьми книгу С.Свердлова «Языки программирования и методы трансляции» и почитай вкратце про каждый язык, там про корявости Фортрана написано хоть и сжато, но очень хорошо.
Я ж не просто так привёл анекдот про Холмса: строка CALL SUB(1) на самом деле не делает ничего. То есть вообще НИ-ЧЕ-ГО. Если кто-либо что-либо и делает, то:
1. Процессор под управлением транслятора, генерируя объектный код.
2. Процессор под управлением оттранслированной и скомпонованной программы, исполняя её код. Естественно, система команд этого кода должна совпадать с системой команд процессора. Ещё более естественно, что от строки исходного текста в исполняемом коде не остаётся ничего, даже если исходник был на языке ассемблера, не говоря уже о ЯВУ.
Что же до фортрана, то в RT-11 (и её родителях) при передаче параметров он передаёт такой мощный блок этих параметров, что паскали и прочие ассемблеры нервно курят в сторонке. Начнём с того, что в разбираемом случае он передаёт подпрограмме две :) единицы. Кстати, именно из-за структуры этого блока длина имени подпрограммы фортрана ограничена 6-ю символами. И если мне не изменяет память (паскалеводы меня в случае чего поправят), то паскаль в RT11 требовал процессоров с плавающей арифметикой. Фортран же не только не требовал, но на процессоре 1801ВМ2 даже выполнял эти вычисления вчетверо быстрее паскаля. Правда, знающие люди сказали, что на оригинальном процессоре LSI-11 этих тормозов не было, но мой опыт работы ограничен только советскими ЧПУхами, а в них были только 1801ВМ1 да 1801ВМ2, да полная плата М2 от Электроники-60.
После ASCIZ ни разу нет выравнивания на границу слова. В первом разе это прокатило, поскольку получилась последовательность чётной длины. Во втором разе длина последовательности получилась нечётной, но поскольку это было в конце программы, то можно условно считать, что тоже прокатило. В любом случае транслятор поправил бы эту ошибку, от чего я и сказал не "ошибка", а именно "неряшливость". В 16-разрядной системе байтовая адресация - атавизм (вон, у 64-разрядного Крея и символьные, и целые, и плавающие, и комплексные данные имели разрядность 64 бита!), поэтому с ней надо быть поаккуратнее. Точно так же неряшливо товарищ задал и свой "сложный" вопрос, сложность которого заключается именно в неопределённости, расплывчатости, недосказанности его формулировки.Цитата:
в чём вы видите неряшливость кода?
вопрос был именно о Фортране и особенности передачи аргументов библиотечным процедурам и функциям.
Обычный абстрактный вопрос как дополнение к билету на экзамене )))
- - - Добавлено - - -
Приветствую, Олег! Редкий ты гость в нашем разделе )
Книгу обязательно для общего образования поизучаю - поскольку мне сама тематика интересна. Остальные разборки по Фортрану тут в общем то и связаны с ОС и оборудованием не совсем современным ) Там есть ключевой комментарий от form'а, в чем именно
уникальность реализации Фортрана для PDP ) Хотя - некоторые вещи не стареют и со сцены не спешат уходить )
А у ассемблера MACRO-11 каким блоком это ограничение вводится? ;)
Может все-таки дело в формате символьных таблиц стандартного OBJ файла для PDP-11?
В этом блоке ровно n+1 (где n - количество аргументов как указанных так и пропущенных) слов. Первое слово слово - количество аргументов, следующие - адреса (или -1 если аргумент пропущен). Все. К именам никакого отношения. К слову, такой способ передачи параметров ипользуется почти во всех реализациях фортрана, не только в RT-11. Почти - потому, что есть g77 в котором параметры передаются по сишному или около того, но его и фортраном-то назвать нельзя ибо он не умеет самое главное в фортране - отрабатывать фортрановский (!) символ форматирования :)
И, к слову, к чему поминать фортран для RT-11? Точно также все выглядит и в фортране для RSX. Можно скомпилировать в одной системе, перетащить результат в другую, и уже там собрать.
Это параметр генерации паскаля. Другое дело, что в союзе наверное никто никогда не видел дистрибутива паскаля для RT-11 (у меня его до сих пор нет - только для RSX).
UPD. Проверил тот паскаль, что у меня есть в RT-11 - без FPP все работает. Тест правда совсем простой - несколько действий с плавающей точкой.
После ASCIZ нету, но в данном конкретном случае есть - это обусловлено размером строки. XXX в коментарии для того и написано, что это "криво, но работает". Разумеется в живой программе если там была бы строка текста, после нее бы стоял .EVEN. Ставить же его после любой строки ну совершенно необязательно (например если она часть структур данных фиксированной длины). Именно так подобные вещи коментируют и в наше время (см исходники любой операционки и софта под нее).
Сложность видимо заключается в желании позанудствовать. Вопрос (а точнее - тоже позанудствую - упоминание вопроса) выглядел понятным для всех, кроме Вас ;)
я понимаю, что 77 Фортран на PDP наверное самый прогрессивный, но ведь
есть ещё более ранняя (или просто другая) реализация с римским номеров в названии iV как у него
там с системными вызовами (имеется в виду системная библиотека)? И в целом, надо бы кратко хотя
бы охарактеризовать обе реализации и совместимость (синтаксис) программ? Кстати в сети полно
по разному обоснованных рекомендаций Фортрана как "первого алгоритмического языка" вместо Бейсика или
Паскаля.
- - - Добавлено - - -
Глядя на объём всего F77 на диске RT-11 5.7 - для чисто флопов очень как-то громозко всё выглядит, с ЖД ничего не страшно (это я про УК-НЦ!).
- - - Добавлено - - -
F-IV компактнее, но видимо совсем совсем не актуальный???
- - - Добавлено - - -
В инете упоминается 77 и 90 синтаксис: 90 - это уже за пределами PDP видимо?
Библиотеке пофигу к какому фортрану ее подключить. Формат вызова одинаковый.
Да, F77 здоровенный и по большому счету в SJ/SB/FB фактически непригоден для компиляции больших программ - просто памяти не хватит.
У DEC F77 последняя реализация.
Честно говоря, ни разу не видел фортрановской программы, выходящей за рамки FIV :)
А тут еще неизвестно, кто виноват. Запросто может быть так, что, проектируя формат объектного модуля, инженеры DEC прикинули, что стандартному Фортрану 6-символьных внешних имен хватает, ну и нам хватит! Мы же, мол, не Систему-360 проектируем...
- - - Добавлено - - -
Если что, М2 - это цельнотянутая LSI-11/03, отличие лишь в корзиночном разъеме - в оригинале он дюймовый, у нас его сделали метрическим, с шагом ног 3.00 мм.
Фортран тут абсолютно непричем. Это ограничение формата OBJ. Пофигу фортран это, MACRO-11 или еще кто :)
Формат записи о символе в OBJ файле: два слова имени в RADIX-50, байт 0, байт 2 и еще одно слово просто так.
И никаких различий между маленькими и большими буковками. Если такое различие нужно - его нужно реализовывать обходными путями.
Естественно. Но, когда сочиняли этот формат OBJ, по фигу было, сколько слов в RAD50 отвести под это имя - 2, 3 или вообще плюнуть на этот RAD50 и забабахать строку ASCII произвольной длины до 255 символов. Однако выбрали 2 слова RAD50 и нельзя исключить влияние Фортрана, что мол Фортрану 6-символьных идентификаторов хватает, ну и нам хватит.
Более того, похоже, это началось еще раньше. Первый-то ассемблер был абсолютным, результат выдавал в виде LDA-файла. И фактическая длина меток (любых) в 6 символов как бы тоже не с Фортрана была позаимствована - из тех же соображений: Фортрану хватает, и нам хватит!..
Здесь и заключается ошибка, а точнее - две: :)
1. Вопрос был не обо всём фортране, а об одном из его операторов. Если не чувствуете разницу, то поясню: свойства подмножества не обязательно будут выполняться на всём множестве. Более того, у фортрана есть несколько типов вызовов подпрограмм, осуществляемых по-разному.
2. Вопрос был "что делает данный оператор". Заметьте, не "как он это делает", а просто "что делает" без требования раскрыть подробности:
2.1. если Вы считаете, что он передаёт аргументы, то можно говорить о передаче аргументов, но об особенностях этой передачи говорить рано;
2.2. поскольку фортран передаёт не аргументы, а ссылки на ссылки на них, то говорить об особенности передачи аргументов просто некорректно;
2.3. однако рассматриваемый оператор не только передаёт ссылки, а ещё и передаёт управление, и тут уж "особенности передачи аргументов" совсем побоку.
Строго говоря, Ваш первый ответ про передачу единицы был верным. Не полным, далеко не полным, но формально он ещё не содержал ошибок. Ошибки посыпались, когда Вы начали раскрывать неаккуратно сформулированный вопрос.
Ай, бросьте! И обычный абстрактный ответ "Здесь и заключается ошибка"! И обычная абстрактная оговорка "То есть конечно 1 в качестве параметра передается". По его словам, Вы ответили правильно, но при этом ответили неправильно. :)Цитата:
Обычный абстрактный вопрос как дополнение к билету на экзамене )))
Гляньте на примерный кусок (к тому же ещё и неполный, там на самом деле есть ещё третья единица и собственно передача управления, которое - отдельная песня, ну и нумерацию строк я для простоты тоже опускаю) кода, генерируемого фортраном при вызове фортрановской подпрограммы:
Ваш ответ "передаёт ей входящий параметр = 1" настолько прост и наивен, что не может содержать в себе ошибку. Другое дело, что единицу фортран передаёт не эту и не там, где Вы думали. Но тем не менее он же её помимо всего прочего передаёт в конце концов!? Вон она там, самая последняя! Но товарищу надо было показать, что все вокруг негодяи, а он - Д'Артаньян, поэтому он голословно уличил Вас в недопущенной Вами ошибке, хотя бы и с оговоркой. С точки зрения логики его суждение ложно, а с точки зрения этики - подленько. :) Нет бы сказать: "Да, верно, передаёт единицу." И далее уточнить: "А как он её передаёт? И делает ли он ещё что-нибудь?" И всё было бы логично и последовательно.Код:.PSECT $CODE
; CALL SUBROUTINE
JSR R4, $OTIS ; заполнение блока параметров
BLPAR
; тут должна была быть передача управления
; . . .
.PSECT $DATAP
BLPAR: .RAD50 /SUB / ; здесь всегда 6 символов.
1 ; количество параметров
$PARAM
$PARAM: $00002 ; адрес 1-го параметра,
; адрес 2-го параметра, если бы он был,
; адрес 3-го параметра ...,
; и т.д. до конца списка параметров.
.PSECT $DATA
$00002: 1
Я на 77-м почти не работал (если не считать оффтопика). На ДВК - только фортран-4. Про него и веду речь.
А зачем нативно?
Есть подход, когда в язык не включается вообще всё, что может понадобиться (иначе получается PL/1 или Ada, которые целиком не изучит никто), а механизмы для расширения. Комплексный тип внедряется с помощью таких механизмов, библиотечно. Это хорошее решение, потому что позволяет в самом языке описать нужные вещи. Это примерно как Oberon-X, для тех, кто в теме.
Кроме того, веришь, за 20 лет программинга мне комплексные числа не понадобились НИКОГДА.
А вот аргументы в Фортран-функции передаются только одним способом: по ссылке. На асме Z80 ты бы так никогда не делал. Неэффективно. Есть риск испортить значение переменных (если функция корявая), т.е. никакой защиты. Надёжность страдает.
Ну, меня ЯП интересуют в первую очередь в соотношении минимализма к идеалу, и если ты спросишь, имеет ли смысл в наше время работать на Фортране (хотя бы для RT-11), я скорее посоветую Паскаль. Кстати, есть ведь ещё и Modula-2 для PDP-11. Есть и Active Oberon, только это закрытая разработка. К сожалению.
- - - Добавлено - - -
AFZ, допустим, комплексные числа в Фортране есть. А вот операций для работы с матрицами и множествами нету. С прогрессиями. Нативно. То есть, я рад, что в Ф. есть комп. числа, но как язык для использования он меня не устраивает, из-за корявостей.
- - - Добавлено - - -
Уже не говоря про отсутствие работы со строками. ;-)
Patron,если не ошибаюсь охотно поделился всеми возможными версиями компиляторов и языков ещё в самом начале,
они (так вышло) немного разбросаны по архиву, но в целом легко ищутся
http://archive.pdp-11.org.ru/ukdwk_a...ranIV_GromovK/
И по моему очень интересное получается (лось) обсуждение.
Верю. А мне пару раз раз потребовались - для расчетов цепей переменного тока. Первый раз это было где-то в конце 70-х или начале 80-х, тогда я это легко и непринужденно сделал на Фортране-4 Системы-360 (в смысле, ЕС ЭВМ). Второй раз - в начале 2000-х, так я изматерился, делая это средствами Визуальной Студии!..
Работа со строками - это ни разу не вычисления. А для вычислений средств Фортрана более, чем достаточно.
Я, в общем-то, программирующий электронщик. И когда мне надо рассчитать что-то по сколь-нибудь сложной формуле, вместо возни с калькулятором, я предпочитаю по-быстрому накидать программулю, которая не ошибется, в которой, промазав по нужной клавише, не надо переделывать все сначала, которую можно выполнить в цикле раз 20-50 и, просмотрев полученную таблицу выбрать подходящий вариант...
Так вот, сейчас я это делаю, в основном, на Бейсике, а во времена ДВК - Э60 я пользовал и Бейсик, и Фортран, примерно пополам.
Настоящие программисты не используют Паскаль! (с) См., например, здесь.
Компиляторы для RT-11 я выкладывал (последние версии F77 и FORTRA) и патчи Y2K к ним (и патченые дистрибы).
На стакане и вороне тоже оба варианта есть. Но я сам никогда не разбирался в различиях языка. Помню, что в F77 можно константы определять, что компилятор его во время компиляции не пишет названия текущей компилируемой (под)программы и что в случае достижения END, программа молча выходит, а не пишет сообщение об останове. На этом все, что помню про F77 заканчивается :)
Ребята ) Я хочу просто напомнить, что это не абстрактная тема о программирование вообще,
и уж точно не о правильности выбора того или иного языка программирования.
Это тема о программировании под ОС RT-11 (!) и о программировании на оборудовании DEC PDP
или совместимом.
Я не проф. программист, но по теме могу сказать вот что (частный случай УК-НЦ и любая ДВК с RT-11 на борту),
вот представьте что вам нужно что то написать системное (форматирование дискеты) - вы конечно на МАКРО-11
что то такое напишите. А представьте, что вы пишите например игру, под терминал VT52 (символьную) рогалик
какой-нибудь - неужели вы будете лопатить такой проект на макро? Это не реально. Тут либо Паскаль, либо Си,
либо Фортран (бейсик - запрещаю о нём говорить! объясню почему = системный бейсик слишком специфичный,
вильнюс бейсик полная фигня).
И так я на УК-НЦ выбрал для себя ПАСКАЛЬ+МАКРО11 как связку, поскольку у меня старшие товарищи пользуясь
тем же достигали видимых, реальных результатов, приблизиться к которым мне хотелось.
Поверьте я не встретил ни одного разработчика ПО в Зеленограде в то время кто бы писал на Фортране )))
Ни одного кто бы писал на BASIC-11 и ни одного кто бы писал что-то кроме шуток на вильнюс бейсике.
На Си как видно из архива писали для УК-НЦ, но это тогда мне было не известно (пример софт от OlegH.)
И ещё момент (!) посмотрите архив - все библиотеки со вспомогательными процедурами и функциями
написаны для Паскаля. Был (до сих пор не обнаружен) так же очень правильный спрайтовый движок
для Паскаля или Макро-11 (мог одинакого использоваться и там и там).
Поэтому на уровне хобби и учитывая возможности железок - программисты на Паскале таки писали )))
Паскаль преподавали, а Фортран уже нет. Так же никто не преподавал Модулу ! Ассемблер приходилось осваивать практически самостоятельно.
В обще школьная программа предпочитала Вильнюсовский Бейсик. А в качестве "инженерного" языка
всё время пыталась подсунуть вам Фокал ))) Хотя его УК-НЦ вариант не так уж и плох для вычислений
и инженерной графики ?
- - - Добавлено - - -
Я же писал выше о специфике выбора языка не случайно.
Те задачи которые решает AFZ ему удобнее решить на Фортране или Бейсике.
Быстро и точно для работы. Это и есть практическое (прикладное) программирование.
form системщик ) Он всех отформатирует если что ) Какой уж там Паскаль, хотя
и он Паскаль под MS DOS использовал для чего-то.
Oleg N. Cher, у тебя свои задачи и ты используешь (на чём кстати?) ту среду разработки
которая тебе удобная или принята в конторе.
И по секрету, я знаю что Титус и Patron пишут на Си (могу конечно ошибаться).
эмулятор УК-НЦ написан на Си. Меня исходники на Си пугают например своей нечитабельностью.
Я ничего не понимаю в листинге где одни скобочки )))
- - - Добавлено - - -
PDP-11 тёпленькая и родная потому что 8-миричнаяразряднаясистема исчисления однажды впившись в мозг не спешит его покинуть + МАКРО-11 ) Но я то действительно не программист )