* Replace vcells with variables
* Thread-safety in env.c wrt the hash table
* What is scm_c_lookup_env for?
* unify data structures between interpreter and vm: frames, environments?
* why is vm written in C? is there no way to generate the C?
* bytecode->objcode: what's with the 10 byte header?
  GOOF-0.5 + nlocs + nexts -- 256 max? -- make into a macro plz thanks
* guile-vm documentation, with function docs
* objecode necessary? why not just a u8vector? relationship to `program'?
  perhaps replace program with objcode
* tension between C and scheme. Would be nice to push more to Scheme.
  GOOPS can help with this.
* purpose of heapifying frames? is this a continuation thing?
* encoding of lengths into constant vectors/lists
  instead of always using two octets, use the encoding in
  vm.c:vm_fetch_length
  (23b587b0a1e73940b167f67a1d1f7273b7fc5f79); conv.scm:encode-length,
  conv.scm:decode-length; grep for 256.
* assign hardware register to fp on x86-64 in vm_engine.h

* from docs: still relevant?
   Most instructions deal with the accumulator (ac).  The VM stores all
results from functions in ac, instead of pushing them into the stack.
I'm not sure whether this is a good thing or not.
* update:
section 3.1
 -- Instruction: link binding-name
     Look up BINDING-NAME (a string) in the current environment and
     push the corresponding variable object onto the stack.  If
     BINDING-NAME is not bound yet, then create a new binding and push
     its variable object.


guile-vm code is beautiful!
except for (system base syntax). Terror. Replace with GOOPS imo.

