Затрону ещё один вопрос - о безусловных переходах. Считаю нужным расширить их употребление в техноязыке. Почему, когда по правилам структурного программирования надо вроде бы ограничить? Дело в том, что Паронджанов считает единственным достоинством ДРАКОНа силуэт; но он и построен именно на основе одного из типов БП (который я назвал разрешённым, Р-БП) - по явно указанной метке (имени ветки).
По моему мнению, ещё одно достоинство техноязыка (и шампур-метода) - как раз введение БП в явном виде, что делает язык структурно законченным, целостным формализмом. Причём если построение силуэта возможно именно за счёт БП, то обратное неверно - БП может использоваться не только для построения силуэта. Именно это "не только" я стремлюсь показать, вводя для этого и новые типы БП. Тем самым техноязык становится возможно употребить более глубоко в процессе формализации импер-знаний (до машинного представления алгоритма), и притом так же широко - не только как производственный, но и как учебный и научный язык. В частности, открывается возможность при обучении программированию избежать пресловутого "семантического разрыва" между исходным текстом и программным кодом, наглядно объяснив переход между ними. Аналогичный разрыв между алгоритмом и исходным текстом вполне успешно заполняется на базе гибридного программирования.
Итак, главная конструктивная идея техноязыка - то, что его создатель из возможных вариантов структуризации схем алгоритмов и программ выбрал тот, который не исключает БП, но формализует их употребление для двумерного представления схем. В то же время считается, что существуют некие операторы-заменители БП как в текстовых языках, так и в визуальных (в т.ч. в ДРАКОНе); на мой взгляд, это можно трактовать как разные случаи всё того же безусловного перехода, что и показано при описании структурных конструкций (следования, ветвления, цикла). Визуализация предполагается в Драконографике, а здесь пока общая идея текстом.
В конечном счёте машинный код алгоритма не содержит типов БП, употребляемых на более высоких уровнях; скажем, разрешённый БП между шампурами смежных веток силуэта при кодировании заменяется на естественный переход. Зато сохраняются (и/или вводятся заново) другие типы БП, которые назовём машинно-ориентированными.
Так, каждый условный оператор машинного языка (команда ветвления) в качестве альтернатив завершения исполнения имеет:
естественный переход к следующей в ОП команде, начинающей одну ветвь (реализуется наращиванием счётчика команд СК);
переход к команде, начинающей другую ветвь, в силу одномерности ОП расположенную не прямо за командой ветвления (реализуется загрузкой в СК адреса этой команды из записи команды ветвления); он как раз понимается как безусловный, т.к. по сути имеем метку (адрес) начала кода ветви.
А в конец каждой ветви (на место древесной точки слияния с более правой ветвью) вставляется парный БП на оператор (команду), следующий по шампуру за разветвлённой конструкцией в целом.
Аналогично раскладывается цикл, только БП по петле цикла (с выхода развилки или шампур-блока ПОКА) идёт против шампура (на точку слияния при входе в цикл); принцип легко понять, если "примитивизировать" силуэт с веточным циклом.
В системе команд информашины переходам с концов вертикалей соответствует обычная команда БП.
Можно показать такого рода переходы (называю их линейными) на дракон-схеме. При этом мы раскрываем нелинейную дракон-схему до линейной нагрузки всех вертикалей и представляем себе каждый линейный участок шампура, каждую вертикаль ветвления (тела цикла) как ветку-фрагмент; в визуал эти фрагменты объединяются как раз линейными БП. Эти переходы вводятся как в силуэт, так и в примитив; более того, они важны именно в примитиве, о чём сказано ниже.
Отмечу, что для обычного (высокоуровневого) представления алгоритмов также рассматривались возможности разложения условного оператора на более мелкие элементы; это обсуждалось и где-то здесь на конференции.
Далее, икона Вставка совместно с заголовком и концом визуала-вставки заменяется на иконы БП с возвратом (также имеют свою графику и текст); принцип также понятен, если представить себе вставку как особый тип ветки, допустимый как в примитиве, так и в силуэте. В системе команд информашины этой паре переходов соответствует пара команд ВЫЗОВ и ВОЗВРАТ (понятно, что названия условные).
Схема с машинно-ориентированными БП изображается без соединений одноимённых икон какими-либо линиями; по сути это есть лиоформа визуального алгоритма.
Устранение разрешённых БП при машинном кодировании фактически "примитивизирует" силуэт; это несущественно, т.к. структура любой нелинейной дракон-программы одновременно по линейным БП раскладывается на фрагменты-вертикали, которые образуют некую перестановку (линейный порядок) на "ленте памяти" (в адресном пространстве информашины). Адресуемая, или основная память ОП реализуется как постоянное и/или оперативное ЗУ; последнее обычно сегментируется на блоки.
Если код какой-то из вертикалей не умещается в размер блока ОЗУ, принятый в архитектуре данной платформы, то в него м.б. введены межблочные БП; тогда единицами линейного порядка выступают как "короткие" фрагменты, так и блоки "длинных" фрагментов.
Как известно, адрес каждого машинно-ориентированного БП либо предопределён при компиляции, либо вычисляется в процессе загрузки кода в ОП. Считая в лиоформе метку (значение адреса в команде БП) переменной, можно при визуализации системных программ среди прочего показать и способ этих вычислений (как часть алгоритма загрузки кода в ОЗУ).
Всё сказанное и составляет суть ассемблерной модификации шампур-метода. Полученную структуру (лиоформу визуала) можно изобразить на диосцене (для человека) без пересечений, однако она будет менее наглядна, т.к. вообще-то предназначена для перевода в предметную форму (для информашины). Тем не менее, если захочется программировать в кодах, то именно так целесообразно визуализировать дракон-программу.