Index  Comments

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.