The generative model of computing

Once upon a time I wrote a piece that turned out decent enough to deserve being re-written in English. This is the result of that re-write.

One of the fundamental properties of computing is that it can be represented at various layers of abstraction: what constitutes a program? Is it made up from a bunch of electrical signals? Or from evolving bits? Is it a set of registers changing their values in time? Or variables that are read, written and executed? Any of these is a valid representation, only one of them may be more useful to us than the others at a given time.

At the same time, one of the fundamental problems of software is that it is inherently replicable. Mind you, this is not my problem; I myself am very happy with how computing and software work -- at least when they do¹ -- which makes this ease of replication the exact opposite of a problem. It is however a problem for halfwits; for those people who believe that something that was read, and thus learned, can and sometimes must be magically un-learned; or who believe that something that was uttered can be magically un-uttered. No one sane knows why anyone would ever wish for this piece of nonsense to be possible², but computer engineering is supposed to give practical solutions to technical problems, and I'm feeling particularly generous today, so let's indulge this intellectual wankery.

As I was saying, software is replicable, and the problem is whether it can be made impossible, or at the very least extremely hard to replicate. That is, it is easy for virtually anyone to download a program off the Internet and run it on their computers; or a movie, or a secret document, and open them using a program. This works even when one is not legally authorized to do so, and it's simpler and a lot cheaper than actually stealing things, which forces the actual economic value of intellectual property to asymptotically go towards zero.

This pernicious issue can be easily described at the instruction set architecture level. Generally processors contain an instruction dubbed mov, which moves a numeric value from a register to another. The problem, however, is precisely that it doesn't move data: it copies it! That is, when saying mov r0, r1, we read for example "move data from r1 to r0", but we mean "copy data from r1 to r0"; in other words, upon setting r0 to the contents in r1, r1's value doesn't change at all³. This is so for very good practical reasons: firstly, it is more expensive to actually move data from one register to another, as we need to do two operations (set destination to source value; then erase source) instead of one; secondly, we don't know what the value of an "erased" (or otherwise "empty") register should be.

But let's leave aside these details for a moment and specify in more precise terms what it is that we want: a computer that cannot copy data per se, and that can only move it. This is, of course, impossible: one must put, i.e. create, or otherwise generate an object somewhere in able to be able to then move it somewhere else. So what we really want is a computer with two basic operations:

• a move operation: from register to register, from main memory to register, from disk to main memory, etc.
• a generate operation, that "puts" data into a memory unit (register, a cell in main memory, on disk, etc.)

An intuitive way to look at this is that any memory unit can be in one of two states: either "empty", in which case it cannot be read (i.e. used as a source); or "full", in which case it could be used as a source or destination if the user desires. Thus move cannot read from an empty register, while generate is pretty much equivalent to our old mov: it can read and write from and to anything. The advantage of this separation is that it would allow hardware manufacturers to limit the use of generate, by imposing a price on every instruction call and/or other policies, possibly used in conjunction with cryptographic approaches. Simply put, the possibility of having an instruction set with a move and a restricted generate opens up the possibility of a whole new different type of computing.

Let's look at some of the practical design and implementation challenges of this model. Performance is an issue, as discussed previously, at least as far as the fabrication technology remains the same. Space is also an issue, as every memory cell now needs at least an extra bit to represent empty or full state. Since the data in memory cells is usually moved around, then a. all move instructions need to be transactions, i.e. if and when a move is completed, we are guaranteed that the destination contains the desired data and the source is empty, otherwise the move has failed and the state hasn't changed; and b. all memory must be persistent, such that e.g. following a power outage the system can be restored to its previous state without any data loss. These engineering problems are perfectly approachable, if not necessarily trivial.

Then there are deeper problems: is this type of computer Turing-complete? This question cannot be given an off-the-top-of-head answer, and shall not be explored here due to space constraints.

Then there are other practical problems: how easy is it to program such a computer? Adding costs to copying would conceivably put a limit on the development of software, as it would emphasize economy over the writing of code; but that aside, how usable would the machine be from the point of view of the user/programmer⁴?

Then there is the problem that software producers themselves would need need to pay for every software copy that they sell, because they would need to copy it before selling it. Which brings us to the crux of the problem: software and hardware vendors concoct all these technologies, e.g. SGX, various DRM "solutions", without thinking of many of the trade-offs involved. One can't stop copying without putting limits to it; and then once they've done this, they can't copy without actually copying⁵; no, you can't have your cake and eat it too.