Примеры программирования на языке ассемблер. Начинаем программировать на языке ассемблера. Какой ассемблер лучше
Разработка комплекса П-1000 «Вулкан» была начата в соответствии с правительственным постановлением от 17 мая 1979 г.
ПКР 3М-70 имела аналогичный П-500 турбореактивный двигатель,
однако за счет использования более мощной стартово-разгонной ступени (СРС) с
управляемыми соплами, а также более современных конструкционных материалов (в частности, титановых сплавов), а также
ослабления броневой защиты имела увеличенную до 700 км дальность.
Начало испытаний нового комплекса началось 3.12.1982 года в 10.55 по московскому времени на полигоне близ поселка Ненокса Архангельской области. Первый пуск ракеты прошел неудачно: стартовый агрегат после отработки не отделяется от ракеты, в результате чего, ракета начала разваливаться в полете и после 8-ми секунд после запуска падает. Следующий пуск, проведенный 9.04.1983 года, также оказывается неудачным, ракета падает на 9 секунде полета. По ходу проведения расследования неудачных пусков, установлено, что причина неполадок в ракете кроется в системе управления. Поэтому к третьему пуску, прошедшему в июне 1983 года, систему управления дорабатывают, и ракета успешно отработала по всей траектории полета.
Основные испытания ПКРК «Вулкан» начинаются 22.12.1983 года с борта ПЛАРК проекта 675 модернизированной до проекта 675МКВ. Модернизация заключалась в получении нового ПКРК П-1000. Всего данную модернизацию в свое время прошли четыре ПЛАРК проекта 675. Совместные испытания модернизированных ПЛАРК и новых установленных комплексов П-1000 начинаются в 1985 году. Был произведен залп двумя ракетами, которые успешно уничтожили установленную цель, и это несмотря на то, что произошел сбой в работе системы поддержки давления в отсеке приборного оборудования и ошибку при старте ракеты оператора. Следующий пуск в рамках программы совместных испытаний осуществлен 8.11.1985 года - был дан залп тремя ракетами, который, в общем, признан успешным – две ракеты успешно уничтожили установленную цель, у третьей ракеты произошел в полете отказ РЛС визира. В общем, было проведено 18 испытательных пусков ракет и 11 из них признаются успешными.
До конца 1985 года были закончены доработки системы управления и КПА, по окончанию которых подписывают Акт окончания совместных испытаний, в котором рекомендуется принять ПКРК «Вулкан» на вооружение ВМФ с учетом проведения в 1986 году контрольных испытаний. Для испытаний было выделено 8 ракет – залповый пуск 4-х ракет и одиночный пуск остальных в рамках различных испытательных программ:
- пуск 1-ой ракеты осуществили 24.05.1986 года, в рамках программы испытаний системы управления ракеты комплекса «Базальт». Пуск признан успешным;
- пуск 2-й ракеты осуществили 18.06.1986 года, в рамках проверки помехозащищенности. Пуск признан успешным;
- пуск 3-й ракеты осуществили 19.06.1986 года, в рамках проверки помехозащищенности. Пуск признан успешным;
- залповый пуск 4-х ракет состоялся 4.07.1986 года, залп признан успешным. Три из четырех ракет были оснащены телеметрией, так как наземное оборудование на полигоне не могло осуществить принятие данных сразу четырех ракет. Четвертая ракета, без телеметрии, по неизвестной причине сбилась с траектории полета и цель не поразила.
ПКРК «Вулкан» (П-1000) принимают на вооружение 18.12.1987 года.
Комплекс мог поставляться в трех вариантах – наземный (береговой) с ПУ типа СМ-49 (использовался при первых испытаниях 1982 года), надводный с ПУ типа СМ-248 (аналог комплекса «Базальт»), подводный (надводный старт) с ПУ, по типу ПКРК «Базальт».
Как в свое время и «Базальт »,
новый комплекс также установили на ПЛАРК практически без доработок носителя. Применение крылатых ракет комплекса «Вулкан» планировалось на АПЛ
проекта 675МКВ. Начиная с конца 80-х модернизацию по проекту 675МКВ прошло пять кораблей проекта 675МК (К-1, К-22, К-34, К-35, К-10).
Модернизация ПЛАРК К-10 не была закончена. Боекомплект ПЛАРК проекта 675МКВ
составлял 8 КР, размещаемых в контейнерах. Для управления ракетной стрельбой корабль
получал комплекс «Аргон-675КВ». Для целеуказания по данным от ИСЗ использовалась
система «Касатка». Старт ракет был по-прежнему надводный из поднятых контейнеров.
В 1992-94 все 4 ПЛАРК проекта 675МКВ были списаны.
На крейсере «Варяг» («Червона Украина») пр.1164, вступившем в строй 16 октября 1989 г.,
вместо ПКР «Базальт» были установлены ракеты «Вулкан» (предполагалась аналогичная замена и для предыдущих кораблей проекта).
Перезарядка комплексов «Базальт» и «Вулкан» производится только на базах кораблей, т.к. представляет из себя довольно трудоемкую операцию.
Серийным производством ракет 3М-70 для комплекса занималось оренбургское
Советский / российский противокорабельный ракетный комплекс (ПКР). Является развитием системы П-500 «Базальт»
История создания
Ракета П-1000 «Вулкан» была создана как последующее развитие успешной противокорабельной ракеты П-500 «Базальт», в свою очередь, являющейся развитием старой ракеты П-35. Целью конструкторов было создание более дальнобойной ракеты, при сохранении прежних габаритов и массы и возможности применять без капитальной модернизации существующие пусковые комплексы и инфраструктуру для П-500. Постановление правительства от 15 мая 1979 года дало начало разработке новой ПКР П-1000 «Вулкан».
Первый испытательный пуск с наземного стенда в рамках лётно-конструкторских испытаний произошёл на полигоне в Нёноксе в июле 1982 года.
Создание системы управления и ряда другой аппаратуры закончились в 1985 году.
Конструкция
В главных элементах конструкции, ракета П-1000 повторяет прежнюю П-500 «Базальт». Она имеет сигарообразную форму с треугольным раскладным крылом и воздухозаборником двигателя под фюзеляжем. Главные различия между П-1000 и ее предшественником связаны с уменьшением массы конструкции ракеты ради увеличения запаса топлива.
Корпус П-1000 был сделан с использованием титановых сплавов, это позволило уменьшить вес конструкции, не снизив ее прочности. Маршевая двигательная установка та же, что и у П-500; это короткоресурсный турбореактивный двигатель КР-17В. Новый стартовый ускоритель повышенной мощности, с отклоняемым вектором тяги, разрешает оптимизировать траекторию ракеты на старте и обеспечить взлет с большим стартовым весом. Масса осколочно-фугасной боевой части была уменьшена до 500 килограмм. Все эти меры позволили увеличить запас топлива не меняя габаритов ракеты, и увеличить ее радиус действия до 700-1000 км.
Ракета П-1000 «Вулкан» применяет аналогичную П-500 «Базальт» комбинированную схему полета. Большую часть траектории ракета преодолевает на большой высоте, а вблизи цели снижается, и оставшееся расстояние проходит на сверхмалой высоте (около 15-20 метров), скрываясь от обнаружения радарами за горизонтом. Из-за большего запаса топлива на П-1000, продолжительность ее маловысотного участка может быть увеличена, что делает ракету менее уязвимой к дальнобойным ЗРК неприятеля.
ГСН ракеты применяет алгоритмы идентификации и распределения целей, созданные на основе работы над П-700 "Гранит". Ракета может идентифицировать отдельные корабли, анализировать их положение в ордере и выбирать наиболее ценные. Подобно П-700, ракеты П-1000 обмениваются данными во время атаки и формируют общую стратегию действий, распределяя цели и выполняя одновременный заход с разных направлений.
ТТХ
Длина: 11,7 м
-Диаметр: 0,88 м
-Размах крыла: 2,6 м
-Стартовая масса: 7000-8000 кг
-Скорость число Маха (км/ч):
-на высоте: 2,5 (3077)
-у поверхности: 2 (2460)
-Максимальная дальность стрельбы: до 1000 км
-Система управления: инерциальная + радиолокационная
-Боевая часть:
-фугасно-кумулятивная: 500 кг (масса ВВ)
-ядерная: 350 кт
Противокорабельная крылатая ракета
П-1000 "Вулкан" / 3М70 разработана НПО машиностроения (г.Реутов) по Постановлению Совета Министров СССР от 17 мая 1979 г. Ракетный комплекс является дальнейшим развитием комплекса П-500 с сохранением пускового оборудования и заметным увеличением дальности действия за счет использования нового стартового двигателя, увеличения объемов топлива маршевой ступени, снижения массы бронирования и других улучшений.
Первый испытательный пуск ракеты П-1000 с наземного стенда СМ-49 в Неноксе выполнен 3 декабря 1982 г. Испытания с подводной лодки проекта 675МКВ начаты 22 декабря 1983 г. Проведение совместных испытаний комплекса П-1000 и ПЛА пр.675МКВ начаты в 1985 г. В результате летно-конструкторских и совместных испытаний произведено 18 пусков ракет из которых 11 пусков признаны успешными. В декабре 1985 г. подписан Акт об окончании совместных испытаний с рекомендацией принятия на вооружение комплекса П-1000 "Вулкан".
Комплекс "Вулкан" принят на вооружение 18 декабря 1987 г. Ракета П-1000 производилась с 1985 г. по 1992 г.
Ракеты П-1000 "Вулкан" были приняты на вооружение подводных лодок проекта 675МКВ ("МКВулкан") и ракетных крейсеров проекта 1164.
Ракета 3М70 комплекса П-1000 "Вулкан"
(фото Дмитрий Стогний, http://militaryphotos.net/)
Западное наименование ракеты - SS-N-12 mod.2 SANDBOX.
Носители ракетного комплекса П-1000 "Вулкан" в ВМФ России
- Атомные подводные лодки с крылатыми ракетами (ПЛАРК) проекта 675МКВ - переоборудование 5 ПЛАРК проекта (К-1, К-22, К-34, К-35 и К-10) по проекту 675МКВ велось СРЗ "Звездочка". Переоборудование ПЛАРК К-1 начато 15 декабря 1981 г. и завершено в 1983 г. Модернизация ПЛАРК К-10 не завершена, всего переоборудовано 4 ПЛАРК. На ПЛАРК пусковые установки комплекса П-500 заменены пусковыми комплекса "Вулкан" (8 шт на ПЛ). Пусковые установки с надводным стартом. Для целеуказания по данным ИСЗ использована система "Касатка". ПЛАРК выведены из состава ВМФ начиная с июля 1992 г. по июль 1994 г. (все 4 шт).
- Ракетные крейсеры проекта 1164: ракетный крейсер "Варяг" (вступил в строй 16 октября 1989 г. под названием "Червона Украина") изначально вооружен комплексом П-1000. Так же вероятно к 2006 г. на этот ракетный комплекс перевооружен ракетный крейсер "Москва". Так же планировалась установка комплекса на недостроенный ракетный крейсер "Украина" (бывший "Адмирал Лобов", находится на ССЗ в Николаеве). На кораблях проекта 1164 устанавливается 16 неперезаряжаемых пусковых установок.
Конструкция ракеты
Конструкция ракеты продолжает линейку ракет разработки НПО машиностроения, которые берут своё начало с ракеты П-5 и является близкой к предыдущей модификации - ракете П-500 "Базальт".
Ракета оснащается двумя вариантами стартово-разгонной ступени - новой большой с увеличенной мощностью и продолжительностью работы или старой от ракеты комплекса П-500.
Двигатели:
- стартово-разгонная ступень - РДТТ с управляемыми соплами, более мощный, чем у ракет П-500;
- маршевый - короткоресурсный ТРД КР-17В, аналогичный двигателю ракеты комплекса П-500. Разработан ОКБ-300 ГКАТ.
Длина - 11.7 м Диаметр корпуса - 0.88 м Размах крыла – 2.6 м Масса стартовая - 9300 кг Масса без стартового двигателя - 5070 кг Дальность действия - 550-700 км (в зависимости от профиля полета, в некоторых источниках указывается дальность 1000 км) Скорость полета: - 2 М (на малой высоте) - 2.5 М (на большой высоте) Высота полета - 15-20 м (минимальная)ТТХ ракеты П-1000 "Вулкан"
Модель ракеты 3М70 комплекса "Вулкан" с увеличенной СРС, авиасалон МАКС-2009 (http://bastion-karpenko.narod.ru/)
Ракета может нести два типа боевых частей: - фугасно-кумулятивная - по расчетам для уничтожения авианосца требуется попадание 3-х ракет с такими БЧ; - ядерная мощностью 350 кт.Боевое оснащение
Пуск ракеты П-1000 "Вулкан" с ракетного крейсера "Варяг" проекта 1164
(http://milparade.ru/)
Система управления инерциальная с коррекцией по данным радиолокационной головки самонаведения (ГСН). Разработчик - ЦНИИ "Гранит", главный конструктор системы управления А.В.Чижов. Селекция целей вероятно автоматическая. На ракете использованы выполненные на новой элементной базе автопилот А21 с БЦВМ Б9, что в купе с новым стартовым двигателем позволило увеличить дальность действия. Существенно улучшена помехозащищенность РЛС ГСН за счет улучшения бортовой БЦВМ.Система управления и наведение
Модификации:
П-1000 "Вулкан" / 3М70 - базовые вариант ракетного комплекса и ракеты.
"Новый оборонный заказ. Стратегии"
После многих лет занятия чем не попадя, решил вернуться к истокам. К программированию. Опять же, ввиду множества «современных достижений» в этой области было трудно определиться, чего же на самом деле не хватет, за что взяться чтобы было и приятно и полезно. Попробовав много чего понемногу, все же решил вернуться туда, куда тянуло с первых дней знакомства с компьютером (еще с копией творения сэра Синклера) – к программированию на ассемблере. На самом деле, в свое время Ассемблер я знал достаточно неплохо (в данном случае говорю про x86), но почти 15 лет ничего на нем не писал. Таким образом это своеобразное возвращение «блудного сына».
Но тут поджидало первое разочарование. Найденные на просторах Интернета книги, руководства и прочие справочники по ассемблеру, к моему глубокому сожалению, содержат минимум информации о том, как надо программировать на ассемблере, почему именно так, и что это дает.
Пример из другой области
Если брать в качестве примера бокс, то все подобные руководства учат исполнять удар, перемещаться стоя на полу, но абсолютно отсуствует то, что делает бокс - боксом, а не «разрешенным мордобитием». То есть комбинационная работа, особенности использования ринга, защитные действия, тактическое построение боя и, тем более, стратегия боя не рассматриваются вообще. Научили человека бить по «груше» и сразу на ринг. Это в корне неверно. Но именно так построены практически все «учебники» и «руководства» по программированию на ассемблере.
Однако нормальные книги должны быть, скорее всего под горой «шлака» я их просто не нашел. Поэтому прежде чем восполнять знания глобальным описание архитектуры, мнемоники и всяческих фокусов «как слепить фигу из 2х пальцев», подойдем к вопросу программирования на ассемблере с «идеологической» точки зрения.
Идилия?
Маленькое замечание, далее по тексту будет использована классификация, отличающаяся от распространненной в настоящее время. Однако это не является поводом для «споров о цвете истины», просто в данном виде проще объяснить точку зрения автора на программирование.Итак, на сегодняшний день, казалось бы, для программистов наступила эпоха счастья. Огромный выбор средств на все случаи жизни и пожелания. Тут тебе и миллионы «фреймворков»/«паттернов»/«шаблонов»/«библиотек» и тысячи средств «облегчающих» программирование, сотни языков и диалектов, десятки методологий и различные подходы у программированию. Бери – нехочу. Но не «берется». И дело не в религиозных убеждениях, а в том, что это все выглядит как попытка питаться чем-то невкусным. При желании и усердии можно приноровиться и к этому, конечно. Но, возвращаясь к программированию, в большинстве из предлагаемого не видно технической красоты – видно лишь множество «костылей». Как результат, при использовании этих «достижения», из-под «кисти художников» вместо завораживающих пейзажей выходит сплошная «абстракция», или лубки - если повезет. Неужели большинство программистов такие бездари, неучи и имеют проблемы на уровне генетики? Нет, не думаю. Так в чем же причина?
На сегодняшний день имеется множество идей и способов программирования. Рассмотрим наиболее «модные» из них.
- Императивное программирование – в данном подходе программист задает последовательность действий, приводящих к решению задачи. В основе лежит разделение программы на части, выполняющие логически независимые операции (модули, функции, процедуры). Но в отличии от типизированного подхода (см. ниже) тут есть важная особенность – отсутствие «типизации» переменных. Иными словами отсутствует понятие «тип переменной», вместо него используется понимание, что значения у одной и той же переменной могут иметь различный тип. Яркими представителем данного подхода являются Basic, REXX, MUMPS.
- Типизированное программирование – модификация императивного программирования, когда программист и система ограничивают возможные значения переменных. Из наиболее известных языков - это Pascal, C.
- Функциональное программирование – это более математический способ решения задачи, когда решение состоит в «конструировании» иерархии функций (и соответственно создание отсутствующих из них), приводящей к решению задачи. Как примеры: Lisp, Forth.
- Автоматное программирование – подход, где программист строит модель/сеть, состоящую из обменивающихся сообщениями объектов/исполнительных элементов, как изменяющих/хранящих свое внутреннее «состояние» так и могущих взаимодействовать с внешним миром. Иными словами это то, что обычно называют «объектное программирование» (не объектно-ориентированное). Этот способ программирования представлен в Smalltalk.
Как видим, каждый из подходов (даже без учета ограничений конкретных реализаций) накладывает собственные ограничения на саму технику программирования. Но иначе и быть не может. К сожалению, эти ограничения зачастую созданы искуственно для «поддержания чистоты идеи». В итоге, программисту приходится «извращать» изначально найденное решение в вид, хоть как-то соответствующий идеологии используемого языка или используемому «шаблону». Это даже без учета новомодных методик и способов проектирования и разработки.
Казалось бы, программируя на ассемблере, мы вольны делать все и так, что и как пожелаем и позволяет нам «железо». Но как только нам захочется использовать «универсальный драйвер» для какого-либо типа оборудования, мы вынуждены менять свободу «творчества» на предписанные (стандартизированные) подходы и способы использования драйвера. Как только нам понадобилась возможность использовать наработки других коллег или дать им возможность делать тоже самое с плодами нашего труда - мы вынуждены менять свободу выбора взаимодействия между частями программы на некие обговоренные/стандартизированные способы.
Таким образом та «свобода», за которой часто рвутся в ассемблер зачастую оказывается «мифом». И этому (пониманию ограничений, и способам их организации), на мой взгляд, должно уделяться повышенное внимание. Программист должен понимать причину вносимых ограничений, и, что отличает ассемблер от многих языков высокого уровня, иметь возможность менять их, при возникновении такой необходимость. Однако сейчас программист на ассемблере вынужден мириться с ограничениями, вводимыми языками высокого уровня, не имея «пряников» доступных программирующими на них. С одной стороны, операционные системы предоставляют множество уже реализованных функций, есть готовые библиотеки и много многое другое. Но способы их использования, как специально, реализованы без учета вызова их из программ, написанных на ассемблере, а то и вообще наперекор логике программирования для x86 архитектуры. В результате, сейчас программирование на ассемблере с вызовом функций ОС или внешних библиотек языков высокого уровня – это «страх» и «ужас».
Чем дальше в лес, тем толще
Итак, мы осознали, что хотя ассемблер очень прост, но пользоваться им надо уметь. И основная слажность - это необходимость взаимодействия со средой исполнения, где запускается наша программа. Если программисты на языках высокого уровня уже имеют доступ к необходимым библиотекам, функциям, подпрограммам на многие случаи жизни и им доступны способы взаимодействия с внешним миром, в виде, согласованном с идеей языка, то программисту на ассемблере приходится продираться сквозь чащу всевозможных препонов, водруженных на пустом месте. Когда смотришь на то, что генерируют языки высокого уровня при компиляции, то складывает ощущение, что, те, кто писал компиляторы, либо понятия не имеют, как работает процессор с архитектурой x86, «или одно из двух» (ц).Итак, давайте по-порядку. Программирование - это в первую очередь инженерия, то есть научное творчество, направленное на эффективное (по показателям надежности, использования доступных ресурсов, сроков реализации и удобства применения) решение практических задач. И, в основе любой инженерии лежит системный подход. То есть нельзя рассматривать любое решение как некий «неразборный» черный ящик, функционирующий в полном и идеальном вакууме.
Еще один пример из другой области
Как яркий пример системного подхода можно привести производство грузовиков в США. В данном случае, производитель грузовика – это просто изготовитель рамы и кабины + сборщик конструктора. Все остальное (двигатель, трансмиссия, подвеска, электрооборудование и т.д.) берется исходя из пожеланий заказчика. Захотел один заказчик получиться себе некий Kenworth с двигателем от Detroit Diesel, ручной коробкой Fuller, рессорной подвеской от какой-нибудь Dana – пожалуйста. Понадобилась другу этого заказчика та же модель Kenworth, но с «родным» двигателем Paccar, коробкой-автоматом Allison и пневмоподвеской от другого производителя – легко! И так делают все сборщики грузовиков в США. То есть грузовик – это система, в котором каждый модуль может быть заменен на другой, того же назначения и безпроблемно состыкован с уже имеющимися. Причем способ стыковки модулей сделан с максимально доступной универсальностью и удобством дальнейшего расширения функционала. Вот к чему должен стремиться инженер.
К сожалению, нам придется жить с тем, что есть, но в дальнейшем подобного следует избегать. Итак, программа – это, по сути, набор модулей (невожно как они называются, и как себя «ведут»), компонуя которые мы добиваемся решения стоящей задачи. Для эффективности крайне желательно, чтобы можно было эти модули использовать повторно. Причем не просто использовать любой ценой, а использовать удобным способом. И вот тут нас ждет очередной неприятный «сюрприз». Большинство языков высокого уровня оперируют такими структурными единицами как «фунция» и «процедура». И, как способ взяимодействия с ними, применяется «передача параметров». Это вполне логично, и тут никаких вопросов не возникает. Но как всегда, «важно не то, что делается – важно как делается» (ц). И вот тут начинается самое непонятное. На сегодня распространены 3 способа организации передачи параметров: cdecl , stdcall , fastcall . Так вот, ни один из этих способов не является «родным» для x86. Более того, все они ущербны с точки зрения расширения функционала вызываемых подпрограмм. То есть, увеличив количество передаваемых параметров, мы вынуждены менять все точки вызова этой функции/подпрограммы, или же плодить новую подпрограмму с похожим функционалом, которая будет вызываться немного иным способом.
Указанные выше методы передачи параметров относительно неплохо работают на процессорах с 2мя раздельными стеками (стеком данных, и стеком адресов/управления) и развитыми командами манипулирования стеком (хотя бы индексное обращение к элементам стека). Но при программировании на x86 приходится сначала извращаться при передаче/получении параметров, а потом не забыть «структурное» их удаление из стека. Попутно стараясь угадать/рассчитать максимальную глубину стека. Напомним, что x86 (16/32 битный режим), это процессор, у которого:
- специализированные регистры (РОНы – регистры общего назначения – как таковые отсутствуют: то есть, мы не можем одной командой умножить содержимое регистра GS на значение из EDI и результат получить в паре EDX:ECX, или же разделить значение из пары регистров EDI:ESI на содержимое регистра EAX);
- регистров мало;
- один стек;
- ячейка памяти не дает никакой информации от типа хранящегося там значения.
Следующая особенность взамиодействия с готовыми модулями, написанными на «языках высокого уровня»- это «борьба» с «типами переменных». С одной стороны, причина появления типов переменных ясна – программист знает какие значения используются внутри его подпрограммы / модуля. Исходя из этого, видится вполне логичным, что, задав тип значений переменной, мы можем «упростить» написание программы, возложив контроль типов/пределов значений на транслятор языка. Но и тут с водой выплеснули младенца. Потому как любая программа пишется не для генерации сферических коней в вакууме, а для практической работы с пользовательскими данными. То есть очевидное нарушение системного подхода – как будто разработчики языков высокого уровня рассматривали свои системы без учета взаимодействия с внешним миром. В итоге, программируя на типизированном языке разработчик должен предсматривать все возможные виды «неправильных» входных данных, и искать способы обхода неопределенностей. И вот тут на сцену выходят монструозные системы поддержки регулярных выражений, обработки исключительных ситуаций, сигнатуры методов/процедур для разных типов значений и прочая прочая генерация костылей.
Как было уже указано выше, для архитектуры x86 само значение, хранимое в ячейке памяти, не обладает никаким типом. Программист на ассемблере получает привилегию и ответственность за определение способа обработки этого самого значение. А уж каким образом определять тип значения и как его обрабатывать – тут на выбор множество вариантов. Но, подчеркнем еще раз, все они касаются только значений, получаемых от пользователя. Как верно заметили разработчики типизированных языков: типы значений внутренних и служебных переменных практически всегда известны заранее.
Эта причина (извращенная передача параметров в модули, написанные на языках высого уровня и необходимость строго следить за типами передаваемых параметров в теже самые модули) видится основной, из-за которой программирование на ассемблере неоправданно затруднено. И большинство предпочитает разбираться в дебрях «языков высокого уровня», чтобы воспользоваться тем, что уже наработано другими, чем мучиться, вставляю одни и те же «типовые» костыли, для исправления того, чего они не делали. И редкий транслятор ассемблера хоть как-то «разгружает» программиста от этой рутины.
Что делать?
Предварительные выводы с учетом 15ти летного перерыва в программировании на ассемблере.Во-первых, по поводу модулей или частей программы. В общем случае стоит выделить два вида исполнительных модулей программы на языке ассемблера – «операция» и «подпрограмма».
- «Операцией» будем называть модуль, выполняющий «атомарное» действие и не требующий для своего выполнения множества параметров (например, операция очистки всего экрана, или операция расчета медианы числового ряда и т.п.).
- «Подпрограммой» же стоит назвать фунциональный модуль, требующий, для корректного функционирования, множество входных параметров (больше 2х-3х).
Полезно также следовать правилу немутабельности – то есть неизменности передаваемых параметров. Подпрограмма не может (не должна) менять значения в передаваемой ей структуре и результат возврашает либо в регистрах (не более 2х-3х параметров), либо также в новой, создаваемой структуре. Таким образом мы избавлены от необходимости делать копии структур, на случай «забытого» изменения данных подпрограммами, и можем использовать уже созданную структуру целиком или основную ее часть для вызова нескольких подпрограмм, оперирующих одним/схожим набором параметров. Более того, практически «автоматом» приходим к очередному «функциональному» правилу – внутренней контексто-независимости подпрограмм и операций. Иными словами - к разделению состояния/данных от метода/подпрограммы их обработки (в отличие от автоматной модели). В случаях параллельного программирования, а также совместного использования одной подпрограммы мы избавляемся как от необходимости плодить множество контекстов исполнения и следить за их «непересечением», так и от создания множества экземляров одной подпрограмм с разными «состояниями», в случае нескольких ее вызовов.
Что касается «типов» данных, то тут можно как оставить «все как есть», а можно тоже не изобретать велосипеда и воспользоваться тем, что давно используют разработчики трансляторов императивных языков – «идентификатор типа значения». То есть все данные, поступающие из внешнего мира анализируются и каждому полученному значению присваивается идентификатор обрабатываемого типа (целое, с плавающей точкой, упакованное BCD, код символа и т.д.) и размер поля/значения. Имея эту информацию, программист, с одной стороны, не загоняет пользователя в излишне узкие рамки «правил» ввода значений, а с другой - имеет возможность в процессе работы выбрать наиболее эффективный способ обработки данных пользователя. Но, повторюсь еще раз, это касается только работы с пользовательскими данными.
Это были общие соображения о программировании на ассемблере, не касающиеся вопросов проектирования, отладки и обработки ошибок. Надеюсь что разработчикам ОС, которые пишут их с 0-ля (а тем более на ассемблере), будет о чем подумать и они выберут (пусть не описанные выше, а любые иные) способы сделать программирование на ассемблере более систематизированным, удобным и приятным, а не будут слепо копировать чужие, зачастую безнадежно «кривые» варианты.
