proj-oot-ootAssemblyNotes24

---

190529

we need to take a hard look at if Boot is meeting its goals: i'm not sure that it's any easier to implement than RISC-V RV32I.

it provides other benefits:

• the only thing that depends on native pointer size is pointer size
• it's 32-bit
• pointers are opaque
• it will incorporate opcodes for all the syscall primitives necessary for bootstrapping and core interop
• because of the secondary registers and smallstack, you can probably write a bunch of core algorithms in it directly
• it's a 16-bit encoding instead of 32-bits
• it has that cool Smallstack, which probably increases code density
• it's a stepping stone to BootX?, which is pretty expressive

it's better than WASM (no weird structured control flow), simpler than JVM, much simpler than CIL, simpler and lower level than Lua, and simpler than ARM (esp. in instruction encoding). But it may be more complicated than RISC-V. And RISC-V is more popular, so even if it were equal complexity, RISC-V should win.

i used to be scared of RISC-V's instruction encoding variants, but now we have a bunch of those too! And ours are (right now, at least) even less regular than theirs, and also theirs are more thought out and have a bunch of properties that they claim are important for simple, efficient hardware decoding:

• their register operands are always in the same place
• the high bit (sign bit) of their immediate operand is always in the MSb bit (bit 31)
• also, they didn't mention this, but i notice that their rd (destination register) is nearest to the opcode, whereas we have it in the other order -- not sure if that's important though

Yes, their 32-bit and 64-bit platforms are different not only in pointer size, which makes it harder for us to write code targeting both. But we already have an unknown pointer size in Boot, is it really that much trouble to have distinct 32-bit and 64-bit targets? And it's probably not so much trouble to make it worth it to have to start from scratch toolchain-wise with a new assembly language.

Yes, for our purposes, it's slightly simpler to include the necessary syscalls as opcodes. But again, not worth the complexity of introducting a new assembly language.

the only thing that i think might really be important is pointer opaqueness. I'm imagining interop situations where we are running inside a high-level platform like Python, and we want to interoperate with its data structures. In this context we don't have pointers, we have opaque references. We can store them, but not in integers. We can't do pointer arithmetic on them even if we want to. I'm imagining that we will be accessing struct fields (e.g. objects) by assigning a numerical offset for each field and then adding that offset to the base 'reference's, which is why i include the operation of adding an int to a pointer. (now that i say this, it strikes me that even blt-ptr (bltp) is too much, ok i just took that out).

in older versions of Boot we had systems that made the pointer size totally opaque; the program didn't even have to know it for memory layout b/c memory was accessed in terms of pointer-sized words. Should we go back to that?

In any case, we should at least work on our instruction encoding to make it more regular, more like RISC-V.

i think the takeaways are:

• yes, it may still be worth it to do Boot, because pointer opaqueness is a big deal
• i took out blt-ptr just now
• need to improve instruction encoding. Probably should split up the opcodes, like RISC-V does, and also put high bits of immediates at the end, they seem to think that's important.
• consider going back to memory operations that operate in terms of words (slots) of the same size as the ptr. we can still have quantities restricted to 32 bits... this would allow us to have programs that are completely architecture-independent, which is a big win

---

ok so thinking a little more, we need to go back a little to the more complex system where memory was a linear sequence of locations of opaque type and size. The reason is that the whole reason that we want totally opaque pointers is in order to use Boot code in situations like when we are running on top of Python; memory we allocate is Python arrays and we access Python objects by assigning a numbering to their fields and then treating the object reference as a pointer and adding integers to that pointer to specify the fields. The ability to do this is why Boot is more useful for interop than RISC-V.

so some considerations:

• we need to bring back the OTHER type that i took out. Namely, Boot memory locations and registers (which register bank? they might be big, like pointers, but they can't be dereferenced) can hold opaque values of unknown type (these represent objects in some type that the underlying platform knows about but that the Boot implementor hasn't yet made interoperable with Boot). All you can do with these guys is copy them around.
• we may need to go back to making int registers of an unknown bitwidth which is >= 32 bits. The semantics of arithmetic may need to change so that wrapping at 2^32 is no longer guaranteed. This would introduce issues; now it's hard to check for overflow (you can't just see if the resulting value is too small), so we may need to go back to arithmetic with overflow checks, but then that can't be compiled to efficient code on many platforms. Alternately, we can keep int registers at 32 bits, which is what i'm leaning towards. This would imply that OTHERs definitely go in ptr regs.
• we need to bring back the more complicated semantics that i just deleted from the previous version about how it's an error to try and dereference OTHER types or ints
• it's not as easy as just saying that every addressable memory location can hold a pointer. Sometimes you want to navigate memory in smaller chunks than that, for example, when navigating the Boot instruction stream you want offsets in units of one byte because of the BootX?