MIM design: elaborate on RVECTOR access
[muddle.git] / doc / mim.md
index b2af24dccdfb6d58da489b9a9c30d1ae21834989..20de59ef66e4af3bd443fa4e90566502552e3ea3 100644 (file)
@@ -130,14 +130,18 @@ which enables simplifications like a fallthrough implementation for
 ops that have one variant that takes an immediate in the B position
 and another variant (with a different opcode) that takes a local.
 
-Operand types can be:
-- immediate Byte (incl. signed offset for must jump operations)
-- immediate Word (offset for the "long jumps"--JUMP/EMP?/FALSE?)
-- index into the current function's Constants table
-- index into the current function's Locals table
-- index into the Locals table containing an LVAR to be dereferenced
-Generally each opcode has a fixed interpretation of each operand; any
-necessary variants are encoded as separate opcodes rather than
+The address modes are:
+- B: immediate Byte (incl. signed offset for most jump operations)
+- H: immediate Halfword (16-bit operand, incl long jumps JUMP/EMP?/FALSE?)
+- W: IP-relative Word (32 bit constant inlined in code)
+- L: index into the current function's Locals table
+- LL: index into the Locals table, result indirected through a locative
+The RVECTOR is placed at local0, so that static values can be accessed
+via NTHR and locals with static names via NTHRL.
+
+An opcode interprets each of its arguments according to a fixed
+address mode; any necessary variants are encoded as separate opcodes
+(distinguished in assembly by the suffixes listed above) rather than
 branching on flag bits. The only common non-guard branches are the
 opcode dispatch, (occasionally prefixed-opcode dispatch), and dispatch
 for polymorphic/mistyped ops.