Editing Register machine (section)

== Historical development of the register machine model ==
Two trends appeared in the early 1950s. The first was to characterize the computer as a Turing machine. The second was to define computer-like models—models with sequential instruction sequences and conditional jumps—with the power of a Turing machine, a so-called Turing equivalence. Need for this work was carried out in the context of two "hard" problems: the unsolvable word problem posed by [[Emil Post]]<ref name="Post_1936"/>—his problem of "tag"—and the very "hard" problem of [[Hilbert's problems]]—the 10th question around [[Diophantine equation]]s. Researchers were questing for Turing-equivalent models that were less "logical" in nature and more "arithmetic."<ref name="Melzak_1961"/>{{rp|page=281}}<ref name="Shepherdson-Sturgis_1963"/>{{rp|page=218}}

The first step towards characterizing computers originated<ref group="nb" name="NB3"/> with [[Hans Hermes]] (1954),<ref name="Hermes_1954"/> [[Rózsa Péter]] (1958),<ref name="Péter_1958"/> and Heinz Kaphengst (1959),<ref name="Kaphengst_1959"/> the second step with [[Hao Wang (academic)|Hao Wang]] (1954,<ref name="Wang_1954"/> 1957<ref name="Wang_1957"/>) and, as noted above, furthered along by Zdzislaw Alexander Melzak (1961),<ref name="Melzak_1961"/> [[Joachim Lambek]] (1961)<ref name="Lambek_1961"/> and [[Marvin Minsky]] (1961,<ref name="Minsky_1961"/> 1967<ref name="Minsky_1967"/>).

The last five names are listed explicitly in that order by [[Yuri Matiyasevich]]. He follows up with:
:"''Register machines [some authors use "register machine" synonymous with "counter-machine"] are particularly suitable for constructing Diophantine equations. Like Turing machines, they have very primitive instructions and, in addition, they deal with numbers''".<ref name="Matiyasevich_1993"/>

Lambek, Melzak, Minsky, Shepherdson and Sturgis independently discovered the same idea at the same time. See note on [[#Precedence|precedence]] below.

The history begins with Wang's model.

=== Wang's (1954, 1957) model: Post–Turing machine ===
Wang's work followed from Emil Post's (1936)<ref name="Post_1936"/> paper and led Wang to his definition of his [[Wang B-machine]]—a two-symbol [[Post–Turing machine]] computation model with only four atomic instructions:
 { LEFT, RIGHT, PRINT, JUMP_if_marked_to_instruction_z }
To these four both Wang (1954,<ref name="Wang_1954"/> 1957<ref name="Wang_1957"/>) and then C. Y. Lee (1961)<ref name="Lee_1961"/> added another instruction from the Post set { ERASE }, and then a Post's unconditional jump { JUMP_to_ instruction_z } (or to make things easier, the conditional jump JUMP_IF_blank_to_instruction_z, or both. Lee named this a "W-machine" model:
 { LEFT, RIGHT, PRINT, ERASE, JUMP_if_marked, [maybe JUMP or JUMP_IF_blank] }
Wang expressed hope that his model would be "a rapprochement"<!-- which one? <ref name="Wang_1954"/> or <ref name="Wang_1957"/> -->{{rp|page=63}} between the theory of Turing machines and the practical world of the computer.

Wang's work was highly influential. We find him referenced by Minsky (1961)<ref name="Minsky_1961"/> and (1967),<ref name="Minsky_1967"/> Melzak (1961),<ref name="Melzak_1961"/> Shepherdson and Sturgis (1963).<ref name="Shepherdson-Sturgis_1963"/> Indeed, Shepherdson and Sturgis (1963) remark that:
:"''...we have tried to carry a step further the 'rapprochement' between the practical and theoretical aspects of computation suggested by Wang,''"<ref name="Shepherdson-Sturgis_1963"/>{{rp|page=218}}

[[Martin Davis (mathematician)|Martin Davis]] eventually evolved this model into the (2-symbol) Post–Turing machine.

'''Difficulties with the Wang/Post–Turing model''':

Except there was a problem: the Wang model (the six instructions of the 7-instruction Post–Turing machine) was still a single-tape Turing-like device, however nice its ''sequential program instruction-flow'' might be. Both Melzak (1961)<ref name="Melzak_1961"/> and Shepherdson and Sturgis (1963)<ref name="Shepherdson-Sturgis_1963"/> observed this (in the context of certain proofs and investigations):

:"''...a Turing machine has a certain opacity... a Turing machine is slow in (hypothetical) operation and, usually, complicated. This makes it rather hard to design it, and even harder to investigate such matters as time or storage optimization or a comparison between the efficiency of two algorithms.<ref name="Melzak_1961" />{{rp|page=281}} "...although not difficult... proofs are complicated and tedious to follow for two reasons: (1) A Turing machine has only a head so that one is obliged to break down the computation into very small steps of operations on a single digit. (2) It has only one tape so that one has to go to some trouble to find the number one wishes to work on and keep it separate from other numbers''"<ref name="Shepherdson-Sturgis_1963" />{{rp|page=218}}

Indeed, as examples in [[Turing machine examples]], Post–Turing machine and [[partial function|partial functions]] show, the work can be "complicated".
<!-- Example: Multiply '''a''' x '''b''' = '''c''', for example: 3 x 4 = 12.

The scanned square is indicated by brackets around the mark i.e. ['''1''']. An extra mark serves to indicate the symbol "0".

At the start of a computation, just as Shepherdson–Sturgis and Melzak complain, we see the variables expressed in unary—i.e. the tally marks for '''a'''= '''| | | |''' and '''b''' = '''| | | | |''' – "in a line" (concatenated on what Melzak calls a "linear tape"). Space must be available for '''c''' at the end of the computation, extending without bounds to the right:
{|class="wikitable"
|- style="font-size:9pt" align="center" valign="bottom"
| width="14.4" Height="11.4" |
| width="13.8" |
| width="13.8" |
| width="13.8" | top
| width="13.8" | a
| width="13.8" | a
| width="13.8" | a
| width="13.8" |
| width="13.8" | top
| width="13.8" | b
| width="13.8" | b
| width="13.8" | b
| width="15.6" | b
| width="13.8" |
| width="13.8" | btm
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" |
| width="13.8" |
| width="13.8" |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="11.4" |
 |
 |
|style="background-color:#FFFF99" | [1]
|style="background-color:#FFFF99" | 1
|style="background-color:#FFFF99" | 1
|style="background-color:#FFFF99" | 1
 |
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|}

At the end of the computation the multiplier '''b''' is 5 marks "in a line" (i.e. concatenated) to left of the 13 marks of product '''c'''.
{|class="wikitable"
|- style="font-size:9pt" align="center" valign="bottom"
| width="14.4" Height="11.4" |
| width="13.8" |
| width="13.8" |
| width="13.8" | top
| width="13.8" | a
| width="13.8" | a
| width="13.8" | a
| width="13.8" |
| width="13.8" | top
| width="13.8" | b
| width="13.8" | b
| width="13.8" | b
| width="15.6" | b
| width="13.8" |
| width="16.8" | btm
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
| width="13.8" | c
|- style="font-size:9pt" align="center" valign="bottom"
| Height="11.4" |
 |
 |
 |
 |
 |
 |
 |
|style="background-color:#CCFFCC" | [1]
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
 |
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
|style="background-color:#99CCFF" | 1
 |
 |
 |
|}-->

===Minsky, Melzak–Lambek and Shepherdson–Sturgis models "cut the tape" into many===
{{Tone|section|date=January 2024}}
Initial thought leads to 'cutting the tape' so that each is infinitely long (to accommodate any size integer) but left-ended. These three tapes are called "Post–Turing (i.e. Wang-like) tapes". The individual heads move to the left (for decrementing) and to the right (for incrementing). In a sense, the heads indicate "the top of the stack" of concatenated marks. Or in Minsky (1961)<ref name="Minsky_1961"/> and Hopcroft and Ullman (1979),<ref name="Hopcroft-Ullman_1979"/>{{rp|pages=171ff}} the tape is always blank except for a mark at the left end—at no time does a head ever print or erase.

Care must be taken to write the instructions so that a test for zero and a jump occur ''before'' decrementing, otherwise the machine will "fall off the end" or "bump against the end"—creating an instance of a [[partial function]]. 

Minsky (1961)<ref name="Minsky_1961"/> and Shepherdson–Sturgis (1963)<ref name="Shepherdson-Sturgis_1963"/> prove that only a few tapes—as few as one—still allow the machine to be Turing equivalent if the data on the tape is represented as a [[Gödel number]] (or some other uniquely encodable Encodable-decodable number); this number will evolve as the computation proceeds. In the one tape version with [[Gödel numbering|Gödel number]] encoding the counter machine must be able to (i) multiply the Gödel number by a constant (numbers "2" or "3"), and (ii) divide by a constant (numbers "2" or "3") and jump if the remainder is zero. Minsky (1967)<ref name="Minsky_1967" /> shows that the need for this bizarre instruction set can be relaxed to { INC (r), JZDEC (r, z) } and the convenience instructions { CLR (r), J (r) } if two tapes are available. However, a simple Gödelization is still required. A similar result appears in Elgot–Robinson (1964)<ref name="Elgot-Robinson_1964" /> with respect to their RASP model.<!-- To do a multiplication algorithm we don't need the extra mark to indicate "0", but we will need an extra "temporary" tape '''t'''.  And we will need an extra "blank/zero" register (e.g. register #0) for an unconditional jump:

{|class="wikitable"
|- style="font-size:9pt" align="center" valign="bottom"
|style="font-weight:bold" width="83.4" Height="12" | At  the start:
| width="16.8" |
| width="15" |
| width="16.2" |
| width="15" |
| width="15" |
| width="15" |
| width="15" |
| width="15" |
| width="15" |
| width="15" |
| width="15" |
| width="15" |
| width="15" |
| width="15" |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | register 0:
|style="font-weight:bold" | []
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | a = register 1:
|style="background-color:#FFFF99" | 1
|style="background-color:#FFFF99" | 1
|style="background-color:#FFFF99" | 1
|style="background-color:#FFFF99;font-weight:bold" | []
|style="font-weight:bold" |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | b = register 2:
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC;font-weight:bold" | []
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | c = register 3:
|style="background-color:#CCFFFF;font-weight:bold" | []
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | t = register 4:
|style="font-weight:bold" | []
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="3" |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt"
|style="font-weight:bold" Height="12" align="center" valign="bottom" | At the end:
|  valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
| align="center" valign="bottom" |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | register 0:
|style="font-weight:bold" | []
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | a = register 1:
|style="background-color:#FFFF99;font-weight:bold" | []
 |
 |
 |
|style="font-weight:bold" |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | b = register 2:
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC" | 1
|style="background-color:#CCFFCC;font-weight:bold" | []
 |
 |
 |
 |
 |
 |
 |
 |
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | c = register 3:
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF" | 1
|style="background-color:#CCFFFF;font-weight:bold" | []
 |
|- style="font-size:9pt" align="center" valign="bottom"
| Height="12" | t = register 4:
 | 1
 | 1
 | 1
 | 1
|style="font-weight:bold" | []
 |
 |
 |
 |
 |
 |
 |
 |
 |
|}

We can write simple Post–Turing "subroutines" to atomize "increment" and "decrement" into Post–Turing instructions. Note that the head stays always just one square to the right of the top-most printed mark, i.e. at the "top of the stack". "r" is a parameter in the instructions that symbolizes the tape-as-register to be moved and printed or erased, and tested:
:
: "Increment r" = PRINT_SCANNED_SQUARE_of_TAPE_r, MOVE_TAPE_r_LEFT; i.e. (or: move tape r's head right)
::'''X+''' r is equivalent to '''P''' r; '''L''' r
: "Decrement r" = JUMP_IF_TAPE_r_BLANK(ZERO) TO XXX, ELSE MOVE_TAPE_r_RIGHT, ERASE_SCANNED_SQUARE_of_TAPE_rN; (or: move tape r's head left)
::'''X-''' r is equivalent to '''J0''' r, xxx; '''R''' r; '''E''' r

Indeed this is similar to the approach that Minsky (1961)<ref name="Minsky_1961"/> took. He started with 4 left-ended tape-machine that:
: "used the basic arithmetic device of the present paper. Then, two of the tapes were eliminated by the prime-factor method".<ref name="Minsky_1961"/>{{rp|page=438}}

He then observed that:
: "we may formulate these results so that the operations act essentially only on the ''length'' of the strings"<ref name="Minsky_1961"/>{{rp|page=449}}

His first model, "1961" (it had changed by 1967<ref name="Minsky_1967"/>) started out with only a single mark at the left end of each tape-as-register. The machine was not allowed to '''P'''rint any marks, just move '''L'''eft or '''R'''ight and test for the mark = "1" in the following example. Thus the conventional Post–Turing-like instruction set went from
: { R; L; P; E; J0 xxx; J1 xxx, H }

to, for each tape-as-register:
: { R; L; J1 xxx, H }

where '''R''' can be renamed '''INC'''rement, '''R''' can be renamed '''DEC'''rement, "J1" can be combined with "DEC" to create a non-atomized instruction, or can be kept separate and renamed '''J'''ump if '''Z'''ero. -->

=== Melzak's (1961) model is different: clumps of pebbles go into and out of holes ===
Melzak's (1961)<ref name="Melzak_1961"/> model is significantly different. He took his own model, flipped the tapes vertically, called them "holes in the ground" to be filled with "pebble counters". Unlike Minsky's "increment" and "decrement", Melzak allowed for proper subtraction of any count of pebbles and "adds" of any count of pebbles.

He defines indirect addressing for his model<ref name="Melzak_1961"/>{{rp|page=288}} and provides two examples of its use;<ref name="Melzak_1961"/>{{rp|page=89}} his "proof"<ref name="Melzak_1961"/>{{rp|pages=290–292}} that his model is Turing equivalent is so sketchy that the reader cannot tell whether or not he intended the indirect addressing to be a requirement for the proof.

Legacy of Melzak's model is Lambek's simplification and the reappearance of his mnemonic conventions in Cook and Reckhow 1973.<ref name="Cook-Reckhow_1973"/>

=== Lambek (1961) atomizes Melzak's model into the Minsky (1961) model: INC and DEC-with-test ===
[[Joachim Lambek|Lambek]] (1961)<ref name="Lambek_1961"/> took Melzak's ternary model and atomized it down to the two unary instructions—X+, X− if possible else jump—exactly the same two that Minsky (1961)<ref name="Minsky_1961"/> had come up with.

However, like the Minsky (1961)<ref name="Minsky_1961"/> model, the Lambek model does execute its instructions in a default-sequential manner—both X+ and X− carry the identifier of the next instruction, and X− also carries the jump-to instruction if the zero-test is successful.

=== Elgot–Robinson (1964) and the problem of the RASP without indirect addressing ===
A RASP or random-access stored-program machine begins as a counter machine with its "program of instruction" placed in its "registers". Analogous to, but independent of, the finite state machine's "Instruction Register", at least one of the registers (nicknamed the "program counter" (PC)) and one or more "temporary" registers maintain a record of, and operate on, the current instruction's number. The finite state machine's TABLE of instructions is responsible for (i) fetching the current ''program'' instruction from the proper register, (ii) parsing the ''program'' instruction, (iii) fetching operands specified by the ''program'' instruction, and (iv) executing the ''program'' instruction.

Except there is a problem: If based on the ''counter machine'' chassis this computer-like, [[John von Neumann|von Neumann]] machine will not be Turing equivalent. It cannot compute everything that is computable. Intrinsically the model is bounded by the size of its (very-) ''finite'' state machine's instructions. The counter machine based RASP can compute any [[primitive recursive function]] (e.g. multiplication) but not all [[mu recursive function]]s (e.g. the [[Ackermann function]]).

Elgot–Robinson investigate the possibility of allowing their RASP model to "self modify" its program instructions.<ref name="Elgot-Robinson_1964"/> The idea was an old one, proposed by Burks–Goldstine–von Neumann (1946–1947),<ref name="Burks-Goldstine-Neumann_1947"/> and sometimes called "the computed goto". Melzak (1961)<ref name="Melzak_1961"/> specifically mentions the "computed goto" by name but instead provides his model with indirect addressing.

'''Computed goto:''' A RASP ''program'' of instructions that modifies the "goto address" in a conditional- or unconditional-jump ''program'' instruction.

But this does not solve the problem (unless one resorts to [[Gödel number]]s). What is necessary is a method to fetch the address of a program instruction that lies (far) "beyond/above" the upper bound of the ''finite'' state machine instruction register and TABLE.

:Example: A counter machine equipped with only four unbounded registers can e.g. multiply any two numbers ( m, n ) together to yield p—and thus be a primitive recursive function—no matter how large the numbers m and n; moreover, less than 20 instructions are required to do this! e.g. { 1: CLR ( p ), 2: JZ ( m, done ), 3 outer_loop: JZ ( n, done ), 4: CPY ( m, temp ), 5: inner_loop: JZ ( m, outer_loop ), 6: DEC ( m ), 7: INC ( p ), 8: J ( inner_loop ), 9: outer_loop: DEC ( n ), 10 J ( outer_loop ), HALT } However, with only 4 registers, this machine has not nearly big enough to build a RASP that can execute the multiply algorithm as a ''program''. No matter how big we build our finite state machine there will always be a ''program'' (including its parameters) which is larger. So by definition the bounded program machine that does not use unbounded encoding tricks such as Gödel numbers cannot be ''universal''.

Minsky (1967)<ref name="Minsky_1967"/> hints at the issue in his investigation of a counter machine (he calls them "program computer models") equipped with the instructions { CLR (r), INC (r), and RPT ("a" times the instructions m to n) }. He doesn't tell us how to fix the problem, but he does observe that:
: "''... the program computer has to have some way to keep track of how many RPT's remain to be done, and this might exhaust any particular amount of storage allowed in the finite part of the computer. RPT operations require infinite registers of their own, in general, and they must be treated differently from the other kinds of operations we have considered.''"<ref name="Minsky_1967"/>{{rp|page=214}}

But Elgot and Robinson solve the problem:<ref name="Elgot-Robinson_1964"/> They augment their P<sub>0</sub> RASP with an indexed set of instructions—a somewhat more complicated (but more flexible) form of indirect addressing. Their P'<sub>0</sub> model addresses the registers by adding the contents of the "base" register (specified in the instruction) to the "index" specified explicitly in the instruction (or vice versa, swapping "base" and "index"). Thus the indexing P'<sub>0</sub> instructions have one more parameter than the non-indexing P<sub>0</sub> instructions:
: Example: INC ( r<sub>base</sub>, index ) ; effective address will be [r<sub>base</sub>] + index, where the [[natural number]] "index" is derived from the finite-state machine instruction itself.

=== Hartmanis (1971) ===
By 1971, Hartmanis has simplified the indexing to [[indirection]] for use in his RASP model.<ref name="Hartmanis_1971"/>

'''Indirect addressing:''' A pointer-register supplies the finite state machine with the address of the target register required for the instruction. Said another way: The ''contents'' of the pointer-register is the ''address'' of the "target" register to be used by the instruction. If the pointer-register is unbounded, the RAM, and a suitable RASP built on its chassis, will be Turing equivalent. The target register can serve either as a source or destination register, as specified by the instruction.

Note that the finite state machine does not have to explicitly specify this target register's address. It just says to the rest of the machine: Get me the contents of the register pointed to by my pointer-register and then do xyz with it. It must specify explicitly by name, via its instruction, this pointer-register (e.g. "N", or "72" or "PC", etc.) but it doesn't have to know what number the pointer-register actually contains (perhaps 279,431).

=== Cook and Reckhow (1973) describe the RAM ===
Cook and Reckhow (1973)<ref name="Cook-Reckhow_1973"/> cite Hartmanis (1971)<ref name="Hartmanis_1971"/> and simplify his model to what they call a random-access machine (RAM—i.e. a machine with indirection and the Harvard architecture). In a sense we are back to Melzak (1961)<ref name="Melzak_1961"/> but with a much simpler model than Melzak's.