This is probably the worst possible way to implement a processor.

Instead of just bumping the instruction pointer by one or an offset, you now need to have code labels in your processor and a way to efficiently look them up.

goto "exit" means the processor needs to have a lookup table of all the possible nodes in the computational graph. Calling a function requires a global look up table.

How is that table implemented? Obviously you can't just have an array of code labels, because using a linear data structure would kind of defeat the point.

Instead you need to build hardware that can store a graph and its edges directly and each hardware unit also has a label matcher so you can load a particular node and its edges.

This seems like an absurd amount of effort for moving from one instruction to the next. You know, something that could have been done by doing a single IP+1 or IP+jump_offset.

See my sibling comment. Basically each text fragment (either each branch-free run of instructions or each function/method) would need to be an object w/ capability, and the linker-loader must arrange for all text references to have the correct pointers. And then it would work. It's just a complication of the linker-loader, but once a program is loaded there would be no further lookups (unless you use something like `dlsym()`). The compromise to make is that within each such text object you have linear addressing with small offsets.

What I meant, and indeed it was poorly explained, is that an address shouldn't be just an integer freely manipulable by any instruction. The microcode will obviously know how to an manipulate an address, but the ISA as a whole doesn't have to, and in fact shouldn't, with the exception of a few specific instructions. What I am advocating is that addresses should constitute a separate type, which isn't a simple alias to integers. I think that this is what capabilities are about.