The Meta-Machine Code Interface Concept
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 recall or conceive more and more of my ideas
concerning the topic and feel the want. In particular, I intend to update this article with
illustrations, later.
The Meta-Machine Code interface concept began as a vague notion of machine-assisted creation of
machine instructions through reasonably structured use of questioning and whatnot. Among the first
examples was, having chosen the instruction through a single action, having the system guide operand
questioning in a way that prevented invalid such operands from being entered. To provide a concrete
example, the peculiarities of ARM literals could be accomodated for in the integer collecting
routine in a way that doesn't permit an invalid such integer to be entered. Given the inherently
interactive nature of the tool, it was important to prevent errors of this type; the notion of an
invalid literal loses its meaning at this level, as something will always be present.
Due to distaste with Emacs' notion of a mode-line and minibuffer, the interface eventually became
entirely uniform, with an unimportant number of rows spanning ranges filling the display area. The
interface uses these rows to display contiguous regions of memory, with each row containing identity
information, such as address and range contents in various bases, and the remainder being available
to the meta-machine code routines for custom purposes, such as displaying the contents of the memory
as an instruction for ease of understanding. Making this former half of each row customizable
proved too complicated for my tastes and so the idea was discarded. An interesting consequence of
this design is how the tool functions properly with even only one row of display, given it's wide
enough
The question arose as to where input should be collected, with either a transient area, such as a
``popup window'', appearing for such or the commandeering of a row for such use. The commandeering
of a row is simpler in some display primitive sets and is currently what is being pursued. This
choice also preserves the quality of needing just one row for proper operation.
Associated meta-machine code routines are run in order; it was thought that disallowing range
changes would allow for parallel processing, but this restriction would prevent, say, instruction
bytes from being interpreted in several ways related to an offset within the instruction and this
was considered an important and interesting feature; it has later been decided that enabling such
range changes interferes too deeply with screen consistency and that a separate mechanism can be
provided for this interesting, albeit perhaps rare case. Originally these display routines could
potentially alter previous displayed rows, and this wasn't considered an issue, as the programmer
was expected to know how such a feature would be used or abused, but maintaining display consistency
has been a prime bother and disallowing display routines from asking questions, modifying the
program, and other such actions, making them idempotent, has been a key to alleviating this bother.
By funneling all program changes through a single mechanism, originally for making any undo
functionality possible to implement, it can also easily be calculated whether redisplay should
occur. It was not considered acceptable to make a copy of any information to determine if redisplay
should occur. By funneling all changes through this mechanism, it can be checked each time and a
single flag set to determine this. The current row is always redisplayed and changes outside of the
view need no redisplay; this reduces the check to four integer comparisons: testing the bounds of
the first region, between the beginning of the display and the current row, and also testing the
bounds of the second region, between the current row and the end of the display. By requiring all
changes to occur through this mechanism, including name changes, it can easily be tested whether a
full redisplay is necessary or not. More complex algorithms could be employed to avoid requiring
full redisplay, but this will not be done.
As for manual screen redisplay, a rather necessary traversal command was found to also be suitable
for this, without explicitly creating such a command, as that was explicitly not going to be done,
and so avoided tainting the MMC with such concerns. Along with traversal among the rows and the
scrolling of rows through memory, this command for selecting an address was envisioned to be useful
and an unoptimizing, and so realistic, version would always redisplay to accomodate all cases; this
necessarily makes it work for redisplay. Having the default address result in redisplay of the
screen beginning from the current row nicely solves this bother.
.