The Meta-Machine Code Targeted at CHIP-8: The Evolution of the Metadata Format

As this writing is a collection of my ideas that have not been written down in full before now, this
page will be gradually updated and refined whenever I feel the want or make significant changes.  In
particular, I intend to perhaps update this article with illustrations, later.


The basic format has largely remained unchanged, I believe, regarding the header and name organizing
and so what will mostly be documented are those changes regarding that metadata which corresponds to
each program octet.  The basic format is a six octet header, in which the first hextet is used for a
versioning system and the remainining two are used to give program bounds to the remaining metadata;
following that other data are the names, which consume 3+N space, where N is the length of the name,
and the three octets are the header, consisting of a hextet for the value and an octet for which the
first three bits are zero, the fourth bit zero for a normal name and one for a label, and the nibble
remaining indicating the length of the name, where zero is disallowed.  There was originally thought
given to how and where names should be stored, but any separation was considered baroque and so this
appending to the end was chosen as a nice method; a constant storage size of eighteen for names, the
maximum, or a table indicating the position of each name could be used to permit constant and random
access, but this was considered unnecessary, wasteful, and the latter more prone to failure.  Hextet
values are used in the header for three reasons: the versioning was thought to benefit from it; even
octet header length was desirable; and there are extensions to CHIP-8, which I don't care for, which
extend that program space to sixteen bits.  The alternative was a four octet header with a lone byte
for versioning and the two twelve-bit addresses placed into the remaining three.

Starting with the original envisioning of metadata also shows how the tool had much more general and
wasteful beginnings; the format consumed five octets and one bit for every octet of program, as each
nibble could have a name; stored was a twelve-bit Meta-CHIP-8 routine address, with a four-bit usage
code, and this code was split for the two twelve-bit name codes; the remaining bit indicated a range
starting or being subsumed and was stored elsewhere.  I don't believe this first format ever was put
to implementation.

I realized the DXYZ instruction was the only one which benefited from nibble-granularity.  My second
format, which was actually implemented, only provides byte granularity for names.  The generality is
still present, however, as the format consumed three and one half octets for every octet of program;
the range was the first bit, the name usage was the following three, and that remaining space stored
the routine address and the name code.

What I believe will be the final format uses a single hextet for each program octet and fully leaves
the Meta-CHIP-8 and so generality of the previous formats.  I observed the routine field wasn't used
beyond three values for instruction, octet value, and hextet value designations.  It's unpleasant to
manipulate the second format in many languages, also.  This format stores a two-bit designation code
with instruction, octet, hextet, or subordinate values; three bits store that name usage information
with none, lower nibble, upper nibble, octet, address, and hextet values, states four and six aren't
valid; and the remaining eleven bits are used to store the name code.  This halving of the name code
is the only negative aspect of this format.  This is pleasant, as it corresponds precisely to a high
level representation of the data, with the subordinate field, and is symbolic in nature; the removal
of the range field for being unnecessary in view of the designation code was also nice.  Those prior
formats were terminated by the end of the medium and so out-of-band, as I like formats that can only
suffer insufficient-length errors; however, this format encodes information that must be checked and
so this quality isn't truly present; in the interest of extension, the zero name length will be used
to terminate the names and so the metadata.

I expect future metadata formats for other targetings to resemble this latest such format.
.