</p>
<RT·math>
- <RT·math>\aleph_{0}</RT·math> - <RT·math>\aleph_{-1}</RT·math> = 1
+ \aleph_{0} - \aleph_{-1} = 1
</RT·math>
<p>
<!--------------------------------------------------------------------------------->
<RT·chapter>The Universal Turing Machine</RT·chapter>
- <p>The Computer Theoretic model chapter provided symbolic definitions for the Turing machine and the TTCA variation. Those definitions were written as strings of characters, which the reader scanned, and presumably understood. Furthermore we explained in detail how an executor could make use of those definitions so as perform input string transformations. I proposed in the text that the executor could be a person, say a student, and in the text also described how a machine could execute the transformations automatically.</p>
+ <p>The Computer Theoretic model chapter provided symbolic definitions for the Turing machine and the TTCA variation. Those definitions were written as strings of characters, which the reader scanned, and presumably understood, thus demonstrating the ability of those text strings to convey meaning. Furthermore the text explained in detail how an executor could make use of those definitions so as to perform the input string transformations. As Turing originally noted, the executor could be a person. Alternatively, as the book continued on to describe in detail, the executor could be a machine that applied the input transformations automatically.</p>
- <p>In his original paper Alan Turing put these things together and explained that a Universal Turing Machine could read the definition of a Turing Machine from tape, and thus be a Turing Machine executor. Hence, say, a Turing Machine reads the symbolic definition of a Turing Machine from one tape, and then automatically performs the described input string transformations on another tape. Said Universal Turing Machine would then be chameleon like, performing the function of any other Turing Machine so described on the first tape.</p>
+ <p>In his original paper Alan Turing put these things together and explained that a Universal Turing Machine could read the definition of a Turing Machine from tape, and thus be a Turing Machine executor. Hence, say, a Turing Machine reads the symbolic definition of a Turing Machine from one tape, and then automatically performs the described input string transformations on another tape. Said Universal Turing Machine would then be chameleon-like, performing the function of any other Turing Machine so described on the first tape.</p>
- <p>The only information that the first tape of a Universal Machine need contain is the variable part, <RT·math>\mathit{MP}</RT·math>, which we called the <em>program</em>, as the remainder of the definition is common to all machines and can thus be built into the controller. <RT·math>\mathit{MP}</RT·math> describes a state controller, it lists the states, the symbols of the alphabet, the instruction to be issued from each state, the symbol gated next state transitions, and the halting state. The universal machine control program would then have to interpret that information and send the universal machine through the same steps that a human executor would take while running the described machine.</p>
+ <p>The only information that the first tape of a Universal Machine need contain is the variable part, <RT·math>\mathit{MP}</RT·math>, which the text established as the <em>program</em>, as the remainder of the definition is common to all machines and can thus be built into the controller. <RT·math>\mathit{MP}</RT·math> describes a state controller, it lists the states, the symbols of the alphabet, the instruction to be issued from each state, the symbol gated next state transitions, and the halting state. The Universal Machine control program would then have to interpret that information and send the universal machine through the same steps that a human executor would take while running the described machine.</p>
<p>However, the controller can be simplified if the program encoding is changed from the raw definition. Notice that the only information that leaves the state controller while it runs are the instructions issued per state, with that list terminating when the controller reaches the halt state.</p>
<p>Imagine then, mounting a tape on a given machine, running the machine, and recording the instructions that leave the controller up until it halts. Then taking that list of instructions, and the same input tape, and mounting them on a Playback Machine. The Playback Machine then takes the instructions from the list on the first tape and issues them out of its own controller one by one. The playback controller is quite simple. Though of course, this approach has the drawback of having to run the given machine first so as to observe it, thus making the playback run moot.</p>
- <p>Consider then, adding a jump table instruction. To create the program first examine the state diagram for the controller. Take all the sequential state runs, even those of length 1, from the controller, and list their instructions in the same sequence order. Wherever a state has next state transition arcs based on the value of the status register, insert jump table instruction, so that it jumps to the appropriate instruction sequence.</p>
+ <p>Consider then, inserting jump table instructions to handle the next state transitions. Then a state controller can be mechanically changed into an instruction sequence with embedded jump table instructions without having to run it and observe it. Accordingly, first examine the state diagram for the controller. Take all the sequential state runs, even those of length 1, from the controller, and list their instructions in the same sequence order. Then, after each such sequence, wherever a state has next state transition arcs based on the value of the status register, insert a jump table instruction, so that it jumps to the appropriate instruction sequence.</p>
<p>Take for example the TTCA machine two headed string reverse example, this procedure produces the following instruction sequence:</p>
+ <RT·code>
+ # Phase 1: Both heads scan right to the EOM pivot
+ L·initial:
+ read('s' ,0)
+ jump(s, {EOM: L·Check_Empty, def: L·Scan_Right})
+
+ L·Scan_Right:
+ right(0)
+ right(1)
+ jump(def: L·initial)
+
+ # Phase 2: Setup pointers or short-circuit on empty string
+ L·Check_Empty:
+ status(0)
+ jump(s, {leftmost: L·Empty_Setup, def: L·Setup_Write})
+
+ L·Empty_Setup:
+ right(1)
+ jump(def: L·Write_EOR_Done)
+
+ L·Setup_Write:
+ right(1)
+ left(0)
+ jump(def: L·Copy_Read)
+
+ # Phase 3: The Linear Copy Loop
+ L·Copy_Read:
+ read('d' ,0)
+ status(0)
+ jump(s, {leftmost: L·Copy_Last, def: L·Copy_Loop})
+
+ L·Copy_Loop:
+ write('σ' ,0 ,SP)
+ write('d' ,1)
+ right(1)
+ left(0)
+ jump(def: L·Copy_Read)
+
+ # Phase 4: Final character, advance, and clean halt
+ L·Copy_Last:
+ write('σ' ,0 ,SP)
+ write('d' ,1)
+ right(1)
+ jump(def: L·Write_EOR_Done)
+
+ L·Write_EOR_Done:
+ write('σ' ,1 ,EOR)
+ halt
+ </RT·code>
+
+ <p>The state labels have become addresses into the program tape, and the address of the cell indicated by the head on the first tape is now an Instruction Pointer (IP). In a sense the programmed controller has been replaced by a little Turing Machine of its own. One that controls the head on the first tape, and moves it in response to the control instructions found on the first tape. Such a controller on a processor is called a <RT-term>sequencer</RT-term>.</p>
-<!-- CPCU -> PCU -->
+ <p>By separating the control path from the data path, utilizing an integrated symbol alphabet, replacing states with sequential instructions, and introducing an explicit addressable instruction pointer, the theoretical machine has physically crossed the bridge to conventional computing. The resulting architecture is a stored-program, von Neumann-style machine organization.</p>
+ <p>Some of the default cases for the jump table unnecessarily jump to the instruction at the next sequential address. This code lacks the regularity to use a computed jump table, so this style of jump table becomes a Lisp <RT·code>cond</RT·code> statement, i.e. sequential conditional tests. So then by using the instructions <RT·code>test</RT·code>, <RT·code>beq</RT·code> (for branch on equal), and <RT·code>jump</RT·code> as control instructions, and rearranging to favor sequential execution, this code becomes:</p>
+
+ <RT·code>
+ # Phase 1: Both heads scan right to the EOM pivot
+ L·initial:
+ read('s' ,0)
+ test('s' ,EOM)
+ beq L·Check_Empty
+
+ # L·Scan_Right (Implicit fall-through)
+ right(0)
+ right(1)
+ jump L·initial
+
+ # Phase 2: Setup pointers or short-circuit on empty string
+ L·Check_Empty:
+ status(0)
+ test('s' ,leftmost)
+ beq L·Empty_Setup
+
+ # L·Setup_Write (Implicit fall-through)
+ right(1)
+ left(0)
+
+ # Phase 3: The Linear Copy Loop
+ L·Copy_Read:
+ read('d' ,0)
+ status(0)
+ test('s' ,leftmost)
+ beq L·Copy_Last
+
+ # L·Copy_Loop (Implicit fall-through)
+ write('σ' ,0 ,SP)
+ write('d' ,1)
+ right(1)
+ left(0)
+ jump L·Copy_Read
+
+ # Phase 4: Final character, advance, and clean halt
+ L·Copy_Last:
+ write('σ' ,0 ,SP)
+ write('d' ,1)
+
+ L·Empty_Setup:
+ right(1)
+
+ # L·Write_EOR_Done (Implicit fall-through)
+ write('σ' ,1 ,EOR)
+ halt
+ </RT·code>
+ <p>This is an assembly-level code description of an instruction sequence. To get it into final form, the labels that appear as instruction arguments would be replaced with their addresses. Symbolic labels would not appear on the tape. As an alternative to using absolute branches, relative branches could be used. Performance will be greatly enhanced for a sequencer that performs relative branching if it contains an adder circuit; otherwise, the addition of offsets would be another TTCA program invocation.</p>
<!--------------------------------------------------------------------------------->
<RT·chapter>Software</RT·chapter>
projects / TM-2026 / commitdiff