Если смотреть на системы команд разных процессоров, игнорируя особенности их архитектур, можно заметить нечто общее в организации их систем команд, в исключительном большинстве случаев делающее их программно несовместимыми. Везде наблюдается преобладающий фактор хаоса, порождённый фривольностью инженеров-разработчиков тех процессоров. Так как ещё со времён паровых механических машин Бебиджа не было разработано никакого некоего кодекса, в котором строго и чётко расписывались бы все правила проектирования архитектуры вычислительного устройства на всех уровнях, каждая ветка индустрии процессоров шла своим путём и порождала свои правила.

Позвольте мне упустить из внимания особенности архитектур, которые и без меня развивались и будут дальше усложняться. Хочу сосредоточиться лишь на том, что какими бы ни были процессор и его система команд, разработчику всегда нужно придумать систематизированное обозначение всей этой псевдо-хаотической абстрактной лабуды. Разработать мнемоническое обозначение команд, язык ассемблера и сборщик конкретного объектного кода. Так как пользователю, будь то домохозяйка или же программист сторонней компании, так ли иначе нужно будет как-то с этим работать. Программисту необходимо будет переварить всю эту мнемоническую кашу, а домохозяйке нужно будет мириться с ограниченной функциональностью и возможными багами используемой техники.

Здесь я попытаюсь изложить свои труды, практической целью которых стало стремление заполнить нишу, то пустое пространство, которое образовалось под высоким давлением ведущих индустриальных гигантов. Исторически сложилось так, что вся инженерия всегда и в первую очередь работает на военные интересы, где нету, выражаясь формально, ограничений на сложность разрабатываемых систем и финансовых затрат. В супер компьютерах давно уже не скупятся на длину машинного кода, чтобы получить относительно прозрачную и элементарную систему команд для переваривания конвейерами, а также для явного указания параллелизма. Главное там - надёжность и производительность. Всё, чем мы пользуемся в быту, от настольных компьютеров до карманных сотовых телефонов - лишь сильно сжатые праобразы супер ЭВМ с предельно компактными записями команд.

Здесь я попытаюсь описать на собственном опыте все сложности в разработке процессора, который не должен прогибать программиста под себя в каком-то смысле. Я попытаюсь избавить его от абстрактной системы команд. Процессор может получиться неприлично медленным и ограниченным. Но свои усилия я направлю на то, чтобы он работал с программой не как с каким-то очередным байт-кодом, а реальным листингом с вполне конкретными математическими записями и выражениями. Для того, чтобы избавить от всяких посредников, начиная от ассемблера и восходя до языков высокого уровня.

Идея разработать собственный процессор с особенной системой команд, пересекающейся с ascii-таблицей, у меня возникла относительно недавно. Эдак, в 2008 году.
Однако, черновые наброски как в наборе заметок и правил, так и на уровне алгоритма, имели много нестыковок.
Но совсем недавно я наткнулся на статью, послуживщую сильным стимулом. Как там сказано, в оснащение входит встроенный интерпретатор Бейсика. Для меня это значит, что любая программа будет выполняться с тормозами.
Значит, как я для себя заключил, для любительских проектов, которые в перспективе не должны попасть на орбиту планеты, можно использовать любой процессор. Даже самый медленный, как мой аппаратный парсер.

Мне посоветовали установить компактный пакет Icarus Verilog. Благодаря чему я наконец-то смог перейти от теории к практике.

Хотя написанный в JavaScript эмулятор процессора функционирует с большими натяжками (об этом - ниже), но оказалось, что легче начать разрабатывать Verilog-листинг с нуля, чем портировать его со скрипта. Единственное, что пригодилось, это прошивка таблицы и мой приобретённый опыт.

Как я уже сказал, симулятор функционирует с натяжками. Прежде всего их создаёт непродуманность концепции в целом. Не сформирована до конца модель синтаксиса.
Хотя синтаксис приближён к языку Си (кстати, про Verilog говорится то же самое, хотя с Си схожесть довольно натянута), но имеются очень необычные формы записей. Что создаёт трудности в развитии синтаксиса.

Как правило, когда человек начинает заниматься чем-то новым, оказывается, что это нечто новое уже начинает жить собственной жизнью. Диктует свои правила, образует исключения.
В этом плане я понимаю разработчиков. Хотя синтаксис и объявляется Си-подобным, но к самому Си имеет есть косвенное отношение. Как язык php или даже C++, который стал самостоятельным языком с конфликтами с Си.

На форуме я открыл тему с этой идеей.
Правда, материал темы немного подстарился, так как идея сейчас достаточно скоро развивается и вносятся соответствующие коррективы.

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