[muddle] we have MSUBRs

kaz at lambdaverse.org kaz at lambdaverse.org
Fri Mar 23 19:47:22 PDT 2018


repo: git://git.lambdaverse.org/muddle
branch: master
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
  sites, respectively.
- 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
  produced.

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
same data.

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...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://muddlers.org/pipermail/muddle/attachments/20180323/118dc083/attachment.sig>


More information about the muddle mailing list