Глубинные фундаментальные практические и практичные
основы программирования и архитектуры процессоров.
В настоящее время неактуально разрабатывать систему команд - только как набор команд (instruction set).
Система команд процессора должна позволять объединять отдельные команды в единое выражение на аппаратном исполняемом уровне.
Лингвопроцессорное выражение - LUX (Lingual Unit eXpression) - есть единый прямой концептуально-выверенный путь от обычных математических выражений через концептуальную систему-набор команд к отдельным арифметико-логическим устройствам процессора.
До сих пор было так, что разработчики архитектуры процессоров, что называется - творили, что хотели.
Естественно и безусловно - это было оправдано, когда на заре развития процессоров - последние состояли всего из нескольких сотен триггеров, ферритовой памяти и дешифратора кодов операций на диодных матрицах.
Тогда - программный интерфейс состоял из небольшого набора команд (Instruction Set) или Системы Команд и для кода операции хватало и 6-ти бит, что хорошо вписывалось в главенствующую тогда для кодов команд - восьмеричную систему счисления.
Структура команды была также наипростейшей - код операции и несколько (1 либо 2 или 3) адресов памяти.
Программировали прямо в восьмеричных кода - позже появился Автокод или Ассемблер.
Естественно, математики хотели программировать в арифметических выражениях и вслед появились трансляторы формул и язык Фортран.
Архаика построчной записи операторов Асемблера и Фортрана уже тогда явно противоречила принципам структурного программирования, которые требовали свободной записи операторов языка в соответствии с древовидной иерархией структурированных программ.
Это противоречие было устранено в трансляторах формул - вместе с появлением Алгола-60 и других алголоподобных языков, вплоть до современных - Си, Паскаль, Ява - и им подобных ...
А язык Ассемблера так и остался нелюбимым дитяти математиков, которые и считали себя математиками в силу лишь того, что программировали на формулоподобных языках, так называемого - высокого уровня.
Хотя, им всё-таки пришлось в достаточной степени поступиться принципами и линеаризовать свои формулы, и прежде всего отказаться от многоэтажных степеней и в частности - радикалов, а также заменить горизонтальную дробную черту на наклонную, заключив при этом по необходимости числители и знаменатели в круглые скобки.
Надо сказать, что трансляторы с таких языков, несмотря на свои громоздкие внутренние алгоритмы оптимизации, иногда выдавали чудовищно неэффективный исполняемый код.
Поэтому, когда небходимо было реализовывать быстродействующие программы, либо задачи обработки данных и другой информации, а также задачи системного программирования, где и операция умножения встречается редко, не говоря уже о делении - приходилось программировать на языке Ассемблера.
Мне приходилось программировать много - и на формульных языках - и на языке Ассемблера - и меня всегда удивляла эта огромная и противоречивая пропасть - между языками формул-выражений и языком Ассемблера.
На каком-то этапе, ещё 20 лет назад, я понял, что эта пропасть не является непроходимой и, наводя мосты через эту пропасть, я нашёл ещё одну опору для такого моста - лингвопроцессорные выражения!
Дело оказалось в том, что математики слишком рано остановились в процессе линеаризации своих выражений, так и не дойдя до лингвистики языка программирования, несмотря на то, что он - язык программирования - и по логике вещей, вполне резонно, называется - ЯЗЫКОМ!!!
А что может быть лингвистичней самого Языка!?
В результате глубинного анализа оказалось то, что язык программирования состоит из операторов - предложений повелительного наклонения, где знак операции или идентификатор функции являются сказуемым, а операнды операции или аргументы функции яляются объектными дополнениями, и последовательность таких операторов и составляет так мною названное - лингвопроцессорное выражение (Lingual's Units eXpressions - LUX).
Оставалось только разработать транслятор с языка этих выражений и в процессе этой исследовательской и конструкторской работы, практически и тщательно проработать форму каждого такого оператора, максимально приближенной к форме терма традиционного математического выражения и таким образом - мосты были наведены и был создан язык программирования Люкс!
И это уже достигнутый результат, остаётся вопрос - куда двигаться дальше?
Язык LUX очень хорошо лёг на систему команд процессорора Intel 80x86 вплоть до 32-битовой архитектуры IA-32, поскольку эта система команд в основном базируется на двухадресных командах с первым операндом в регистре и в этот же регистр помещается результат двуместной операции.
Язык LUX неплохо лёг и на систему команд процессорора Intel 80x86 новой 32/64-битовой архитектуры IA-32e,
Однако дальнейшие планы разработок фирмы Intel, выраженные в новой архитектуре процессора Itanium, вызывают весьма значительные противоречия.
Разработчики вновь, как и в прошлом веке - поддались ложному искушению величия гигантомании - и пошли по проторённому пути - чем длинее машинное слово, тем больше адресность команды, хотя, хорошо выверенная - байтоориентированная архитектура памяти и минимальная адресность машинной команды-инструкции - остаётся в веках, как научно-техническое достижение и хорошо выверенный вариант данного технического решения.
Это подтверждает и пример наилучшего достижения архитектуры процессоров - в известной своими научно-практическими достижениями в областях ядерной энергетики и освоения космоса - советской науке и технике, а именно - великолепный пример процессора цифровой "драги советской науки" - ЭВМ БЭСМ-6, который был одноадресным - и хорошо вписывался в байтоориентированную архитектуру, хотя длина машинного слова - для того времени и той элементной базы - была оптимальна и достаточно велика - 48 бит (48-bit).
В исторически последовашим за ним великолепном процессоре ЭВМ ЕС - архитектуры IBM-360 была, как и в дальнейшем - в процессоре Intel 80386 - двухадресная система команд с первым операндом двуместной операции в регистре и длиной слова - 32 бита (32-bit).
В процессоре же - Itanium - число адресов или операндов в команде выросло аж до ЧЕТЫРЁХ(?) ...
А из практики программирования хорошо известно, что исполняемый код даже в двух-трёхадресных системах команд содержит значительное количество пустых незаполненных либо дублирующихся адресов.
Очень весомым аргументом является также то, что - чем больше число адресов в команде, тем намного менее универсальной становится эта команда и тем меньше вариантов где бы её, без особых излишеств(!) вставить в исполняемый код!
А одно-двухадресную команду без особых излишеств(!) можно вставить везде - в любом случае!
Я уже показывал это в своей статье "О проекте НОВОГО ПРОЦЕССОРА БУДУЩЕГО", на следующей странице своего сайта:
http://www.pancov.narod.ru/mydream.htm
В силу этих ВЕСЬМА ВЕСОМЫХ обстоятельств - разработчикам систем команд новых процессоров следует заботиться о том - как компактно и понятно будут накладываться выражения исходного языка на систему команд разрабатываемого процессора!!!
Сомнительная погоня за весьма незначительным увеличением быстродействия процессора не оправдывает значительного роста громоздкости команд и их сведения от выверенной десятилетиями наглядной байтовой ориентированности до малонаглядной и малологичной битовой мешанины!
Это показывает и исторический опыт - ведь байтоориентированная система команд процессорора Intel 80x86 уже несколько десятилетий успешно конкурирует с многоадресными RISC-процессорами.
Именно поэтому около десятилетия назад я взялся за разработку байтоориентированной системы команд процессора архитектур LUX-Sextium - LUX-Septium и т.д. ... и довёл эту разработку до стадии РАБОТАЮЩЕГО технического проекта с эмулятором-интерпретатором и декомпилятором этой системы команд, которые я уже несколько лет использую для разработки необходимых программ для новых процессоров LUX-Sextium - LUX-Septium и т.д.
Компилятор и декомпилятор этой системы команд процессора архитектур LUX-Sextium - LUX-Septium и т.д. ... сводит на нет существующую пропасть между исходным языком и исполняемым загрузочным кодом разрабатываемой программы.
Дело в том, что компиляторы с языков высокого уровня располагают машинные команды транслированных операторов исходного языка не совсем в том порядке, в котором находятся термы этих команд в исходном операторе, особенно при наличии глубокой оптимизации.
Попытки отождествлять машинные команды с термами операторов исходного языка превращаются в головоломный ребус, даже при наличии дизассемблера или просмотрщика кода типа CodeViewer.
Этому способствует изначальная неэффективность самой трансляции.
В общем, разработчики и не пытаются делать такое отождествление, если отлаживаемая программа, что называется ещё "дышит", то есть завершается с выдачей некоторых, хотя бы - промежуточных результатов, и в таких случаях можно осуществлять выдачи промежуточных результатов и трассировать всю программу или отдельные её части.
Хуже обстоит дело, когда программа "зависает" или завершается аварийно с выдачей скудной - недостаточной информации о месте сбоя.
В таких случая для анализа причин сбоя приходится прибегать к просмотру загрузочного кода.
Компилятор языка Люкс выдаёт относительные адреса в машинных кодах исходных операторов языка Люкс.
А декомпилятор выдаёт подстрочную запись оператора на исходном языке Люкс для каждого оператора машинной команды.
Таким образом, имея относительный адрес места сбоя и исходный код для этого места сбоя, гораздо легче понять и причину сбоя в работе программы.
Это значительно ускоряет отладку программ, а также, по необходимости - позволяет в любое время оценить эффективность отдельных, возможно - наиболее критичных фрагментов программ.
Язык Люкс настолько удобен для оптимизации программ, что я, к примеру, мог осуществлять оптимизацию повторяющихся фрагментов программы в одной и той же программе - либо включением в эту программу подпрограмм, реализующих эти повторяющиеся фрагменты, либо макросов, реализующих эти же повторяющиеся фрагменты, путём замены вызовов подпрограмм на макросы, или обратно, путём замены этих фрагментов через контекстный редактор.
К примеру, замена вызовов подпрограмм на макровключения в программу - позволило мне увеличить быстродействие LUX-Septium интерпретатора в полтора раза!
А при необходимости, для увеличения наглядности программы при её доработке и отладке, можно, наоборот, заменять макровключения на вызовы подпрограмм, после чего, вдоволь наглядевшись на эту наглядную программу, после её отладки - можно восстановить макровключения и получить быстродействующую рабочую программу.
В настоящее время неактуально разрабатывать систему команд - только как набор команд (instruction set).
Система команд процессора должна позволять объединять отдельные команды в единое выражение на аппаратном исполняемом уровне.
Лингвопроцессорное выражение - LUX (Lingual Unit eXpression) - есть единый прямой концептуально-выверенный путь от обычных математических выражений через концептуальную систему-набор команд к отдельным арифметико-логическим устройствам процессора.
***