proj-oot-ootAssemblyNotes12

if SootB? is also SHORT, i guess we really should find a way to at least call custom instructions from there.

also, if we've 'broken the seal' of non-fixed-size instructions in SHORT, OR if we use 16-bit fixed size instructions, should consider if we can do better and get some other 'addressing modes' in there besides pure stack.

if we throw some register addressing in there, that doesn't really increase the complexity of implementation very much imo, it's still a good bootstrap language.

---

we basically want 3 addr modes:

• immediate
• register
• stack

we need at least ~4 bits for opcode, plus some way to call longer 'custom' instructions.

3-operand format is nice but 2-operand mode is probably more efficient.

do we need to call first-class instructions? nah, save that for MEDIUM. So we never need the 4-th (3rd) operand.

With fixed length, we'd need at least 16 bits; because you really want at least 8 bits for absolute jumps, and you want the bitlength to be a power of 2. Another reason for this is 4 opcode bits + 2 operands * (2 addr mode bits) = 8 bits, without even putting in the operands yet.

So let's say we have 16 bits.

For absolute jumps, that gives us an instruction format with 4-bit opcodes and 12 bits of data.

For 2 operands with 2 bit addr modes, that's (16 - 4-bit opcode - 2*2 addr mode bits)/2 = 4 bits per operand left.

Now if we need more opcode bits, so that we can have more instructions, that reduces the above number. For 3 bits per operand, we can have 6-bit opcodes, and for 2 bits per operand, 8-bit opcodes.

but recall that since this is SHORT mode, we need 2 form bits now.

---

Since we only really need 3 addr modes, and since stack addr mode doesn't need an operand, we could compress things further:

• 1 bit: register or (immediate+stack)
• 3 bits: (immediate+stack), if 0, stack, o/w, # - 1 is immediate
• or, we could just pretend that the stack register is magic, and have 7 real registers, and reads/writes to the stack register do stack addressing; or, we could have a PC register too, like with MEDIUM; actually, i like that better

---

So we're looking at:

• 2 form bits
• 14 bits left, in 2 formats:
• 2 opcode bits, 12 bit immediate operand (JMP, etc)
• 6 opcode bits, 2x (4 bit operand)

---

wait, we COULD do first-class functions in here pretty easily, since we have 6 opcode bits, if we just use the first 2 bits to indicate when that happens;

• 2 form bits
• 14 bits left, in 3 formats:
• 2 opcode bits, 12 bit immediate operand (JMP, etc)
• 6 opcode bits, 2x (4 bit operand)
• 3 bits + 3-bit first class function operand + 2x (4 bit operand)

---

if we added a 4th format we could also pack 3 4-bit stack opcodes in there.. jeez this is getting to be a lot of formats. Also, that would no longer be fixed-length. So mb not? Also, will chains of 3 stack-addressed instructions be all that common when we allow register addressing too?

---

could we possibly reduce this whole thing to about 8 bits?

• 2 form bits
• 6 bits left, in 3 formats:
• 1 opcode bit, 5 bit immediate operand (LOADI)
• 2 opcode bits, 2x (2 bit operand): immediate 0, immediate 1, stack, register 0 (or just register-style access to TOS?)
• 1 opcode bit, 1 bit for which register the first class instruction is in, 2x (2 bit operand)

---

so that reminds me, we'd really like at least 4 addr modes:

• immediate
• register
• stack
• register-like access to the first few stack locations

---

previous proposal is nice but 5-bit immediates isn't much; that only gives us a JMP table with 32 entries. We could accept variable-length addressing w/r/t the FORM bits. This wouldn't be too much more crazy than the old, simpler, 4-bit proposal:

• we already had 'variable length' in the old proposal because sometimes we had those 12-bit immediates
• we already only had 4 bits of opcodes, now we're just adding a standardized format to do some things that would require multiple 4-bit instructions, some of which with 12-bit immediates, before

---

so how about:

2 formats:

• 64-bit MEDIUM IMMEDIATE: 2 form bits + 12-bit opcode + 3x (4 bit addr mode + 12 bit operand) combined into >=32-bit immediate
• 2 form bits + 1x 6 bit (see below) + 3x 8-bit SHORT:

well now we're getting into the same sort of packed SHORT format we had before, where the first (and maybe the last) instruction has a special encoding, to accomodate those 2 form bits. But now we're trying to do a 2-operand format instead of 1. The old ootAssemblyNotes7 SHORT format used a system similar to the limitations on expressions in terms of pushes/pops and parenthesis described slightly earlier in ootAssemblyNotes11. The idea is that you probably want to PUSH the outcome of most of the instructions except at the end.

---

So how about:

2 formats:

• 64-bit MEDIUM IMMEDIATE: 2 form bits + 12-bit opcode + 3x (4 bit addr mode + 12 bit operand) combined into >=32-bit immediate
• 64-bit SHORT (4 packed instructions): 2 form bits + 1x 7-bit + 2x 8-bit + 1x 7-bit

hmm:

• immediate 0 and 1 are probably less useful than you might think
• surely we could spare a bit to indicate if the output should be PUSHed onto the stack, or if it should overwrite a register, or if it should overwrite TOS? Or mb just always PUSH.
• also, i forgot we only need 1 format bit for SHORT, not 2
• this format doesn't leave much room for annotations

---

for the SHORT ones:

• 4 bit opcode
• various formats depending on opcode:
  • imm4: 4-bit immediate
  • (in

• 2-bit ordinary operand encoding:
  • register 0
  • register 1
  • stack (POP)
  • TOS (read the input from the top of the stack, but don't pop)
• output is always PUSH'd, except for when there is an 'out' argument
• the 7-bit instruction (the first one) replaces the first input in2 with 1 bit: register 0

instructions:

• ANNOTATE imm4: annotation_type2,annotation_value2: informative/notification (not consequential/impactful) annotation; has no effect (could be hints, information like stack maps used for program verification, etc). NOTE: should reserve one or more annotation_types for implementation-defined annotations (or does 'comment' serve as this as well?)
• JS in2 imm2: jump to in2 + imm2
• BR imm4: relative branch by (signed) imm4 instructions
• SKZ in2: if in4 was zero, then skip next instruction (note: in MEDIUM mode, the skip can have a constant from 1 to 256, but this must always be 1 in user code, because it may expand as custom instructions are inlined)
• SKNZ in2: if in4 was non-zero, then skip next instruction
• MOV out2 in2:
• ADD-U15 in2 in2: add
• SUB-U15 in2 in2: subtract
• LEQ in2 in2: <=
• LOAD out2 in2: Load value from memory location at in2 to out2
• STORE out2 in2: Store value from in2 into memory location at out2
• LOADI imm4: Push constant
• SYSCALL n4: Call out to external library function or custom instructions n4, which will pop any needed arguments from the stack, and push any results to the stack
• ??: LEA in2 in2: Load Effective Address; inputs are address mode and operand
• ??: CALL
• ??: RET
• ??: MOV1 (MOV with two input operands concatenated to a single long input operand)
• ??: MOV2 (MOV with dest and one of the input operands concatenated to a single long output operand)
• ?:: alternative translation block (eg CALL as a single LONG instruction vs CALL as many medium instructions; but in general every alternative block may span multiple instructions). Perhaps this has the effect of an unconditional JMP to the last alternative block, for those interpreters that can't understand the other alternatives.
• ??: MOVSTACK (when you want to mmap a datastack or callstack)
• CALL4, CALL5, CALL6 (for calling first-class functions in SHORT mode)
• SAVEREGS(highest # reg to save), RESTOREREGS(highest # reg to restore) (to memory, or to stack?)
• todo: would be nice to have a LOADI2 out2 imm2
• todo: would be nice to have an ERR or RAISE that reports (or throws?) a specific error code, and would be nice to have a BRK that traps (or just a TRAP, at least)

plus one MEDIUM instruction (LOADI 16-bits; note it can fit more than 16 bits but for SootB? we don't assume that our regs can hold more than 16 bits; i guess we should offer variants of LOADI that load into register 0, register 1, stack, or TOS? ordinary MEDIUM mode can support each of those. Maybe we also offer a 'STOREI' which writes a 16-bit immediate to any 11-bit address in (register?) memory)

NOTE: in MEDIUM, 'BR' in user-level code is constrained to only use 8-bits (one of the two inputs). The other input is reserved for the implementation. It is expected that the implementation uses this when inlining custom instructions (which increases the distance between points in user-level code).

todo: for hierarchical modules, need a way to LOADK an imported module into somewhere, and then LOADK from that memory location to access something exported by that module. I guess just treat modules as address subspaces.

---

y'know, i'm backing off the idea of unifying SootB? and SHORT. The thing is, SHORT is supposed to be efficient, and we won't know what's efficient until we profile, and we may want to change it each release to be most efficient. Whereas SootB? is for bootstrapping, so it prboably shouldn't change so rapidly. Otoh SootB? bootstrapping will run more efficiently if code density is high.

i guess the answer is, unify them but not yet? mb until then just use the subset-of-MEDIUM thing?

---

eh, maybe unifying SootB? and SHORT is good after all.

i guess what's really going on is that i think it's not worth spending as much time and energy as i have been on the details of SootB? (and even OotB?