Recursive universes don't get interesting until you start doing system calls: > So when an inevitable bug occurred in that super-duper LIFE machine, the intell

Recursive universes don't get interesting until you start doing system calls: > So when an inevitable bug occurred in that super-duper LIFE machine, the intelligent entities in the simulation would have suddenly been presented with a window to the metaphysics which determined their own existence. They would have a clue to how they were really implemented. In that case, Fredkin concluded, they entities might accurately conclude that they were part of a giant simulation and might want to pray to their implementors by arranging themselves in recognisable patterns, asking in readable code for the implementors to be given clues as to what they're like. (Levy's Hackers https://www.worldcat.org/title/hackers-heroes-of-the-computer-revolution-25th-anniversary-edition/oclc/890527375 https://www.worldcat.org/title/hackers-heroes-of-the-compute... ofc, pp. 148-149 in Penguin, p. 120 in O'Reilly: https://books.google.ie/books?id=JwKHDwAAQBAJ&pg=PA120&lpg=PA120 https://books.google.ie/books?id=JwKHDwAAQBAJ&pg=PA120&lpg=P... ) It's unfeasible to keep scanning the whole of a simulated world to try to discern anything that might be intended to pass a message of course, so making a "real" or at least a normal system call involves using a pre-ordained area of the simulated space which is set aside as a buffer, altering the contents of that area according to some pre-ordained protocol known in advance to both the simulated world and the simulating program. Responding to the system call likewise involves the simulating program "miraculously" altering the state of a pre-ordained buffer area according to a pre-set protocol. Not only is this how you can implement system calls in recursive universes: this is what a system call necessarily is. System calls, calls to the runtime, just are events of this nature happening between simulated and simulating systems. Likewise any kind of message passing is built on top of this: basically the only way any process can pass a message to another is to make a system call requesting that a message be passed on to the intended recipient, then hope that simulating system will deliver it as requested. Then delivering the message obviously involves the recipient's simulating system—which isn't necessarily the same system as the sender's simulating system—appropriately altering the state of the recipient. (Unless the sender and receiver have a shared memory area, you could say, but that's not so different either: two simulated programs only have a shared memory area to the extent that the simulating system is pleased to keep the supposedly-shared area actually consistent in the two programs it is simulating.) Notice how annoying it is that, by and large, most system-call protocols don't allow a process to, for example, send its simulating system a message explicitly addressed to its simulating system's simulating system, or to send a simulated system a message explicitly addressed to one of its simulated system's simulated systems. I suppose you could set it up with nested VMs and their virtual Ethernet interfaces.