lorito braindump

gistfile1.txt

lorito braindump

1 - context is the new interp
  - context contains the PC, INSP regs, other stuff as needed (outPC, ehPC, payload, parentContext)
    - there's no goto.  You assign to the PC
    - in a protected context, you can only jump within the segment
    - in an unprotected context, you can also jump far away (C function, other segment, etc)
  - each context has its own REPR/HOW
    - MOP allows security (limited subclass), optimization for platforms (mobile, embedded, PL/X)
  - context is the implicit first arg to all ops (we now have 4-arg ops) 
  - Is there a solution in terms of immutable contexts? (chromatic)
  - on invoke and fork, a new context is cloned pointing to the parent
    - Context state is COW'd
  - there's nothing more global than the context
    - this may not be entirely true.  There shoud, however be *very* little global state. 
  - you subclass the context through itself, if the context allows it
    - there may be a global thingy for GC
    - in a limited context, you can't mess with that kind of thing
2 - for now, we have a fixed number of each register (e.g. 1024)
    - later after we have an allocator, we can make this dynamic through the MOP
3 - for now, alloc is an M0 op
4 - look into how Factor does ffi ("alien")
    - portable ffi is a hard problem.  We don't know the solution.
    - we clearly need something.  Calling into C-based Parrot internals is vital, external nci is really important
    - libffi looks really good, except that it can't do msvc or win64
5 - for int size, there are multiple strategies
    - look at the highest bit, optionally autopromote
    - the default is the widest supported types
    - different M1 ops deal with different types
    - Is it possible to use the MOP to deal with ints and still be efficient?
6 - we can use REPR to deal with types for e.g. ffi, efficient storage, user-friendly
7 - CPS works at an M0 level by using Contexts as the continuation
8 - M0 ops are not controlled.  Permissions metadata is added at a higher level
    - think about something like Java's checked exceptions
    - a method has to either declare what it can throw or handle it.  Otherwise it won't compile.
9 - Work on Lorito and the MOP can continue independently, though they'll eventually need eachother. 
A - Strings and PMCs can share their underlying implementation details, but they still need to have different registers
    - Strings are PMCs


what about: segments
what about: messing with the running bytecode
what about: backtraces