MIM design: elaborate on RVECTOR access
authorKaz Wesley <kaz@lambdaverse.org>
Sun, 18 Mar 2018 06:07:24 +0000 (23:07 -0700)
committerKaz Wesley <kaz@lambdaverse.org>
Thu, 22 Mar 2018 22:29:33 +0000 (15:29 -0700)
Signed-off-by: Kaz Wesley <kaz@lambdaverse.org>
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.