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.
.