Не стану увещевать, "Что первично"...
1. курица али яйцо
2. бытие али сознание
...
N. г.р.а.ф.и.к.а али символика
Остановлюсь лишь на:
а. причина → следствие...
Иными словами "если, то, (иначе)". За неимением лучшего рисую драконовскую лиану; в ней - всего три элемента:
1. переключатель, создающий ветвление
2. лампочка (светодиод)
3. то, что "иначе" (например моторчик)
Задаю вопрос господину Паронджанову: "Неужели так трудно сию мелочь из рисунка перевести сразу в двоичный код, минуя языки программирования?"
(хотя читал, что господин Паронджанов не совсем программист, он лишь продвигает и поддерживает идею философии Дракона)))
Вспомнилось: "Дайте мне точку опоры и я переверну..."...
- Так и я переверну. Дай мне на экран такой "живой" графический переключатель, который будет непосредственно менять назначенный ему разряд
(для этой задачи нужен пока всего лишь 1 разряд для лампочки и 1 разряд для моторчика из шестидесяти четырёх) в самой машине. (в одной из ячеек её памяти)
Далее я нарисую нечто, называемое "до тех пор, пока" (цикл с пред/пост-условием), его легко рисовать, уже имея действующий переключатель) и помещу его в "именной ящик" (опять же нарисованный)
Далее я нарисую нечто, называемое "case" и тоже помещу его в "именной ящик"- ведь это тот же переключатель, но с увеличивающимся числом положений.
Далее я создам кучу поименованных (или разнообразных по форме и цвету) ящиков с разнообразием простейших "релейных" схем... (а к ним - всплывающий ящик "комментарии/описания")
Далее я создам непререкаемое правило: "Символику в виде набора букв, слов и предложений применять лишь там, где это действительно необходимо, где без неё не обойтись"...
Далее я создам масштабирование этих схем-ящиков, дабы поместить их в именованный макро-ящик (бандероль, вагон, тележку, также разнообразив их по цвету и форме)
Далее... а далее начнётся сам процесс творчества, интересный даже ребёнку. (вспомним "кубики")))
- Да, чуть не забыл о главном: пока я играю с переключателями - мне нужен маленький экранчик, (окошечко), вживую отображающий ту область памяти, на которую я влияю... (желательно тоже в графике)))

Уровень для моделирования азов - самый низкий, (возможно ассемблерный), в некоторых случаях придётся скатиться даже до машинного, пока не научим её элементам графики, реализуемой даже без ОСи.
На всех стадиях моделирования не будем забывать о визуальном контроле над сделанным. Экранчики-окна с реакцией машины на действия человека - самое главное условие продвижения продукта.
Это своеобразная обратная связь, отвечающая на вопрос: - "боже-ж мой, а что это я делаю и где это происходит"...

Существующие HEX-редакторы - это не совсем то. "зеркало" оперативки в виде HEX-колонок цифр тоже мало что даёт. Вот если оперативку отобразить в виде градусника с делениями - это вариант, а поскольку она достаточно длинная - применять "скроллинг" и масштабирование рассматриваемого участка и лишь при наведении мыши на нужную область - отображать в дополнительном всплывающем окне данные.
На этой оси выделить разными цветами уже загруженные туда ОСиной дрова, тело самой осины, библиотеки и прочее и прочее...

Происходящие временнЫе изменения выделять спец-метками либо спец-цветом, затухающим по времени.
Двоичный код (0,1) отображать по желанию пользователя - либо в графике, либо точками в разрядах. (кому надо - также выберут либо HEX либо соответствующий ему символ)
Ячея и сота - достаточно короткие словки, ими легко оперировать, причём сотой можно назвать разряд для одного бита либо совокупность разрядов одного слова, а ячеёй - регистр целиком. (или наоборот)))
Здесь можно ещё покумекать, вдруг придут на ум более подходящие словки... С содержимым регистров процессора (процессоров) поступить также, как с оперативной памятью.
Стопроцентная обратная связь, динамически отражающая действительность - самая главная "фишка" проекта. От такого никто не откажется...

Триггер - это "ключ", (от слов "включатель/выключатель"), имеющий 2 устойчивых состояния. Ключ короче, чем защёлка.
Коробки, ящики и окна - виртуальны, это как <div>...</div> в HTML, назвать их "устройством" язык не поворачивается, поскольку есть привычка считать устройством нечто реальное, воплощённое в "железе".
Можно оставить как "окно", а в случае программ, подпрограмм в виде процедур, функций - просто "тело" иногда "поле", внутри которого они и будут писаться/рисоваться.
Каждое "тело/поле" будет иметь свою форму, цвет, "шапку" для названия, всплывающее "поле" для комментариев/описаний...

Благодаря этому отпадёт необходимость сочинять теги открытия/закрытия да и многие спецсимволы отпадут за отсутствием нужды в них.
Поскольку математическая, логическая и низкоэлементная часть проекта будут словарнонезависимыми - вписывание любого языка в проект упростится, что позволит выйти проекту и на международный уровень...
Насчёт полусумматора в области программирования у меня пробел в знаниях. Схематически знаю, что оно такое и для чего, а вот способы применения в программах - пока не доводилось... (раньше АЛУ зачастую реализовывалось отдельно от проца и требовало несколько иной "семантики" - вот и всё, что я помню... )))

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