[muddle] we have MSUBRs
kaz at lambdaverse.org
kaz at lambdaverse.org
Fri Mar 23 19:47:22 PDT 2018
New stuff in: /mimi subproject.
Because the bytecode interpreter is a low-level very non-C-like
machine it seems like the abstractions of the C model are only getting
in the way, so I switched to assembly for our inital MIMI, just like
the original MIM. I've implemented the ops and builtins necessary to
run a factorial demo very similar to the factorial bytecode example in
the MIM docs (last Appendix, "Recursive Factorial
Function"). Implementation notes:
- RVECTORs: this part of the tape was corrupt in the MIM docs but
fortunately M-PL goes into great detail about RSUBR data types, so I
implemented RVECTORs according to the 105 docs--SUBRs can now have
static heap-allocated data (currently only possible to obtain by
hard-coding addresses since there's no loader protocol yet).
- MSUBRs: just like the description of RSUBRs, except the WORDs are
bytecode rather than PDP machine code, and the "call mediator" is
the bytecode interpreter rather than an ITS facility.
- APPLY: the factorial is computed recursively. The APPLY operation
will be sufficient for every kind of call--the vagaries of optional
args and quoting can be handled at function prologues and call
- UNPARSE: our first builtin MSUBR. Currently capable of producing
newly heap-allocated octal BYTES representations of FIXes.
- toplevel: the MSUBR that never returns. Eventually this should call
LISTEN or FLOAD a filename specified on the command line, but for
now it applies a factorial MSUBR to #FIX 5, applies the UNPARSE
builtin MSUBR to the result, and invokes PRINC with the BYTES
For now I'm using assembler macros as the MIM assembler, so locals
don't have names and it's a little less friendly than real MIM
assembly; once I've systematized the opcode numbers and they aren't so
heavily in flux I'll convert the macro definitions back into
codegen.mud's format so it can generate the MIM assembler (which will
eventually be a MIMC component) and the x86 assembler defs from the
Because the interpreter has very little state of its own between
opcodes and whole OBJECTs are packed into quadwords, if you set
breakpoints based on the interpreted program's PC the bytecode-level
debugging experience in gdb is quite pleasant. It's much like the way
the docs describe DDT, though: We'll need a different approach for
MUM-level debugging to be able to achieve legendary the powers of
EDIT, ESP, and MEND, but gdb works very well for low-level debugging.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the muddle