The Meta-Machine Code (MMC) Tool

This is my prime document for a novel and interactive machine code tool I've designed and decided to
name ``Meta-Machine Code''.  The idea came, waiting bored, in a parked car; I mulled over the design
for a machine code which would be infeasible to use with an assembler, composed entirely of switches
and so unlike any I'm familiar with, and saw in my mind an elegent interface for manipulating such a
code.  This gradually became a dislike of assemblers, which unnecessarily obscure machine codes, and
an envisioning of the interactive and machine-guided tool for advanced programming described herein.

It's easy to describe the MMC by contrast with an assembler.  An assembler is a batch tool operating
on an assembler language; arbitrary mnemonics and syntax are assigned to instructions and like data;
``pseudo-operations'' are used for directing an assembler in-situ; and failures beget error notices.

The MMC is interactive; it provides human-readable descriptions of data, eschewing syntax; a command
for changing the current address, among other such things, is given directly and out-of-band with an
instruction command; instructions and like data are given through interactive prompt, bound to keys,
that question by need; and failures beget reprimand, if not prevented entirely by the interactivity.

An example follows, using CHIP-8, showing how octets D123 34FF 8560 are presented from address 1024.

This is what a typical assembler would accept:

:org 1024
sprite v1 v2 3
if v4 = 255 then v5 := v6 end

While uninteractive, this shows how the MMC would display such, without color:

400-401 1024-1025 ▀▀▄▀  ▄█ D123 53539                 Draw 08×03 at V1,V2; VF ← XOR
402-403 1026-1027 ▄▄██▄█▄▄ 34FF 13567                 Skip next if V4 = 255
404-405 1028-1029 ▀▄▄  ▀ ▀ 8560 34144                 V5 ← V6

The obvious difference is the information the MMC provides over an assembler.  The MMC presumes less
knowledge of the machine code and requires less to use.  The information provided is partly intended
to allow for an advanced programmer to notice and take proper advantage of the homoiconic qualities.

The video demonstration displays the interactive nature; the assembler example is fully interactive.
The nature of the display mechanism is further explained in my 2018-01-01 article, but isn't needed.

Follows is an explanation of the video demonstration:

 Once entered, the tool is instructed to jump to address 1024.
 The command for instruction DXYZ is pressed, prompting for two registers and a height.
 Once answers are given, and invalid numbers may not be entered at all, a nice description is shown.
 A command for traversal to the following instruction is issued.
 The command for instruction 4XYY is pressed, prompting for one register and an octet value.
 The available bases for integer questioning are cycled through for the octet value.
 The 4XYY command was given to show how easily it can be corrected to 3XYY with the default answers.
 Correcting the instruction merely required issuing the correct command and answering the questions.
 Again, a command for traversal to the following instruction is issued.
 Lastly the final instruction is formed, asking for two registers, using a distinct set of defaults.
 Using the instruction commands required no foreknowledge of the instruction form or meaning.

The MMC is the first tool I've created with which I seek to remove textual matters from programming.
Programming has naught to do with text; I scorn that I use the same tools for writing I do for such.
However, a major concern is naming; I realized machine code was particularly suited to this, through
the relatively small and sparse use of names, such that it would serve as a decent vehicle for this.

I'm not fond of forced conventions, such as local labels or common string syntax.  Names are values,
and may have no arithmetic nor dependency on other names.  Names are updated when the values change.

It's poor form that assemblers mask the homoiconicity most machine codes possess; using data as code
is usually infeasible, but the inverse is quite valuable.  The MMC hides none of this opportunity to
save space and whatnot, also showing numbers in several bases to further help such.  These qualities
are intended for hardcore machine code hacking, but the tool has pedagogical value; one can be given
the tool, learn mostly by random key presses, and be told what instructions do, unlike an assembler.

The tool produces a memory-dump, along with metadata in a special format, rather than any particular
executable format; the CHIP-8 metadata format and the evolution thereof is detailed in my 2019-09-29
article.  The name system was added so that an assembler wouldn't be a more powerful tool; the names
permit use of them in place of integers when answering questions, and to create associations.  Then,
upon value changes, the relevant parts may be easily updated in-situ; labels are mere visible names.

In general a name should be able to hold an instruction or address, favoring the latter.  Sans that,
the name has an identifier and indicates whether it's a label to be shown at its value address.  The
association system is tailored to a particular machine code, and designed to be mechanically simple.

There are one-pass and two-pass assemblers; by contrast, the MMC is a no-pass tool.  Names need only
exist when used to answer a question.  Associations may be used and later discarded, without issues.

I mulled over the basic issue of the tool asking yes or no questions a great deal.  My solution uses
the integer asking routine defaulting to name entry, and having a name ``no'' as zero and ``yes'' as
one; this permits customizing names, and a default answer of zero and so ``no'' works well for such.

Building a Meta-Machine Code involves devising a high-level understanding of the targeted machine it
will use for its manipulation.  Thoughts of building a Meta-Meta-Machine Code which transforms these
representations to a targeting stay with me, but I'd prefer to have a few rather varied instances to
compare before I quite seriously pursue such.  I'd prefer to think it's not particularly worthwhile.

In reconciling my ideas of high-level machines and this design, I wonder what purpose it would serve
in such settings.  Given that the first finished targeting is towards a virtual machine from several
decades back and just fine for its toy purpose, it's clear that this manner of programming will stay
with man, as it's a form of puzzle, and there's always room for puzzles, no matter the advancements.

If my MMC is only used for light low-level programming, such as on the level of a microcode, I could
be pleased with that outcome; it would be a tool designed to suit its purpose as well as it could be
made to, regardless of how significant that purpose is, and there's pride in building something that
properly addresses a problem, regardless of commonality.  So few are interested in properly building
at the lower-levels; it's allowed me to innovate; and it's respectable to build such a tool as this.

This article serves as a light introduction to some of the ideas of my tool, for later elaborations.
.