Введение

Языки ассемблера для IBM System/360 и последующих мейнфреймов.

Серия языков ассемблера и ассемблеров IBM Basic assembly language and successors была разработана для мэйнфрейм-системы IBM System/360 и её преемников, включая IBM Z. Первый из них, Basic Assembly Language (BAL), представлял собой крайне ограниченный язык ассемблера, представленный в 1964 году и использовавшийся в системах 360 с объёмом основной памяти всего 8 КБ и только считывателем карт, перфоратором карт и принтером для ввода-вывода, в составе IBM Basic Programming Support (BPS/360). Базовый ассемблер для BAL также был доступен в составе базовой операционной системы/360 (BOS/360). Впоследствии для System/360 появился язык ассемблера с более широкими возможностями и удобством использования, например, с поддержкой макросов. Этот язык и линейка ассемблеров, которые его реализовывали, продолжали развиваться для System/370 и последующих архитектур, наследуя и расширяя его синтаксис. Некоторые специалисты в компьютерной индустрии называли их обобщённым термином "Basic Assembly Language" или "BAL". Однако многие так не делали, и сама IBM обычно именовала их просто "System/360 Assembler Language", как "Assembler" для конкретной операционной системы или платформы, или подобными названиями. Отдельные ассемблеры были известны как Ассемблер Е, Ассемблер Ф, Ассемблер Н и так далее. Программисты, работавшие с этим языком и этим семейством ассемблеров, также называли их ALC (от Assembly Language Coding) или просто "ассемблером". Последний язык, произошедший от него, известен как IBM High Level Assembler (HLASM).

Общие характеристики

Поскольку BAL является языком ассемблера, он использует нативный набор инструкций архитектуры IBM, на которой он работает, – System/360. Последующие версии BAL используют нативные наборы инструкций архитектур IBM, на которых они выполняются, включая System/360, System/370, System/370 XA, ESA/370, ESA/390 и z/Architecture. Простота машинных инструкций означает, что исходный код программы, написанной на ассемблере, как правило, значительно длиннее, чем эквивалентная программа, например, на COBOL или Fortran. Ранее скорость программ, написанных на ассемблере вручную, часто компенсировала этот недостаток, но с появлением оптимизирующих компиляторов, C для мейнфреймов и других усовершенствований, ассемблер утратил значительную часть своей привлекательности. Тем не менее, IBM продолжает совершенствовать ассемблер, и он по-прежнему используется, когда требуется максимальная скорость или очень точный контроль. Однако все последующие версии BAL от IBM включают в себя развитую систему макросов, позволяющую создавать гораздо более компактный исходный код. Еще одна причина использования ассемблера заключается в том, что не ко всем функциям операционной системы можно получить доступ на языках высокого уровня. Интерфейсы прикладных программ операционных систем IBM определены как набор инструкций "макро" на языке ассемблера, которые обычно вызывают инструкции Supervisor Call (SVC) [например, в z/OS] или Diagnose (DIAG) [например, в z/VM] для вызова процедур операционной системы. Использовать службы операционной системы из программ, написанных на языках высокого уровня, можно с помощью подпрограмм на ассемблере.

Формат инструкции сборщика

Формат инструкций языка ассемблера отражает структуру перфокарты в 80 столбцов, хотя последующие версии ослабили большинство ограничений. Необязательная метка или имя инструкции представляет собой строку из буквенно-цифровых символов, начинающуюся в столбце 1. Первый символ должен быть буквой. В более поздних версиях к допустимым символам в метках были добавлены @, #, $, и пробел, а размер метки был увеличен с первоначальных шести до восьми символов, а затем до практически неограниченной длины. Код операции, или "мнемоника", может начинаться в любом столбце правее столбца 1, отделённый от метки пробелом. Код операции представлял собой только машинную инструкцию (макросы отсутствовали), обычно состоящую из 1, 2, 3 или, реже, 4 букв. Код операции был расширен до восьми символов, а затем до практически неограниченной длины. Поле операндов может начинаться в любом столбце правее кода операции, отделённом от него как минимум одним пробелом. Пробелы недопустимы в операндах, за исключением символьных констант. Поле операндов, состоящее из одного или нескольких операндов, является необязательным в зависимости от кода операции. Необязательные комментарии могут располагаться справа от поля операндов, отделённые как минимум одним пробелом. Базовый язык ассемблера не допускает переноса инструкций на следующую строку. В более поздних версиях ассемблера перенос обозначается любым непробельным символом в столбце 72 продолжаемой инструкции. Базовый язык ассемблера требует, чтобы столбец 72 был пустым. "Комментарий на всю карту" обозначается звездочкой (*) в столбце 1. Столбцы 73–80 перфокарты, называемые полем идентификационной последовательности, могут использоваться программистом для любых целей, но обычно содержат номера последовательности для сортировки перемешанной колоды карт. Базовый язык ассемблера также допускает альтернативный формат инструкции, начинающийся в столбце 25, позволяя скомпилированную инструкцию разместить на той же карте, начиная со столбца 1. Эта опция не была продолжена в более поздних версиях ассемблера.

Виды инструкций

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

Инструкции для сборщика

Инструкции ассемблера, иногда называемые директивами, псевдооперациями или псевдоопциями в других системах, являются запросами к ассемблеру выполнить различные операции в процессе генерации кода. Например, CSECT означает "начать здесь секцию кода"; DSECT предоставляет определения данных для структуры, но не генерирует код; DC определяет константу, которая должна быть помещена в объектный код. Одной из наиболее важных инструкций ассемблера является USING, которая поддерживает базовое смещение адресации архитектуры S/360. Она указывает ассемблеру, какой базовый регистр и смещение следует использовать для относительного адреса. В BAL она была ограничена формой USING base,reg 1, ,reg n. Адреса машинных инструкций на S/360 задают смещение (0–4095 байт) от значения в базовом регистре; в то время как более поздние версии архитектуры добавили форматы относительной адресации, старые форматы все еще используются многими инструкциями. USING позволяет программисту сообщить ассемблеру, что указанные базовые регистры, как предполагается, содержат адрес "base", base+4096 (если указано несколько регистров) и т.д. Это лишь предоставляет удобство для программиста, который в противном случае должен был бы указывать базовый регистр в каждой инструкции. Программисты по-прежнему несут ответственность за фактическую загрузку адреса "base" в регистр перед записью кода, который зависит от этого значения. Соответствующая инструкция ассемблера DROP отменяет действие предыдущей инструкции USING.

Макро и условная сборка

Ассемблеры Basic Programming Support не поддерживали макросы. В более поздних версиях ассемблера, начиная с Assembler D, программисту предоставляется возможность объединять инструкции в макросы и добавлять их в библиотеку, которую затем можно вызывать в других программах, как правило, с параметрами, подобно возможностям препроцессора в C и родственных языках. Макросы могут содержать условные инструкции ассемблера, такие как AIF (конструкция «if»), используемые для генерации различного кода в зависимости от выбранных параметров. Это делает механизм макросов в данном ассемблере очень мощным. В то время как многострочные макросы в C являются исключением, определения макросов в ассемблере могут легко насчитывать сотни строк.

Макросы операционной системы

Большинство программ нуждаются в услугах операционной системы, а ОС предоставляет стандартные макросы для запроса этих услуг. Это аналогично системным вызовам Unix. Например, в MVS (впоследствии z/OS), STORAGE (с параметром OBTAIN) динамически выделяет блок памяти, а GET извлекает следующую логическую запись из файла. Эти макросы зависят от конкретной операционной системы; в отличие от ряда языков программирования высокого уровня, языки ассемблера IBM для мэйнфреймов не предоставляют операционно-независимых инструкций или библиотек для выделения памяти, выполнения операций ввода-вывода и т.п., и различные операционные системы IBM несовместимы на уровне системных сервисов. Например, запись в последовательный файл будет кодироваться по-разному в z/OS и z/VSE.

Версии

За исключением ассемблеров для IBM System/360 Model 20, ассемблеры IBM в основном обеспечивали обратную совместимость с более новыми версиями. Различия касались главным образом сложности допустимых выражений и обработки макросов. Ассемблеры OS/360 изначально классифицировались по требованиям к объему памяти.

Ассемблеры для базовой поддержки программирования

Ассемблер для BPS – это подлинный "базовый ассемблер". Он был разработан для загрузки с перфокарт и работал на System/360 объемом 8 КБ (за исключением модели 20). Он не поддерживает макроинструкции или расширенные мнемонические коды (например, BH вместо BC 2 для перехода, если код состояния 2 указывает на результат сравнения "выше"). Он может собирать только один блок управления и не допускает фиктивных блоков (определений структур). Выражения в скобках запрещены, а выражения ограничены тремя членами, при этом допустимыми операторами являются только "+", "-", и "*".

Сборщик базовой операционной системы

Базовая операционная система имеет две версии ассемблера. Обе требуют 16 КБ памяти, одна загружается с магнитной ленты, а другая – с диска.

Сборщик D

Ассемблер D был ассемблером DOS/360 для машин с объемом памяти 16 КБ. Он выпускался в двух вариантах: версия объемом 10 КБ для машин с минимальным объемом памяти 16 КБ и версия объемом 14 КБ для машин с 24 КБ. Также был доступен ассемблер уровня F для DOS-машин с 64 КБ или более. Ассемблеры D предлагали почти все возможности более поздних версий.

Сборщик E и F

Ассемблер E был разработан для работы в системе OS/360, требующей минимум 32 КБ оперативной памяти, при этом сам ассемблер занимает 15 КБ. Ассемблер F может работать как под DOS/360, так и под OS/360 на системе с 64 КБ памяти, при этом для его работы требуется 44 КБ. Эти ассемблеры являются стандартной частью OS/360, а версия, которая была сгенерирована, определялась на этапе создания системы (SYSGEN).

Сборщик H

Assembler H работал на OS/360 и последующих версиях; он был быстрее и мощнее Assembler F, но язык макросов не был полностью совместим. Assembler H Version 2 был анонсирован в 1981 году и включал поддержку расширенной архитектуры (XA), включая директивы AMODE и RMODE. В 1994 году он был снят с продаж, а в 1995 году поддержка прекращена. Он был заменен High Level Assembler.

Сборщик XF

Assembler XF – это в основном совместимое обновление Assembler F, включающее новые инструкции архитектуры System/370. Эта версия предоставляет единый ассемблер для систем OS/VS, DOS/VS и VM. Среди других изменений – снятие ограничений на выражения и обработку макросов. Для работы Assembler XF требуется минимальный размер раздела/региона 64 КБ (виртуальной памяти). Рекомендуемый размер – 128 КБ.

Высокоуровневый сборщик

High Level Assembler или HLASM был выпущен в июне 1992 года, заменив Assembler H версии 2 от IBM. Он являлся стандартным транслятором для систем System/370 и System/390 и поддерживал операционные системы MVS, VSE и VM. По состоянию на 2023 год это текущий ассемблерный язык программирования IBM для операционных систем z/OS, z/VSE, z/VM и z/TPF на мэйнфреймах с архитектурой z/Architecture. Версия 6 и более поздние также работают под Linux и генерируют объектные файлы ELF или GOFF (эта среда иногда называется Linux on IBM Z). Работая в IBM, Джон Роберт Эрман создал HLASM и был его ведущим разработчиком, за что его считают «отцом ассемблера высокого уровня». Несмотря на название, сам по себе HLASM не обладает многими функциями, обычно ассоциируемыми с ассемблером высокого уровня. Название, вероятно, связано с расширенными возможностями макроязыка, такими как возможность написания пользовательских функций. Ассемблер в основном похож на Assembler H и Assembler (XF), включая модификации SLAC (Stanford Linear Accelerator). Среди добавленных функций – указание CSECT/DSECT для счетчика адреса, зависимые и помеченные операторы USING, список активных операторов USING, указание, является ли переменная читаемой или записываемой в перекрестных ссылках, и разрешение использования символьных имен в смешанном регистре. Директива RSECT (Read only Control Section) позволяет ассемблеру проверять повторный вход на уровне каждого сегмента. Ранее RSECT был «незадокументирован и реализован непоследовательно в Assembler H».

7090/7094 Сборщик вспомогательных пакетов

Пакет поддержки IBM 7090/7094, известный как SUPPAK, "состоит из трех программ, предназначенных для сборки, тестирования и выполнения программ, написанных для System/360, на ЭВМ IBM 709, 7090, 7094 или 7094 II". Этот кросс-ассемблер работает на системе 7090 или 7094 и использовался во время разработки System/360. Ассемблер поддерживает шестибитный набор символов BCD и восьмибитный EBCDIC.

Сборщики IBM System/360 Model 20

IBM поставляла два ассемблера для модели 20: базовый ассемблер модели 20 и ассемблер модели 20 DPS/TPS. Оба поддерживали только инструкции, доступные на модели 20, включая уникальные инструкции CIO, TIO, XIOB, SPSW, BAS, BASR и HPR. Базовый ассемблер является несколько более ограниченной версией System/360 Basic Assembler; в частности, символы ограничены длиной в четыре символа. Эта версия способна работать на системе с 4 КБ памяти, а поддержка макросов ограничена макросами IOCS. Версии для карт – это двухпроходные ассемблеры, поддерживающие только ввод/вывод с карт. Версии для магнитной ленты – однопроходные, использующие магнитную ленту для промежуточного хранения. Программы, собранные с помощью CPS Assembler, могут адресовать максимум 16 КБ. Он не поддерживает инструкции передачи из памяти в память (SS) или преобразования в двоичный код (CVB), преобразования в десятичный код (CVD), прямого чтения (RDD) и прямой записи (WRD). Он включает четыре инструкции, уникальные для модели 44: Change Priority Mask (CHPM), Load PSW Special (LPSX), Read Direct Word (RDDW) и Write Direct Word (WRDW). Он также включает директивы для обновления исходной программы, функцию, выполняемую утилитами в других системах (SKPTO, REWND, NUM, OMIT и ENDUP).

Сборщик G

"Assembler G" – это набор модификаций, внесённых в Assembler F в 1970-х годах Университетом Ватерлоо (Assembler F был и остаётся программным обеспечением с открытым исходным кодом). Улучшения касаются, главным образом, более эффективной обработки ввода-вывода и оптимизированной буферизации, что существенно повышает скорость сборки. "Assembler G" никогда не был продуктом IBM.

Асембляторы, не IBM

Существовало несколько ассемблеров, совместимых с IBM, для специализированных сред. Серии компьютеров Univac 90/60, 90/70 и 90/80 от Unisys были разработаны для работы с ассемблером формата IBM, поскольку эти серии машин были аналогами систем S/360 и S/370. Серия Fujitsu BS2000 также была создана как аналог 370, используя те же ресурсы, что и Univac, и до сих пор используется в некоторых странах Европы. Dignus LLC Systems/ASM – это ассемблер, совместимый с HLASM, который может работать непосредственно на системах IBM или как кросс-ассемблер. Бесплатный PC/370, разработанный Доном Хиггинсом, позднее был приобретен компанией Micro Focus. z390 – это ассемблер и эмулятор System 390, также разработанный Доном Хиггинсом и написанный на Java. Он имеет открытый исходный код и доступен по адресу http://www.z390.org/. Университет штата Пенсильвания разработал пакет ASSIST, включающий в себя ассемблер и интерпретатор для System 370. Tachyon Software LLC поставляет Tachyon Assembler Workbench, работающий в операционных системах Windows, Linux/x86, Linux для S/390 и zSeries, AIX и Solaris. GNU Assembler (gas) входит в состав GNU Compiler Collection (gcc) для Linux на OS/390 и IBM Z. Этот ассемблер имеет уникальный синтаксис, несовместимый с другими ассемблерами для архитектур IBM.

Важность

Первоначально все операционные системы System/360 были написаны на языке ассемблера, и все системные интерфейсы определялись макроопределениями. Доступ из языков высокого уровня (HLL) был ограничен возможностями, предоставляемыми этими языками, а для других системных вызовов требовалось написание подпрограмм на ассемблере, вызываемых из программ HLL. Кроме того, IBM предоставляла возможность установки настраивать функции ОС с помощью так называемых Exits – пользовательских подпрограмм, которые могли расширять или изменять стандартные функции ОС. Эти Exits требовалось реализовывать на языке ассемблера. Позже IBM переписала OS/360 на язык системного программирования PL/S, но, за исключением короткой тестовой версии, отказалась от выпуска компилятора PL/S для пользователей. В результате этих факторов язык ассемблера широко использовался в системах IBM на протяжении многих лет.