atrodo's brain
1 - context is the new interp
- context contains the PC, INSP regs, other stuff as needed (outPC, ehPC, payload, parentContext)
I<I like this idea. To what I've done, the context/interp definition has changed. The interp
is the core that runs the code, but really, all the guts are in the context.>
- there's no goto. You assign to the PC
I<I'm not sure how this would work. Will the PC have a special register, or would there be
a series of context method calls to set this? Or is there a special opcode for it?>
- 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)
I<>
- each context has its own REPR/HOW
- MOP allows security (limited subclass), optimization for platforms (mobile, embedded, PL/X)
I<To me, REPR/HOW is a detail for a higher level.>
- context is the implicit first arg to all ops (we now have 4-arg ops)
I<>
- Is there a solution in terms of immutable contexts? (chromatic)
I<Immutable contexts?>
- on invoke and fork, a new context is cloned pointing to the parent
- Context state is COW'd
I<The COW is really an implentation detail, but cloning on new thread seems like the right
thing to do>
- there's nothing more global than the context
- this may not be entirely true. There should, 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
I<Maybe I'm lacking the conversation, but in what circumstances would you want to subclass
context? Seems like one of the few things you'd want to keep special.>
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
I<How does the MOP fit in with register allocation?>
3 - for now, alloc is an M0 op
I<I think this item demonstrates a key differance with the approach I've taken. All PMCs in my
proto-lorito are an allocation of memory, just like you would get with pointers in a
traditional, low level machine. So that means new is alloc.>
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
I<Yes. Although, I would augment the thought I think is behind this. If the C function
interacts with lorito, there should be as little between the call from lorito to C. My
current plan is to have a single function signature that any calls to C must conform.
After it's in C land, nci or ffi can take over and call the actual destination after doing
it's magic. The cost of magic should not be incurred for every call to C, because isn't
that our problem today?>
5 - for int size, there are multiple strategies
- look at the highest bit, optionally autopromote
I<Should autopromote be a function of M0? Or should higher levels deal with this?>
- 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.
I<Interesting idea. Not real sure how'd that work, but could be worth exploring>
9 - Work on Lorito and the MOP can continue independently, though they'll eventually need each other.
A - Strings and PMCs can share their underlying implementation details, but they still need to
have different registers
- Strings are PMCs
I<I'm a fan of this idea. Except that the S registers stay around, but as Symbols, not
strings. This also implies that direct manipulation of symbols is impossible, loop have
to be jumpped to create new symbols.>
what about: segments
I<This is the most sane thing to do. Otherwise you have a flat, unpredictable address space.
Having segments that you can pass around and interact with gives much better encapsulation
and security.>
what about: messing with the running bytecode
I<I think being able to manipulate or generate new bytecode is a must have. There are a lot
of implications in being able to do it all in memory with method calls, but it almost has to
be done that way.>
what about: backtraces
I<Yes. About that...>
I<In my opion, for what it's worth, Lorito should be designed as a specification. This the
bytecode format. These are the ops. These are the required PMCs that must be written
natively. This is the test suite that it must pass. So developing a new Lorito implemtation
should only require writing 10% or less of the entire code base. There's new worlds out there
where C doesn't exist, and there's only going to be more. Confining ourselves to C and only C,
I think, is a little silly.>