Introduction

See also:

• ootDesignTodos
• ootToReads
• ootToReadsCondensed (programming languages)

---

Contents

• Introduction
• Contents
• Plan
• Introduction
• Overall plan
• by timescale
• Short-term plan
• Medium-term plan
• Long-term plan
• Sub-plans (in sections)
• Todo
• Urgent and important
• Urgent but not important
• Important but not urgent
• (later: add other categories here)
• Unstructured notes/todos

---

Plan

Plan: Introduction

Plan: Overall plan

Specify and implement Boot, BootX

• test new encoding code

Implement:

• PyBoot?.
• amd64/x86_64 Boot via DynAsm?.
• Boot asm/disasm.
• PyBootX?.
  • Compare with my previous implementation of an earlier version.
• Implement prototype BootX? compiler to Boot.

Go thru and process:

• todo notes at the end of each of boot_extended_reference.adoc and boot_reference.adoc.
• ootAssemblyThoughts
• ootAssemblyNotes*.txt

Revise the Boot and BootX? specs.

At this point we have a draft Boot/BootX? platform.

Consider implementing:

• compilers to/writing an interpreter in/embedding Boot into Python, RISC-V, WASM, ARM Cortex M0, LLVM, JVM, Python, C (to learn if Boot is good at its job of being a 'universal assembly language')
  • note: of course in order to get a Boot interpreter in WASM or LLVM or JVM we could write it in Rust or C or Java and compile, but maybe, for the sake of learning if Boot is actually easy to port, we should actually write the source code in WASM or LLVM or JVM directly
• an LLVM backend to BootX? (to learn if we are unintentionally doing things in a way that makes contemporary code generation systems hard to use for targetting BootX?)
• a compiler from BootX? directly to LLVM or to WASM, skipping Boot (to allow us at least one real-world check if the dream of gaining efficiency by translating BootX? directly to a target holds water)

If something is learned during implementation, revise and revisit ootAssemblyThoughts and ootNotes*.txt as needed, revise the specs. At the end, reimplement these things to the revised specs.

At this point we have a portable assembly language platform/VM; Boot can be easily ported to new platforms, and BootX? can be compiled to Boot. So we can target BootX? going forward. When we wish to spend time optimizing Oot for a certain platform, we can bother to implement a compiler directly from BootX? to that platform.

Finally, add to my todo list to revise and edit and publish the assembly language concordance (until this point i might gain further experience with it).

Goals here:

• keep Boot extremely small and easy to implement, so that (a) it is easy to port, and (b) the roots of the implementation can be easily understood.
• BootX? is larger than Boot to provide the sorta-intersection of data types and operations popular contemporary target languages. This is so that (a) the implementation can be optimized by translating these extra data types and operations directly into platform primitives, and (b) BootX? backends can be more easily written for contemporary toolchains, which expect to find target languages supporting these things.

Implement macro assembler and/or HLL for BootX

To make it more convenient to write code for BootX?, implement a macroassembler and/or a very simple HLL that compiles to it.

For the HLL, we have some options:

• Scheme-like?
• Forth-like?
• Oberon-like?
• Polymorphism (probably generic)?
• Structured control flow? We probably don't want to introduce a real memory stack here yet... but maybe while loops and for loops even if not
• zig-like/C-like?
• (probably not too much C-like, nim-like, D-like, Rust-like: too complicated)
• how much metaprogramming?

The idea here is simply a more comfortable way to write platform-independent 'assembly language'. We don't yet want to introduce confining abstractions (like C does).

At that point, we'll have a more comfortable low-level platform that compiles to BootX?, and hence will be very portable.

Decide on and implement the next level

Now we have to decide what the (initial attempt at a) next level will be.

I'm currently thinking of a virtual machine that provides:

• a bytecode
• a set of 'low level primitives' upon which Oot Core will rely (stuff like map, reduce, arrays, linked lists, dicts)
• a backend that does annoying things like register allocation
• services such as a graph object store (with data nodes that have headers that specify their type (and custom node types can be added), and also where pointers are inside them, for GC; a la SEAM), GC, pickling, scheduling (and related concurrency and I/O)
• interop

Potential goals here:

• elucidate the set of 'low level primitives' upon which Oot Core will rely
• provide a set of fundamental HLL data types and operations to allow interop with HLLs into which we embed
• a platform that is easier to target than BootX? (because BootX? is an assembly language and targetting it requires register allocation, keeping track of the numerical code locations of jump targets, etc)
• a level that is at the ideal height for porting and interop, because it is low enough for easy implementation but high enough so that the semantics of the program have been suffiently preserved so as to allow efficient execution on the target platform

Implement an Oot Core

The goal at this point is not to decide all the pending design decisions and implement a real Oot Core, but rather just to slap something together so that i can start playing around with HLLs and getting experience in how the pending design decisions affect the implementation.

I'm not sure exactly what i should implement first, but i'm guessing:

• a language with Oberon-like capabilities including named variables and structured control flow
• hygenic macros and possibly other metaprogramming capabilities
• a labeled graph data structure
• a 'Roots of Oot Core' style meta-circular interpreter
• bindings to the basic classes of operations expressed by all of the BootX? instructions (eg bitshifts, I/O, etc)

After this point i can take stock of what i've learned and go back and revise my plans, possibly rereading a lot of the Thoughts and Notes files here.

The initial goal here is just to slap something together. The ultimate goals of Oot Core may include:

• a gem-like thing of perfect beauty (but also flexible!) [1]
• the semantics of Oot without the syntax or sugar
• a Lisp-like/homoiconic representation of code that is easy to process using macros
• a representation of code that is easy to process but tedious to type (e.g. perhaps with lots of type annotations)

Implement an Oot

In pre-Oot Core, implement an interpreter or compiler for pre-Oot (either as an interpreter, or possibly using metaprogramming, if that sort of thing is available). At this point we have bootstrapped pre-Oot. Now, in pre-Oot, implement an interpreter or compiler to pre-Oot Core (unless pre-Oot is just a metaprogrammed extension to Oot Core), and then implement an interpreter or compiler from pre-Oot Core to a lower level platform (either an intermediate platform, or BootX?). Also, reimplement the Python-based Boot/BootX? toolchains in pre-Oot.

At this point we'll have a self-hosting language toolchain.

Now we can really start playing around with pre-Oot and trying out the various design decisions.

Plan: by timescale

Plan: Short-term plan

• go thru the todos at the bottom of boots_reference and process them
• go thru boots_extension_reference and simplify it
• go thru boots_design and update it
• implement boots

Plan: Medium-term plan

Plan: Long-term plan

Plan: Sub-plans

---

Todo

Todo: Urgent and important

Todo: Urgent and not important

Todo: Important but not urgent

Todo: organization

• Need to make proglang learning Todo list -- less expressive than a bunch of English notes, but with more todo structure than an unadorned list of bullet points in sections

---

Unstructured notes/todos