lorito braindump

lorito braindump

lorito braindump
MOP topics:
  What is a MOP?
    - a MOP is a programmatic interface for creating classes.
    - in our case, it's split into REPR (low-level representation) and HOW (other)
    - 
  What is our MOP?
    - It's based on jnthn's 6model work.  Go read up on that now.
    - his timeline is uncertain, but this is worth getting right
      - Rakudo needs it and he's capable.  We'll wait.
      - he has minions if he can figure out a good way to use them
      - yes, I'm justifying that we might end up blocking on him for an indeterminate amount of time
  Work on Lorito and the MOP can continue independently for the next month or two, though M0 will eventually need a MOP
    - We don't want M0 to be closely tied to the MOP.  
      - The MOP will be implemented in terms of M0 ops.
      - In theory, anything can implement the MOP interface.
        - In practice, I have no idea.
      - M1 PIR will be closely tied to the MOP's interface and isn't guaranteed to be portable to other MOPs.
    - We'll have a recommended MOP implementation that should be flexible enough to implement any object system, but you aren't forced to use it.
      - chromatic will be in charge of porting jnthn's work to Parrot in its current state
      - once we have that working, we'll write an M0 version
        - changing a MOP is hard.  Changing a MOP and porting Parrot to M0 at the same time is insane.
    - Any MOP can be used by HLLs, but alternate implementations might not be interoperable.
      - we need to think about what interop looks like
    - in the meantime, we can implement simple things in M0 just so we have something to run and generate simple bytecode
      - compressed bytecode won't be useful until it's generated; sane people won't want to write large amounts of M0
  apostrophe
    - stands in for other letters:  it is => it's nice that you found a cow under your bed
    - when you can use "his", don't apostrophize: (its|his) wings smelled of bananas
  What is a PMC register?
    - PMCs living only in registers has some *really* nice implications for GC
    - pointer to a thingy?
      - this means a lot of dereferencing
      - If all PMC pointers are in registers, copying/compacting becomes feasible
    - MOP headers (s-table)?
      - less dereferencing, more space allocated for a register set
      - I/N and S/P registers are different anyway.  Having in-memory representations be a different size is workable.
      - q: How much of an object can be stored in a contiguous block of memory?
    - opaque thingy that fulfils a generic meta-interface?
      - probably not
      - What does a generic MOP meta-interface even look like
      - at some point, a thing is hard-coded
        - It's not turtles all the way down, even if it pretends to be.
      - if there's a generic placeholder, we can get more done before we block on the full MOP
        - this can be a known subset of the MOP, though.
        - sorear seems to think that parts of 6model are pretty stable.
        - using a workable subset of 6model is the best option because we won't be throwing much away
    - it'd be easier to answer this question if we could say with certainty that nobody will ever need another MOP
      - seems overly optimistic
  Strings and PMCs will share their underlying implementation, but they still need to have different registers
    - Strings are PMCs
    - this means fewer code paths and special cases
    - not sure why separate registers are warranted
      - possibly just because that's how Parrot is now and it means fewer changes

more context:
  threading:
    - context on its own is a bit bare for a thread
    - a thread should have only one active context

Op topics:      
  M0 ops are not controlled.  Permissions metadata is added at a higher level
    - If you get to M0, you own the system.
      - you can work around the MOP, manipulate interals directly, escape into other segments or C, etc
    - think about something like Java's checked exceptions
        - an M1 method has to either declare what it can throw or handle it.  Otherwise it won't compile.
          - not sure how this will mesh with PIR compatibility
          - possibly we'll extend PIR or have a safe mode that requires explicit permissions handling
          - I'm just throwing ideas out there.
          - PIR isn't that great as-is, though we Do Not Want to break compatibility for people using it, even if we recommend something else
  M0 will be both a compiled bytecode format and a human-readable assembly language-like representation
    - most code will be generated, but we'll need to be able to verify what's generated for debugging
    - translation between the two should be *extremely* straightforward
  Why not use an existing solution?
    - it's concievable but unlikely
    - requirements for M0
      - brutally simple
      - licensing
      - minimal op set
      - register-based
      - no magic
      - easy to reimplement (js/perl/ruby, C func/C snippet, asm, llvm)
      - want to get the damn thing right
      - we have to fully understand it
    - possibilities
      - LLVM: Quality/usability concerns about the C interface.  licensing uncertainty esp. wrt patents.
      - Neko - stack based
      - MMIX - no
      - others?
  aggregate ops:
    - we want a compile-time system that detects common series of M0 ops and aggregates them into a single op
      - compile-time means that on-disk bytecode and in-memory bytecode will be smaller
    - we want space-efficient and memory-efficient op representations
    - It will take a large number of M0 ops to get something done.  
      - aggregate ops will be more efficient, especially if they're generated based on the patterns that show up in generated code.
    - This doesn't need to correlate with how the M0 is generated.
      - PIR -> M0 can generate a long list of M0 ops.  A second pass can identify common sequences of ops and aggregate them.
      - We may want to have predefined libraries for e.g. PIR.
      - If we do this at runtime, it starts to get close to a HotSpot- or trace-based jit
  metadata:
    - we need a way to indicate the permissions needed by a chunk of M0 bytecode
    - segments seem like a fairly natural way to divide this
    - When a user receives a chunk of M0 bytecode, how does the interp know what permissions it needs?
  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
    - If we have a decent register allocator and drop stuff on the floor, the system's GC can clean it up (.Net, jvm)
    - having all PMCs in registers has some Really Nice impllications for GC complexity.
  for now, alloc is an M0 op
    - this is for bootstrapping until we get ffi nailed down and can call system malloc directly
  for int size, there are multiple strategies
    - the default int is the widest supported types
    - option: look at the highest bit, optionally autopromote
      - autopromotion only happens at M1 or above
      - M0 is maximally non-magical
    - different M1 ops deal with different types
      - a register is just a bunch of bits until ops treat it a certain way
    - question: Is it possible to use the MOP to deal with ints and still be efficient?
      - N-registers aren't often used.  It'd be nice if they could be PMCs and still be efficient.
      - if you can make NotFound happy, you've probably found a winning solution
        - if not, it won't kill us to keep them as under-used registers
  M0 bytecode segments will be immutable.  You can load and unload them, but self-modifying code is impossible
    - will fixups be necessary?  Under which circumstances?
  what about backtraces?
   - The scheme people have been dealing with backtraces and TCO for years.  Figure out what they do.

   read/integrate: http://irclog.perlgeek.de/parrot/2010-12-17#i_3098081

FFI topics:   
  look into how Factor does ffi ("alien")
    - Factor rolls their own.  Forth has a history of generating ASM from DSLs.  This probably isn't feasible for us.
    - portable ffi is a hard problem that we need to have a solution for.  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 by default (any volunteers?)
    - hard-coded thunks may be a temporary option, but yuck.