Talk:ByteByteFork

Possible evolution

Where to go from there?

Infinite memory

If we're going to make it look like The Matrix, the memory should be "conceptually" infinite because, well, the world is huge after all. There are 2 ways this could be done.

• Memory addresses could be relative to the current thread's Instruction Pointer, with signed values to allow forward addressing (on positive value) and backward addressing (on negative values). Two problems though: 1) Since there's no ALU, we use table lookups. To use these tables, a thread needs to reach them with relative addressing, which means they should be repeated every N bytes, to be reachable from everywhere. Which is not particularly sexy. 2) The Instruction Pointers would still have to be able to reference the entire memory, because their location is permanent.

• Addresses could be null-terminated. Addressing can remain absolute, and there's no limit anymore: you can reach the whole memory, even if it's big enough to store the earth state. Such an address starts with a length-byte that contains a length L. After the length-byte, there are L bytes of data (where a part of the address is stored). Then, L bytes after the previous length-byte, there's another length-byte. It goes on until we find a length-byte of value zero.

One way or another, thread's Instruction Pointers have to reach the entire memory. Null-terminated addresses can do this, but it means that when the size of an IP changes, the IP zone has to be reorganized.

Bulk copy

While keeping the "one instruction" spirit of ByteByteJump, we could also add a fourth instruction parameter which would be the length of the copied zone. For example, it would allow the instant creation of a clone thread. In a huge system, this could prove useful, and I think it feels quite natural.

  copy from 13 to 19 with length 3
      ----------------------------------------------------------
      address     12  13  14  15  16  17  18  19  20  21  22  23
      value        1   2   3   4   5   0   0   0   0   0   0   0
      ----------------------------------------------------------
      address     12  13  14  15  16  17  18  19  20  21  22  23
      value        1   2   3   4   5   0   0   2   3   4   0   0
      ----------------------------------------------------------

Now, with such a feature, relative addressing becomes more sexy than it was, because in-block references are kept valid: if you're cloning a block of data/code that has self-references, the clone will also have self-references instead of having references to the block it was cloned from.

   copy from 15 to 19 with absolute addressing
       ----------------------------------------------
       address     12  13  14  15  16  17  18  19  20
       value        0   0   0  13   0   0   0   0   0
       ----------------------------------------------
       address     12  13  14  15  16  17  18  19  20
       value        0   0   0  13   0   0   0  13   0
       ----------------------------------------------
   => the clone points to the original

   copy from 15 to 19 with relative addressing
       ----------------------------------------------
       address     12  13  14  15  16  17  18  19  20
       value        0   0   0  13   0   0   0   0   0
       ----------------------------------------------
       address     12  13  14  15  16  17  18  19  20
       value        0   0   0  -2   0   0   0  -2   0
       ----------------------------------------------
   => the clone points to the clone

Relative null-terminated addresses

In order to have the best of both world, relative null-terminated addresses can be used. An address starts with a length-byte that contains a length L, followed by L bytes of data. L bytes after this length-byte, there's another length-byte. It goes on until we find a length-byte of value zero. Of all the data bits, the first bit indicates the sign of the address.

Now one more thing. If we have tables at given locations, we want our clones to be able to reference them with absolute addresses. One solution is to use an extra-bit to indicate whether the address is relative or absolute. So, in the end, the first bit indicates whether the address is absolute (0) or relative (1), and the second bit indicates whether it's positive (0) or negative (1). Or anything along the line.

Talking is fine. Implementing this behemoth at low level would be another story ;)