gistfile1.txt

Differences between my prototype (alorito) and m0-spec
* Arguments to calling new contexts is an RPA
  -> This could be quite beneficial to JIT since it's explicit in the argument lists, where as
       setting registers inside another context seems difficult to optimize for
  -> Also, I'm not a fan of messing with other people's (or function's) stuff.
  -> Regardless, this is a feature that could be easy to ignore for the time being
* Registers are 256 of the same type
  -> It sounds reasonable to make 1 table of 256 register slots that all 4 types share
  -> It seems like the way to go is have a per-interp table that contains the PMC headers
  -> I have concerns about the size of each type is no consistent and how to handle that sanely
* Registers are not pointers to the variable table
  -> Not convinced we want this extra layer of indirection
* alorito currently has 43 ops, I would guess 10 of them are extra
  -> Each op instruction not only has an op, but also a type: Int, Num, Str, Pmc
  -> Not all ops have each type
  -> The type tells the VM the predominate type of the registers
  -> Some ops statically override some of the arguments to another type
* The math/bit ops are the same, except for sign extend shr/shl
* alorito has 3 comparision ops, iseq, isgt, isge
  -> I could go either way on this.  I would keep them because they are more explicit than sub/if
* There is no goto_cs, there is call
  -> alorito considers a context a pmc (a special, internal pmc type)
  -> a context can point to a code segment or a native function
* The register manipulation ops are coerce_[int,num,str,pmc]
  -> set is a special case where the source and destination are the same type
* The set_mem and get_mem functions are called store and load, to reflect other RISC ISAs
* New is alloc, free doesn't exist
  -> alorito assumes GC exists in native code
* There is an opcode for creating new contexts
  -> The PMC form takes a code segment that it will refer to
  -> The STR form takes a string and PMC and calls an informational function that all PMCs have
  -> I'm not sure how things without this opcode.  How can you call a context to create a context
       if you can't create a context?
* There is a lookup opcode, it is the glue for the object model
* I advocate that these context related opcodes are necessary, but they are in addition to how
    m0-spec is written right now, not in direct competition
* The approach alorito takes to FFI (or really, native functions) is completely different
  -> alorito offloads FFI by not defining it, but instead, treats all code segments equal
  -> A context can refer to a VM code segment, or a native code segement
  -> It is assumed that FFI would be one of these native code functions and take care of the
    translation between VM and native in native code
* Both approaches can live side by side if need be

* The approach alorito takes to bytecode files (.ito) was arbitrary and temporary
  -> The only real difference was the opcode layout.  alorito includes an 4byte immediate in
    every op
  -> I think having the immediate value is of value, and makes the most sense without the
    extra level of indirection with the variables table
  -> An alternate solution could be found to the immediate

* Objects are PMCs, and PMCs are chunks of memory
* However, a PMC also has some header to them, including
  -> The size of the PMC
  -> The actual pointer to the data
  -> A internal type indicator
  -> A lookup and vtable pointers (We may be able to only use lookup with closures)
* This has the added benefit of making compacting garbage collection easier, since the pointers
  to the variable sized data are only in once place, so the actual data could be moved willy nilly
  without affecting anything else
* alorito has several "internal" PMCs that have special meaning
  -> Boxed Int, Num and Str, for fast boxing and unboxing
  -> The basic segments that are loaded from the bytecode loader (or generated) are special
  -> Contexts
  -> C Methods
* alorito uses symbols for it's S type
  -> Adds speed to comparisons and lookups, which is really what the S registers should be for

* I am not a fan making registers special
  -> I debated for a long time about making register 0 always be null/0/''
  -> I could be convinced to make register 0 null/0/'' and register 1 the context
  -> The rest will be used infrequently and could be probably be better utilized by calling
    methods on the context

tl;dr: The major differences between m0-spec and alorito that need unified are:
* Calling a context, arguments passing
* Variables Table
* Creating contexts
* FFI handling
* opcode format
* Strings vs. Symbols
* Special Registers
(I think that's all)