proj-oot-ootAssemblyNotes11

Y'know, after the addition of the capabilities instructions and the various complexities of the OotB? i think OotB? is just getting too complicated. It's no longer an 'implement this on your platform in one afternoon' kind of thing.

So let's subset it yet again. SootB? is a simple stack-machine subset of OotB?.

---

note that OotB? is also rotated "Boot", which is appropriate.

---

we should have a compiler from OotB? to SootB?, not just an interpreter.

---

The need for SootB? calls into question the value of OotB? at all (as more than an implementation detail). If we are already compiling Oot Core into OotB?, and OotB? into SootB?, then why not just compile Oot Core into SootB?? Recall that two of the main motivations for a separate OotB? were (a) to make it dead easy to bootstrap on a new platform, (b) to have a separate layer of services (like GC, greenthreads, etc) underneath Oot Core. (and of course there's also the motivations of execution via a bytecode interpreter runtime, and having a platform-independent pre-compiled object format for storage of code, but these things are implementation details).

But now we have SootB?. And some non-trivial OotB? services (eg capabilities; forking) are being implemented in SootB?.

If we have SootB? then there's (a) already. As for (b), why not just implement the services themselves in Oot Core and then compile them from Oot Core directly into SootB?? Perhaps this compiliation might pass through OotB? as an implementation detail, perhaps not.

This would require Oot Core having a subset and a 'mode' in which the services are not relied upon. That seems doable. Like RPython; exceptions actually act differently in Python and in RPython (in some cases, in RPython, an exception is simply not generated at all if there is no exception handler matching it).

OotB? might still exist (as an implementation detail in the compiler from restricted Oot Core and SootB?, and in the module file format), and thinking about it in detail will still inform the semantics of this Oot Core 'mode'. But it may not be something that either Oot users or porters have to think about.

This is disappointing to me because i've developed an affection for OotB?. But at the same time i have been feeling that i've been placing too much importance onto what should be implementation details, and premature optimization. How many addressing modes should OotB? really have? Should it have indirect offset? Should it have indirect, or instead have LOAD/STORE? I dunno, that stuff is an optimization. Also, i feel that having three layers (OotB?, Oot Core, Oot) is already pushing it, and having 4 layers is too much (as an implementation detail that would be fine, just not as part of the main design).

So if i decide that what i've written above is correct, then maybe OotB? is dead. But it will live on in the form of a fairly close mapping between restricted Oot Core, and OotB?, at least initially.

There are three hitches.

First, some of these services (like capabilities and greenthreads) really do seem like they have to run 'beneath' ordinary Oot Core. If the non-primitive 'custom functions' in the OotB? stdlib are to be written in a manner oblivious to capabilities and greenthreads, then these implementations may have to run 'on top of' a lower-level execution environment. Perhaps we could come up with some metaprogrammy stuff in Oot Core to express this?

Second, a huge benefit of OotB?