<p>
At a conference in Paris in 1900, David Hilbert presented a list of pressing unsolved problems in mathematics.
- Second on his list was "The Compatibility of the Arithmetical Axioms." Hilbert challenged mathematicians to find a means to demonstrate that "a finite number of logical steps based upon them [axioms] can never lead to contradictory results" <RT·endnote>F. N. Cole et al., eds., <em>Bulletin of the American Mathematical Society</em>, Vol. 8 (New York: Macmillan, 1902). This can be found at https://www.gutenberg.org/cache/epub/71655/pg71655 images.html. The MathWorld article on this subject, https://mathworld.wolfram.com/HilbertsProblems.html, explains that Hilbert presented 10 problems at the conference, though the publication shows 23 problems, and shortly later a 24th problem was added. Based on the notes of this citation, it appears the second problem is the same on all of these lists. Also note, Hilbert discusses <em>completeness</em> specifically as an axiom for bounding on the sets, which appears to be distinct from the question of logical completeness for an axiomatic system.</RT·endnote>.
+ Second on his list was "The Compatibility of the Arithmetical Axioms." Hilbert challenged mathematicians to find a means to demonstrate that "a finite number of logical steps based upon them [axioms] can never lead to contradictory results" <RT·endnote>F. N. Cole et al., eds., <em>Bulletin of the American Mathematical Society</em>, Vol. 8 (New York: Macmillan, 1902). This can be found at https://www.gutenberg.org/cache/epub/71655/pg71655-images.html. The MathWorld article on this subject, https://mathworld.wolfram.com/HilbertsProblems.html, explains that Hilbert presented 10 problems at the conference, though the publication shows 23 problems, and shortly later a 24th problem was added. Based on the notes of this citation, it appears the second problem is the same on all of these lists. Also note, Hilbert discusses <em>completeness</em> specifically as an axiom for bounding on the sets, which appears to be distinct from the question of logical completeness for an axiomatic system.</RT·endnote>.
</p>
<p>
<RT·chapter>The Turing Machine transforms mathematics into computing</RT·chapter>
<p>
- To apply his proof to the Entscheidungsproblem, Turing carried the additional burden of establishing that Hilbert and Ackermann's intuitive concept of an effective <RT·term em>procedure</RT·term em> was functionally equivalent to a Turing Machine program. Turing addressed this issue directly in his 1936 paper. Over the following decades, the academic community evaluated and accepted his argument, cementing what is now known as the Church Turing Thesis. This consensus supplied the necessary bridge between mathematics and modern computer science by formally equating the vague, historical notion of a human procedure with the rigorous, mechanical definition of an <RT·term>algorithm</RT·term>.
+ To apply his proof to the Entscheidungsproblem, Turing carried the additional burden of establishing that Hilbert and Ackermann's intuitive concept of an effective <RT·term>procedure</RT·term> was functionally equivalent to a Turing Machine program. Turing addressed this issue directly in his 1936 paper. Over the following decades, the academic community evaluated and accepted his argument, cementing what is now known as the Church Turing Thesis. This consensus supplied the necessary bridge between mathematics and modern computer science by formally equating the vague, historical notion of a human procedure with the rigorous, mechanical definition of an <RT·term>algorithm</RT·term>.
</p>
<p>
</p>
<p>
- An <RT·term em>architecture</RT·term em> provides programmers with information that is valuable when designing the logic of programs. This includes programmers across the entire software stack, such as firmware engineers, driver developers, systems programmers, compiler writers, and application developers. Although applications programs might only be exposed to the <RT·term>virtual architecture</RT·term> presented by various standards, various libraries, and the programming language used. In addition to specifying the instructions (instruction set architecture), <RT·term em>architecture</RT·term em> includes describing the memory and hardware virtualization features, specifying the behavior of the interrupt subsystem, the method of doing I/O, DMA, the special registers and their effects, any architectural busses, and the standards to be followed for each if any. More recently, this also includes specifying how programs can make use of secure areas. The architecture is specified by an <RT·term>architect</RT·term>.
+ An <RT·term>architecture</RT·term> provides programmers with information that is valuable when designing the logic of programs. This includes programmers across the entire software stack, such as firmware engineers, driver developers, systems programmers, compiler writers, and application developers. Although applications programs might only be exposed to the <RT·term>virtual architecture</RT·term> presented by various standards, various libraries, and the programming language used. In addition to specifying the instructions (instruction set architecture), <RT·term>architecture</RT·term> includes describing the memory and hardware virtualization features, specifying the behavior of the interrupt subsystem, the method of doing I/O, DMA, the special registers and their effects, any architectural busses, and the standards to be followed for each if any. More recently, this also includes specifying how programs can make use of secure areas. The architecture is specified by an <RT·term>architect</RT·term>.
</p>
<p>
The classic text by Hamacher, Vranesic, and Zaky carefully defines the organizational level as sitting between architecture and implementation <RT·endnote>V. Carl Hamacher, Zvonko G. Vranesic, and Safwat G. Zaky, <em>Computer Organization</em>, 5th ed. (New York: McGraw Hill, 2002).</RT·endnote>.
- <RT·term em>Organization</RT·term em> is the register transfer level description of the machine, which includes internal buses, external buses and the state machines that implement the protocols used, control units, interrupt structures, and ALU layout. Crucially, it is at this level that decisions regarding instruction level parallelism are made, such as whether the processor will employ a scalar, superscalar, or VLIW design, the depth of its execution pipelines, the use of out of order execution, branch prediction strategies, and the specific hierarchy of hardware caches. It dictates the logical arrangement of hardware and the procedures that force the data to flow to satisfy the architectural constraints. <RT·term>Organization</RT·term> is sometimes called <RT·term>micro architecture</RT·term>, and it is made by a <RT·term>design architect</RT·term>.
+ <RT·term>Organization</RT·term> is the register transfer level description of the machine, which includes internal buses, external buses and the state machines that implement the protocols used, control units, interrupt structures, and ALU layout. Crucially, it is at this level that decisions regarding instruction level parallelism are made, such as whether the processor will employ a scalar, superscalar, or VLIW design, the depth of its execution pipelines, the use of out of order execution, branch prediction strategies, and the specific hierarchy of hardware caches. It dictates the logical arrangement of hardware and the procedures that force the data to flow to satisfy the architectural constraints. <RT·term>Organization</RT·term> is sometimes called <RT·term>micro architecture</RT·term>, and it is made by a <RT·term>design architect</RT·term>.
</p>
<p>
</p>
<p>
- The <RT·term em>implementation</RT·term em> instructs the manufacturing teams very specifically on what is to be built. For a microprocessor chip, this consists of the full wiring of the logic gates and transistors, instructions for cutting the lithography masks, the package to be used, and the production test programs to be run. The instructions for cutting the masks consist of the sizes and placement of doping wells and gates, the placement of contacts, and where to run wires. The implementation is designed by <RT·term>design engineers</RT·term>, with the assistance of design synthesis tools and CAD tools.
+ The <RT·term>implementation</RT·term> instructs the manufacturing teams very specifically on what is to be built. For a microprocessor chip, this consists of the full wiring of the logic gates and transistors, instructions for cutting the lithography masks, the package to be used, and the production test programs to be run. The instructions for cutting the masks consist of the sizes and placement of doping wells and gates, the placement of contacts, and where to run wires. The implementation is designed by <RT·term>design engineers</RT·term>, with the assistance of design synthesis tools and CAD tools.
</p>
<p>
- A <RT·term em>realization</RT·term em> is a physical box full of plastic, metal, fiberglass, and silicon, along with a smattering of exotic materials. A realization is made by <RT·term>manufacturing engineers, technicians, and product line workers</RT·term>, with the assistance of some of the most sophisticated machines ever built by humankind.
+ A <RT·term>realization</RT·term> is a physical box full of plastic, metal, fiberglass, and silicon, along with a smattering of exotic materials. A realization is made by <RT·term>manufacturing engineers, technicians, and product line workers</RT·term>, with the assistance of some of the most sophisticated machines ever built by humankind.
</p>
<p>
</p>
<p>
- When a transform applied to machine <RT·math>m_i</RT·math> produces machine <RT·math>m_{i.1}</RT·math>, and this latter machine gets the same results for the same computational inputs, and furthermore, if any computation theory analysis applied to <RT·math>m_{i.1}</RT·math> yields the same answer as it would when applied to <RT·math>m_i</RT·math> — we say that the transform is <RT·neologism em>computation theoretic inconsequential</RT·neologism em>. Otherwise, the transformation is said to be <RT·neologism em>computation theoretic consequential</RT·neologism em>. The remainder of this section defines these terms more precisely.
+ When a transform applied to machine <RT·math>m_i</RT·math> produces machine <RT·math>m_{i.1}</RT·math>, and this latter machine gets the same results for the same computational inputs, and furthermore, if any computation theory analysis applied to <RT·math>m_{i.1}</RT·math> yields the same answer as it would when applied to <RT·math>m_i</RT·math> — we say that the transform is <RT·neologism>computation theoretic inconsequential</RT·neologism>. Otherwise, the transformation is said to be <RT·neologism>computation theoretic consequential</RT·neologism>. The remainder of this section defines these terms more precisely.
</p>
<h2>Definition of the same results transform property</h2>
</RT·math>
<p>
- We can then assign a property to transform <RT·math>T</RT·math> called its <RT·neologism em>doesn't change results</RT·neologism em> property, as follows. If and only if:
+ We can then assign a property to transform <RT·math>T</RT·math> called its <RT·neologism>doesn't change results</RT·neologism> property, as follows. If and only if:
</p>
<RT·math>
</RT·math>
<p>
- then <RT·math>T</RT·math> is <RT·neologism em>computation theoretic inconsequential for <RT·math>m_i</RT·math></RT·neologism em>.
+ then <RT·math>T</RT·math> is <RT·neologism>computation theoretic inconsequential for <RT·math>m_i</RT·math></RT·neologism>.
</p>
<p>
</RT·math>
<p>
- then we can say without qualification that <RT·math>T</RT·math> is <RT·neologism em>computation theoretic inconsequential</RT·neologism em>. Though still implied are the sets of machines and tapes.
+ then we can say without qualification that <RT·math>T</RT·math> is <RT·neologism>computation theoretic inconsequential</RT·neologism>. Though still implied are the sets of machines and tapes.
</p>
<RT·chapter>The computation theoretic Turing Machine</RT·chapter>
<p>While using the standard library to write tapes, the uninitialized part of the tape could not be read until after it was written, so early tape machines indeed enforced the "read only after write" rule. However, if the programmer were to seek the head back into the device file to do fresh work and perform reads and writes, the device EOF would be nowhere in sight. The burden of the "read only after write" rule would then fall on the shoulders of the programmer, as would the task of structuring the data.</p>
- <p>Core memory, and later system memory, was random access and initially fully accessible. The data would be whatever scrambled mess the machine booted with, or in early virtual memory systems, whatever was left over from the prior use of the page. The approach of recycling pages was a security hazard, so today a page is initially allocated from a read-only zero page, and due to a copy-on-write trap, a new page will be created in memory then the original page copied to it, thus scrubbing it with zeros. If the computational Turing Machine's empty symbol maps to a word of zeros, then the empty symbol remains a poor model, because generally the data message, say sent between the <em>input</em> writer and the <em>recognizer</em> receiver, will also contain many zeros. The advantage is that if a programmer attempts to dereference a zero pointer, a segmentation fault occurs. So in this system, the programmer is again burdened with maintaining the "read only after write" rule.</p>
+ <p>Core memory, and later system memory, was random access and initially fully accessible. The data would be whatever scrambled mess the machine booted with, or in early virtual memory systems, whatever was left over from the prior use of the page. The approach of recycling pages was a security hazard, so today a page is initially allocated from a read-only zero page, and due to a copy-on-write trap, a new page will be created in memory then the original page copied to it, thus scrubbing it with zeros. For pointers the zero pointer is an a sense an empty symbol, and an attempt to dereference it will cause a fault. However, on real machines, there are many integer values used, and these can also be zero. Thus the zeros of the new page are not identical to saying the page contains all empty symbols. In this system, the programmer is again burdened with maintaining the "read only after write" rule. Compilers and interpreters will attempt to help with this by throwing errors upon the use of uninitialized data that they detect.</p>
<p>A violation of "read only after write" could be detected by a modified computation theoretic Turing Machine if, instead of an empty symbol, the initial tape is filled with the <RT·code>unspecified</RT·code> symbol. The end objective is to detect an erroneous condition, which is useful for debugging and testing. Conventionally, mathematicians do not concern themselves with the test and debug phases of programming a Turing Machine, but rather concern themselves with answering computation theoretic questions about known working Turing Machine programs. Though perhaps an algorithm could be studied for this very quality of not ever making decisions based on unspecified data. Nor do real machines have an <RT·code>unspecified</RT·code> symbol; rather, a program reads garbage from memory locations with unspecified data. There is precedent for an <RT·code>x</RT·code>, <em>unknown</em>, logic state in hardware simulators.</p>
<p>An example of effectively unspecified data would be a program that reverses a string without looking at the values being reversed. A string reverse function need not inspect the value of the string; it only needs to recognize the structural boundaries established by the writing protocol. Yet the conventional Turing Machine is incapable of doing this, and worse, as we saw, there is a proportional increase in the number of states for the reverse string controller when the number of symbols, symbols that could have been ignored for control purposes, is expanded.</p>
- <h2>The computation theoretic TTCA Machine</h2>
+ <p>Recall the suggestion earlier in this section that "perhaps an algorithm could be studied for this very quality of not ever making decisions based on unspecified data." In this capacity, the <RT·code>unspecified</RT·code> symbol functions as a <RT·term>test probe</RT·term>. Such an analysis can be done with a two-layer architecture: a first-order machine under study and a second-order machine performing the analysis. The <RT·code>unspecified</RT·code> symbol resides within the alphabet of the second-order machine, which possesses the authority not only to move the symbol but also to base logic upon it. However, demoting the <RT·code>unspecified</RT·code> marker from a meta-symbol to a standard decision symbol leaves the second-order machine without a meta-symbol of its own. In a strictly layered architecture, analogous to Russell and Whitehead's hierarchy of types, a programmer could define <RT·code>unspecified-0</RT·code>, <RT·code>unspecified-1</RT·code>, and so forth, explicitly embedding the order as a unique identifier. However, if the system lacks this strict stratification, the layering strategy collapses. This occurs when a statement operates as an independent island of meaning, analogous to Gödel's unprovable truths, or when an analyzer is tasked with evaluating itself, as in Turing's halting proof. Therefore, whether an <RT·code>unspecified</RT·code> meta-symbol can be deployed successfully depends entirely upon the structural boundaries of the specific system under test.</p>
- <p>A goal of the computation theorist in defining a Turing Machine is to make the math concise and elegant. However, the goal of the computer architect is to define a machine that is intuitive to design and test, and that performs well. Perhaps if a computer architect were to define the computation theoretic Turing Machine, this change in emphasis would favor a different definition.</p>
+<h2>The computation theoretic TTCA Machine</h2>
- <p>The following modifications will be made to the computation theoretic Turing Machine definition so as to support the <RT·code>unspecified</RT·code> symbol:</p>
+ <p>This section presents a modified computation theoretic Turing Machine with three structural additions. First, it separates control flow from data flow, ensuring that payload symbols do not needlessly expand the control state machine. Second, it unifies the control and data symbol sets into a single alphabet to natively support explicit communications protocols even in the presence of recursion and self-recursion. Finally, it implements a cascading next-state evaluation hierarchy, permitting the programmer to formally define and handle meta-symbols such as <RT·code>unspecified</RT·code>, and to more conveniently code communication protocols.</p>
+
+ <p>The specific architectural modifications are as follows:</p>
<ol>
- <li>Move to a Moore style programmed state controller, so that actions can be managed separately from state transitions.</li>
- <li>Introduce explicit actions for reading: a state transition gating read (<RT·code>read_g</RT·code>) and a data read (<RT·code>read_d</RT·code>), which target their respective dedicated registers. Additionally, provide a <RT·code>status</RT·code> action that also targets the <RT·code>g</RT·code> register.</li>
- <li>To match the read functions, the write actions can specify writing a constant symbol (<RT·code>write_σ</RT·code>), or the contents of either the data or gate register (<RT·code>write_d</RT·code>, <RT·code>write_g</RT·code>).</li>
- <li>If the <RT·code>unspecified</RT·code> symbol is read into the state transition gating register, the machine transitions to the predefined <RT·code>unspecified_decision</RT·code> state.</li>
+ <li>There is one unified alphabet <RT·math>\Sigma</RT·math> to which both status symbols and data symbols belong.</li>
+ <li>It utilizes a Moore-style programmed state controller, so that actions can be managed separately from state transitions.</li>
+ <li>It separates control flow from data flow:
+ <ol>
+ <li>Two registers exist within the machine: one for holding a symbol upon which control decisions are made, the <RT·code>s</RT·code> (status) register; and one for holding data upon which decisions are not based, the <RT·code>d</RT·code> (data) register. Here, <RT·code>s</RT·code> stands for 'status', as its value is a condition flag utilized by the programmed controller when determining the next state, while <RT·code>d</RT·code> stands for 'data'.</li>
+ <li>Read and write actions accept an operand designating the target or source register respectively, either <RT·code>s</RT·code> or <RT·code>d</RT·code>.</li>
+ </ol>
+ </li>
+ <li>It implements default state transitions that execute when no explicit transition is given in the main state transition table of triples (each triple being <RT·math>\langle S_i, \sigma, S_{i+1} \rangle</RT·math>):
+ <ol>
+ <li>state-specific transition default pairs, which have the form <RT·math>\langle S_i, S_{i+1} \rangle</RT·math></li>
+ <li>status-specific transition default pairs, which have the form <RT·math>\langle \sigma, S_{i+1} \rangle</RT·math></li>
+ <li>a global default transition, which has the form <RT·math>S_{i+1}</RT·math></li>
+ </ol>
+ </li>
</ol>
- <p>For ease of programming, the new machine evaluates next-state transitions through a four-layer hierarchy:</p>
+ <p>The new machine evaluates next-state transitions through these four layers, in order, progressing to the next layer only when no transition is found in the prior layer:</p>
<ol>
- <li><strong>Fixed global default (<RT·math>δF_0</RT·math>):</strong> Selects the rule that matches the value in the gate register. There is only one rule in this set; it compares the gate register to the <RT·code>unspecified</RT·code> symbol, then transitions to the <RT·code>unspecified_decision</RT·code> state.</li>
- <li><strong>Programmed Conditional (<RT·math>δ_1</RT·math>):</strong> Selects the transition rule that matches the current state and the value of the gate register.</li>
- <li><strong>Programmed Default (<RT·math>δ_2</RT·math>):</strong> If no conditional next state rule is found, selects the default transition rule that matches the current state.</li>
- <li><strong>Global Fallback (<RT·math>δ_3</RT·math>):</strong> An unconditional transition of last resort if no prior layer provides a valid next state.</li>
+ <li><strong>Conditional (<RT·math>\delta_0</RT·math>):</strong> Selects the transition rule that matches the current state and the value of the status register.</li>
+ <li><strong>State Default (<RT·math>\delta_1</RT·math>):</strong> If no conditional next state rule is found, selects the default transition rule that matches the current state.</li>
+ <li><strong>Status Default (<RT·math>\delta_2</RT·math>):</strong> If no next state rule has been found, selects the default transition rule that matches the current machine status.</li>
+ <li><strong>Global Default (<RT·math>\delta_3</RT·math>):</strong> An unconditional transition of last resort if no prior layer provides a valid next state.</li>
</ol>
+
+ <p>Programmers will typically use the Global Default arc, <RT·math>\delta_3</RT·math>, to take the machine to an error state when they have mistakenly left the next state transition undefined. However, it is conceivable for some machines that if no other next state is defined, there is a single logical state that should be visited, and this condition is not an error. If no Global Default arc is specified, and no next state is found, the machine hangs.</p>
- <p>For clarity of presentation, the definition will be partitioned according to separation of concerns. The first section defines the fixed parts of the Turing Machine definition. The second section defines the memory elements (variables). The third section describes the programmable components, which vary between specific Turing Machines depending on their purposes.</p>
+ <p>This approach of cascading next state decisions does more than merely make the machine more convenient to program; it also enables a programmer to support an <RT·code>unspecified</RT·code> symbol. For example, a programmer can incorporate a first-order <RT·code>unspecified</RT·code> symbol by first adding it to the alphabet <RT·math>\Sigma</RT·math>, adding a <RT·code>Q_unspecified</RT·code> state to <RT·math>Q</RT·math>, and then adding a status default arc to <RT·math>\delta_2</RT·math> of <RT·math>\langle \mathtt{unspecified}, \mathrm{Q\_unspecified} \rangle</RT·math>. Then, if the machine attempts to make a decision upon the <RT·code>unspecified</RT·code> symbol, the machine will go to the <RT·code>Q_unspecified</RT·code> state. Such a machine can then be analyzed to see if it ever visits the <RT·code>Q_unspecified</RT·code> state.</p>
+
+ <p>The formal definition that follows will be partitioned according to the <em>separation of concerns</em>. The first section defines the fixed parts of the Turing Machine definition. The second section defines the memory elements (variables). The third section describes the programmable components, which vary between specific Turing Machines depending on their purposes.</p>
<p>There is a mechanical procedure for converting a Moore Machine into a Mealy Machine, and the reverse. Two such converted machines are equally expressive. Making the read operation an explicit action, instead of having it implied by a state transition, increases the number of states in a controller, and consequently the number of steps that must be taken. However, the new machine can do in two steps anything the former machine could do in one; consequently, this change affects the multiplier constant on the linear term of the step count formula but does not change the computation complexity class determined from such a step count. The layers of next-state functions can be collapsed into one layer, where the missing arguments are filled in with all possible unused values. This potentially increases the number of state transition arcs that must be specified, but the state transition logic and the number of states remain unchanged. Partitioning the machine definition by separation of concerns does not change the total specification. Hence, these modifications are computation theoretic inconsequential.</p>
<h3>The TTCA Machine fixed part</h3>
<div style="margin-left: 2em;">
- <RT·math>
- MF = (QF, ΣF, AF, δF_0, HF)
- </RT·math>
+ <RT·math> \mathrm{MF} = (\mathrm{QF}, \mathrm{\Sigma F}, \mathrm{AF}) </RT·math>
</div>
- <p>In the following the middle dot acts as a namespace operator, <RT·math>N{·}x</RT·math>. By doing this we assure there will be no aliasing with the symbols provided by the programmer when he defines the programmed state controller.</p>
+ <p>In the following, the middle dot acts as a namespace operator, <RT·math>N{\cdot}x</RT·math>. By doing this we assure there will be no aliasing with the symbols provided by the programmer when defining the programmed state controller.</p>
<p>The set of predefined <em>states</em>:</p>
<div style="margin-left: 2em;">
- <RT·math>QF = \{QF{·}\mathtt{initial}, QF{·}\mathtt{unspecified\_decision}\}</RT·math>
+ <RT·math>\mathrm{QF} = \{\mathrm{QF}{\cdot}\mathtt{initial}\}</RT·math>
</div>
- <p>The state controller always starts in the <RT·code>QF·initial</RT·code> state. This is a symbol representing the state, it is not a register that holds a state. The 'F' values are all fixed.</p>
-
- <p>If a decision is attempted to be made on an <RT·code>ΣF·unspecified</RT·code> symbol, the machine transitions to the <RT·code>QF·unspecified_decision</RT·code> state, due to the global default transition defined in <RT·math>δF_0</RT·math>.</p>
+ <p>The state controller always starts in the <RT·code>QF·initial</RT·code> state. This is a symbol representing the state; it is not a register that holds a state. The 'F' values are all fixed.</p>
- <p>The set of available actions:</p>
+ <p>The programmer cannot add actions to the machine definition, so there are only fixed actions:</p>
<div style="margin-left: 2em;">
<RT·math>
\begin{aligned}
- AF = \{\\
+ \mathrm{AF} = \{& \\
& \mathtt{no\_op} \\
, & \mathtt{left} \\
, & \mathtt{right} \\
- , & \mathtt{read\_d} \\
- , & \mathtt{read\_g} \\
+ , & \mathtt{read}(\mathtt{d} \mid \mathtt{s}) \\
, & \mathtt{status} \\
- , & \mathtt{write\_σ}(σ) \\
- , & \mathtt{write\_d} \\
- , & \mathtt{write\_g} \\
+ , & \mathtt{write}(\mathtt{d} \mid \mathtt{s} \mid \mathtt{\sigma}, [\sigma]) \\
\}
\end{aligned}
</RT·math>
</div>
- <p>where <RT·math>σ</RT·math> must be in <RT·math>Σ</RT·math>.</p>
+ <p>where <RT·math>\sigma</RT·math> must be in <RT·math>\Sigma</RT·math>.</p>
<p>The set of predefined symbols:</p>
<div style="margin-left: 2em;">
- <RT·math>ΣF = \{ΣF{·}\mathtt{unspecified}, ΣF{·}\mathtt{on\_leftmost}\}</RT·math>
- </div>
-
- <p>The set <RT·math>δF_0</RT·math> holds one global default predefined transition of the form,
- <div style="margin-left: 2em;">
- <RT·math>
- \{\langle \mathtt{g{.}ΣF{·}unspecified}, \mathtt{QF{·}unspecified\_decision} \rangle\}
- </RT·math>
- </div>
-
- <p>In any state if the <RT·code>g</RT·code> register holds the symbol <RT·math>\mathtt{ΣF{·}unspecified}</RT·math>, then the next state will be <RT·math>\mathtt{QF{·}unspecified\_decision}</RT·math>, independent of all other defined next state transitions.</p>
-
- <p>The set of predefined halting states (only one):</p>
- <div style="margin-left: 2em;">
- <RT·math>HF = \{QF{·}\mathtt{unspecified\_decision}\}</RT·math>
+ <RT·math>\mathrm{\Sigma F} = \{\mathrm{\Sigma F}{\cdot}\mathtt{on\_leftmost}\}</RT·math>
</div>
<h3>The TTCA Machine variables</h3>
<div style="margin-left: 2em;">
<RT·math>
- MV = (q, d, g)
+ \mathrm{MV} = (q, d, s)
</RT·math>
</div>
<p><RT·code>d</RT·code>: is the data register.</p>
- <p><RT·code>g</RT·code>: is the gate register.</p>
+ <p><RT·code>s</RT·code>: is the status register.</p>
<h3>The TTCA Machine programmable part</h3>
<div style="margin-left: 2em;">
<RT·math>
- MP = (QP, ΣP, λP, δ_1, δ_2, δ_3, HP)
+ \mathrm{MP} = (\mathrm{QP}, \mathrm{\Sigma P}, \lambda\mathrm{P}, \delta_0, \delta_1, \delta_2, \delta_3, \mathrm{HP})
</RT·math>
</div>
<p>A set of programmed <em>state</em> symbols:</p>
<div style="margin-left: 2em;">
- <RT·math>QP</RT·math>
+ <RT·math>\mathrm{QP}</RT·math>
</div>
<p>A set of programmed data symbols:</p>
<div style="margin-left: 2em;">
- <RT·math>ΣP</RT·math>
+ <RT·math>\mathrm{\Sigma P}</RT·math>
</div>
<p>The programmed actions. A set of pairs of the form:</p>
<div style="margin-left: 2em;">
- <RT·math>λP = \{ \langle q_0, a \rangle, \dots \}</RT·math>
+ <RT·math>\lambda\mathrm{P} = \{ \langle q_0, a \rangle, \dots \}</RT·math>
</div>
- <p>where <RT·math>q_0</RT·math> is matched to the current state, and <RT·math>a</RT·math> is a member of <RT·math>AF</RT·math>.</p>
+ <p>where <RT·math>q_0</RT·math> is matched to the current state, and <RT·math>a</RT·math> is a member of <RT·math>\mathrm{AF}</RT·math>.</p>
- <p>A set of state transition triples; each triple is of the form:</p>
+ <p>The conditional transition table. A set of state transition triples; each triple is of the form:</p>
<div style="margin-left: 2em;">
- <RT·math>δ_1 = \{ \langle q_0, r{·}σ, q_1 \rangle, \dots \}</RT·math>
+ <RT·math>\delta_0 = \{ \langle q_0, r{\cdot}\sigma, q_1 \rangle, \dots \}</RT·math>
</div>
- <p>where <RT·math>q_0</RT·math> is matched to the current state of the machine. <RT·math>r{·}σ</RT·math> is a symbol in register <RT·math>r</RT·math>, where <RT·math>r</RT·math> is either <RT·code>d</RT·code> or <RT·code>g</RT·code>. <RT·math>q_1</RT·math> is the next state. When <RT·math>q_0</RT·math> matches the current state, <RT·math>q_1</RT·math> becomes the next state. Both <RT·math>q_0</RT·math> and <RT·math>q_1</RT·math> come from the total set <RT·math>Q</RT·math>. <RT·math>σ</RT·math> comes from the total set <RT·math>Σ</RT·math>. </p>
+ <p>where <RT·math>q_0</RT·math> is matched to the current state of the machine. <RT·math>r{\cdot}\sigma</RT·math> is a symbol in register <RT·math>r</RT·math>, where <RT·math>r</RT·math> is either <RT·code>d</RT·code> or <RT·code>s</RT·code>. <RT·math>q_1</RT·math> is the next state. When <RT·math>q_0</RT·math> matches the current state and the specified register holds <RT·math>\sigma</RT·math>, <RT·math>q_1</RT·math> becomes the next state. Both <RT·math>q_0</RT·math> and <RT·math>q_1</RT·math> come from the total set <RT·math>Q</RT·math>. <RT·math>\sigma</RT·math> comes from the total set <RT·math>\Sigma</RT·math>.</p>
- <p>The default transition table. A set of state transition pairs; each pair is of the form:</p>
+ <p>The state default transition table. A set of state transition pairs; each pair is of the form:</p>
<div style="margin-left: 2em;">
- <RT·math>δ_2 = \{ \langle q_0, q_1 \rangle, \dots \}</RT·math>
+ <RT·math>\delta_1 = \{ \langle q_0, q_1 \rangle, \dots \}</RT·math>
</div>
<p>where <RT·math>q_0</RT·math> is matched to the current state, and upon a match <RT·math>q_1</RT·math> will be taken as the next state.</p>
- <p>A default next state:</p>
+ <p>The status default transition table. A set of state transition pairs; each pair is of the form:</p>
<div style="margin-left: 2em;">
- <RT·math>δ_3 = q_1</RT·math>
+ <RT·math>\delta_2 = \{ \langle r{\cdot}\sigma, q_1 \rangle, \dots \}</RT·math>
</div>
+ <p>where <RT·math>r{\cdot}\sigma</RT·math> matches the symbol in register <RT·math>r</RT·math> (either <RT·code>d</RT·code> or <RT·code>s</RT·code>), and upon a match <RT·math>q_1</RT·math> will be taken as the next state.</p>
- <p>This is the transition of last resort. It is unconditional, the next state becomes <RT·math>q_1</RT·math>.</p>
+ <p>The global default next state:</p>
+ <div style="margin-left: 2em;">
+ <RT·math>\delta_3 = q_1</RT·math>
+ </div>
+ <p>This is the transition of last resort. It is unconditional; the next state becomes <RT·math>q_1</RT·math>.</p>
- <p>A set of programmer defined halting states:</p>
+ <p>A set of programmer-defined halting states:</p>
<div style="margin-left: 2em;">
- <RT·math>HP</RT·math>
+ <RT·math>\mathrm{HP}</RT·math>
</div>
<div style="margin-left: 2em;">
<RT·math>
- M = (Q, Σ, AF, λP, δ, H)
+ M = (Q, \Sigma, \mathrm{AF}, \lambda\mathrm{P}, \delta, H)
</RT·math>
</div>
<p>The complete set of states, uniting the fixed predefined states and the programmed states:</p>
<div style="margin-left: 2em;">
- <RT·math>Q = QF \cup QP</RT·math>
+ <RT·math>Q = \mathrm{QF} \cup \mathrm{QP}</RT·math>
</div>
<p>The complete set of symbols, uniting the fixed control symbols and the programmed data symbols:</p>
<div style="margin-left: 2em;">
- <RT·math>Σ = ΣF \cup ΣP</RT·math>
+ <RT·math>\Sigma = \mathrm{\Sigma F} \cup \mathrm{\Sigma P}</RT·math>
</div>
<p>The ordered sequence of next state transition rules:</p>
<div style="margin-left: 2em;">
- <RT·math>δ = [δF_0 | δ_1 | δ_2 | δ_3]</RT·math>
+ <RT·math>\delta = [\delta_0 \mid \delta_1 \mid \delta_2 \mid \delta_3]</RT·math>
</div>
<p>The complete set of halting states, uniting the fixed predefined states and the programmed states:</p>
<div style="margin-left: 2em;">
- <RT·math>H = HF \cup HP</RT·math>
+ <RT·math>H = \mathrm{HF} \cup \mathrm{HP}</RT·math>
</div>
-
<h2>Computation theoretic TTCA Machine executor</h2>
<p>To execute the programmed TTCA Machine, a person must maintain the current machine variables <RT·math>MV</RT·math> and evaluate the programmed logic in an repeating two-phase cycle, until a halting state is reached. Because this is a Moore-style architecture, the execution of an action is isolated from the evaluation of the next state transition.</p>
<RT·code>
# TTCA Machine String Reverse
- # input: (σ ∈ Σ)* EOM (starting on the leftmost cell)
- # output: SP* EOM (σ ∈ Σ in reverse)* EOR
+ # Domains:
+ # ΣP = {0, 1, EOM, EOR, SP}
+ # Σ_data = ΣP \ {EOM, EOR, SP}
+ # input: (σ ∈ Σ_data)* EOM (starting on the leftmost cell)
+ # output: SP* EOM (σ ∈ Σ_data in reverse)* EOR
halt: Q·Done
<p>Suppose a controller is not analyzed to determine its computation theoretic complexity, or even tested against worst-case inputs, but is instead run with random or everyday input to gather performance measurements. This process is called <RT·term>profiling</RT·term>. After many runs, a programmer might surmise the behavioral limits of the program. However, many programs are neither linear systems nor smooth functions. With a different set of inputs than those used for profiling, perhaps even values adjacent to prior inputs, the program behavior can shift drastically. Consider the Pentium divider. It did not matter how many millions of times the result was accurate; the fact remains that customers later found an input that yielded wildly inaccurate results. Only by elevating the analysis to the structural logic of the code can such an eventuality from an erroneous program be categorically ruled out. <RT·endnote>This is why the K5 transcendental function development project included a proof writing phase; see Thomas Walker Lynch, A. Ahmed, M. Schulte, T. Callaway, and R. Tisdale, "The K5 Transcendental Functions," <em>Proceedings of the 12th IEEE Symposium on Computer Arithmetic</em>, 1995. DOI: 10.1109/ARITH.1995.465368.</RT·endnote></p>
- <h2>Head unit, <RT·code>HU</RT·code></h2>
+ <h2>Head Unit, <RT·code>HU</RT·code></h2>
<p>An <RT·code>HU</RT·code> contains a head and a local controller. The local controller supports these commands:</p>
<li><RT·code>status</RT·code> → γ</li>
</ol>
- <p>One or more head units are plugged into the <RT·code>TTU</RT·code>, which is described in the next section. The <RT·code>TTU</RT·code> only sends commands when a tape is mounted.</p>
-
- <p>On this model of machine, the <RT·code>HU</RT·code> status is identical to the cell type. The cell type does not come from the tape, so the <RT·code>HU</RT·code> must work in conjunction with the <RT·code>TTU</RT·code> to derive its value. In review the cell types are:</p>
+ <p>On this model of machine, the <RT·code>HU</RT·code> status is identical to the indicated cell's type. The cell type is not read from the tape; rather, it is derived from the head's physical relationship to the ends of the tape. Consequently, the <RT·code>HU</RT·code> works in conjunction with the <RT·code>TTU</RT·code> to derive the status. (The tape transport unit, the <RT·code>TTU</RT·code>, is discussed in the next section.) As established in the section discussing cells, cell types are:</p>
<ol>
<li><RT·code>leftmost</RT·code></li>
<li><RT·code>island</RT·code></li>
</ol>
- <p>A status of <RT·code>rightmost</RT·code> or <RT·code>island</RT·code> would never be returned for a computation theoretic Turing Machine tape. This is where having a finite extendable tape can differ from that of a single ended theoretical object.</p>
-
- <p>Each HU has a data buffer that can be read or written, and a status buffer that can be read.</p>
+ <p>A computation theoretic Turing Machine would never encounter a status of <RT·code>rightmost</RT·code> or <RT·code>island</RT·code>. This is where a finite extendable tape structurally differs from a single-ended theoretical tape.</p>
+
+ <p>For a realized <RT·code>TTU</RT·code>, data can only be read or written when there is relative motion between the head and the tape. Consequently, in an <RT·code>HU</RT·code> implementation, data and status registers are updated from an internal buffer that acquires data during head motion. Conversely, a write value is buffered until subsequent head motion provides the opportunity to write it to the tape.</p>
+
+ <p>Because values can only be read or written to a tape when the tape is in motion, it is advantageous to exaggerate the motion of step commands and to cache a small number of values. In addition, most architectures that make use of a tape drive will attempt to leverage high throughput in an effort to hide high latency by reading or writing blocks of symbols per tape access. Note though, the basic TTCA machine organization lacks the core memory required for buffering blocks.</p>
<h2>Tape transport unit, <RT·code>TTU</RT·code></h2>
<h3>Description of a <RT·code>read_g</RT·code> command</h3>
- <p>A magnetic tape head reads when the tape is moving, so ironically it is like the Emacs cursor. The read will occur when the machine steps, and the data will be waiting in the data buffer for a read command. The head will wait at the other side of the cell. Unlike the theoretical tape, there is interstitial space between the cells where the head can wait for the next command, then swipe further right. In a real machine, blocks of cells will always be read, and the buffer will be much deeper.</p>
-
<p>The current state latch, <RT·code>q</RT·code>, is open on the falling edge of the clock, and then samples and holds while the clock is high. The gate register, <RT·code>g</RT·code>, is the phase inverse; it is open while the clock is high, and samples and holds while the clock is low.</p>
<p>On the rising edge of the clock, the state is latched. The current state signal ripples through the <RT·code>Action Table</RT·code>. As the <RT·code>q</RT·code> register is stored as a one-hot value, this happens very quickly. Rather than placing commands in the <RT·code>Action Table</RT·code>, the decoded values of the commands that are needed for control are programmed directly into the table. Among the decoded outputs of the action command is a control signal that enables the opening of the gate register latch.</p>
</p>
<p>
- Given an original, all copies <RT·neologism>stemming from</RT·neologism> it will be equal to each other and to the original. By <RT·neologism em>stemming from</RT·neologism em>, this definition includes all direct copies and copies of copies.
+ Given an original, all copies <RT·neologism>stemming from</RT·neologism> it will be equal to each other and to the original. By <RT·neologism>stemming from</RT·neologism>, this definition includes all direct copies and copies of copies.
</p>
<p>
-->
<!-- LocalWords: Hopcroft Ullman endnote unformatted dereference
-<!-- LocalWords: computable cardinality
+<!-- LocalWords: computable cardinality uniquifier
-->
-->
projects / TM-2026 / commitdiff
