[eichin:19900510.0617EST] Design notes on the Generic Assembler Emulator

I need a way of writing a machine description and generating emulator code from
it. One reason for this is that I can't spend too much time on the project and
so need as much of a lever as possible.

There are two types of emulators (or are they points on a spectrum?): debugging
and speed. The debugging version should be well instrumented for some sort of
debugging tools; the speed version should be fine-tuned (though perhaps still
profilable?) and have the obvious overhead minimized, but still be legible
enough to be further optimized by hand.

Mappings: binary opcode to function; function to RTL expression

RTL: needs to specify registers (possibly modified by bits), functions, flag
settings, timings(?)...
	ld r1,r2: (store r2 r1)
	add r2:  (progn (store (add r2 acc) acc) (setflags c z))
	or perhaps: (setflags (store (add r2 acc) acc) c z) ??
 Using a lisp-like notation means having expressions that can be easily
operated upon as data; in spite of this they can still be efficient.

opcode: Perhaps specify the reverse mapping and write code to frob the tables?
Then something like
	ld r1,r2: (+ 0100 (hi_slot r1) (lo_slot r2))
	or perhaps: (def ('ld r1 r2) (+ 0100 (hi_slot r1) (lo_slot r2)))
	add r2: (+ xxx (hi_slot r2))
 Use some prolog-like techniques to iterate over the values, except cheat and
remember that the names are special (r1 means A-F, H,L; rp1 means BC, etc.)
However, these must be predefined sets, so add
	(defset r1 (A 7) (B 0) (C 1) ...)
 to indicate r1 as a set, (a 7) as the symbolic tag A but numeric expression
value 7.

chip simulation vs. system simulation -- memory? 8-bit machines can just use a
fixed array, but 16 and 32 bit (and virtual memory) machines should be more
rational about it (though perhaps "buying" memory in 64Kb pages would do?)