Talk:Random-access machine

message: This seems to be a dupe of Register machine... -- 217.82.189.242 18:48, 1 Nov 2004 (UTC)
replies: text: http://www.cs.mcgill.ca/~cs251/OldCourses/1997/topic2/
Like a register machine, all the computations occur "in the registers" (not in an "accumulator" or "accumulators"). 
So we (perhaps) have here a Post-Turing machine with a "tape" designed as a indexed random access memory instead of shift registers, the index register loadable/jammable by an instruction (?). Do we have direct addressing? We need more reference than this (to say the least). An offset implies a summation of a value in the register plus an the offset-value provided by the instruction. This is not the same as increment-decrement of the index register's value. And, other authors' (extremely vague) specifications don't seem to agree with this one. wvbaileyWvbailey 01:20, 12 September 2006 (UTC)
thread_title: [Untitled]

message: From Hopcroft and Ullman (1979):
:"In addition, abstract compter models, such as the random access machine (RAM), also give rise to the partial recursive functions.
:"The RAM consists of an infinite number of memory words, numbered , 1, ..., each of which can hold any integer, and a finite number of arithmetic registers capable of holding any integer. Integers may be decoded into the usual sorts of computer instructions. We shall not define the RAM model more formally, but it should be clear that if we choose a suitable set of instructions, the RAM may simulate any existing computer" (p. 166)
Their RAM has a finite number of arithmetic registers each of which, like a register machine, can do arithmetic operations. There's a tape to hold each register's contents, a tape to hold the 'location counter', a tape to hold the 'memory address register' (cf their Theorem 7.6 p. 167)
Their proof uses:
:"the first 10 bits of an instruction [to] denote one of the standard computer operations, such as LOAD, STORE, ADD, and so on, and the remaining bits denote the address of an operand" (p. 167)
Reference from Hopcroft and Ullman:
:Cook, S. A. and Reckhow, R. A. (1973), Bounded random access machines," Journal of Computer and Systems Sciences 7:4, 354-375.
wvbaileyWvbailey 15:25, 14 September 2006 (UTC)
thread_title:  Hopcroft and Ullman (1979) 

message: In register machine we see Melzak turning his machine into something else by adding an "final modification", an "command" called "Ai Aj Ak":
:"...this will allow the machine to change its own program in the process of carrying it out. Our modification consists essentially of introducing what is known in computer terminology as 'a computed go to' instruction" (p. 288)
The command Ai Aj Ak "operate[s] on certain locations fixed in advance, namely i, j, k." He then iterates i, j, k by letting these indices be an Ap, Aq, Ar. Written in a slighlty more friendly form"
:A(Ap)   A(Aq)   A(Ar)
Not all the subscripts (Ap, Aq, Ar) are required. For example Ai, Aj, A(Ar) is permissible.
Suppose we have 8 holes, { A1, A2, A3, A4, A5, A6, A7, A8 }. Each contains an amount of pebbles: (< x> means "contents of hole x"): < A1 > = 5, < A2 > = 3, < A3 > = 7, all the rest contain zero:
: { 5, 2, 7, 0, 0, 0, 0, 0 }
The command : "S, A1, A(A3)" will do the following:
* look in hole A1, see how many pebbles there are in it i.e. 5
* remove this number (5 pebbles) from sink/source-hole S
* look in hole A3, see how many pebbles there are in it i.e. 7
* go to hole A7 and toss in the 5 pebbles i.e. 5 + 0 --> 5
The final result will be: 
: { 5, 2, 7, 0, 0, 0, 5, 0 }
Suppose the next command is: "A3, A2, S"  This will cause us to do the following:
* look in hole A2, see how many pebbles there are in i.e. 2
* attempt to remove this number from hole A3, i.e. 7 - 2 = 5 (is okay, so continue...)
* put these 2 pebbles in sink/store S
: { 5, 2, 5, 0, 0, 0, 5, 0 }
:: We have just done: < A3 > - < A2 > --> < A3 >, i.e. 7 - 2 --> < A3 >
Now do the first command again, i.e. "S, A1, A(A3)"
* look in hole A1, see how many pebbles there are in it i.e. 5
* remove this number (5 pebbles) from sink/source S (but not from A1)
* look in hole A3, see how many pebbles here are in it i.e. 5
* go to hole A5 and toss in the pebbles i.e. 0 + 5 --> 5
: { 5, 2, 5, 0, 5, 0, 5, 0 }
The next time we do this we will cause A3 to become 0, and at this point we [might] have caused a jump (unclear whether the model's conditional jump is caused by 0 OR underflow, or just an attempt at underflow), probably doesn't matter.
Now we would have to convince ourselves that this model allows for a Turing machine formulation. Melzak proves that it does: "the details of constructing the simulation program are clear now [to him, maybe] and the program itself is left to the reader as an exercise." (p. 292)
In the last paragraph of the paper he observes that "there appears to be no easy way to arrange for a stored program" (p. 293). Which is the salient/key requirement for a RASP. 
How to parse an instruction-list in "the holes": 
(i) The machine would need a "program counter" hole (more likely a pair, whatever...) and an  "instruction register" hole (more likely a pair... whatever). Upon receipt of "an instruction" pointed to by the "program counter" hole, the machine would put "the instruction" into the "instruction counter hole". [Either now or in a while it will have to reconstruct the now-missing instruction!]. (For example: 3 pebbles might be instruction "INCREMENT", 4 pebbles is "DECREMENT", IF-THEN's are an interesting challenge, etc).  
(ii) Parsing: If the machine were to decrement its "instruction register-hole" (the instruction's opcode) until empty, the "empty-condition" would propel the next steps of the "fetch" toward one-of-many "instructions". For example: "If hole is zero do www ELSE", decrement hole, "If hole is zero" THEN jump to xxx ELSE", decrement hole, "If hole is zero THEN jump to yyy ELSE; Decrement hole; "IF hole is zero THEN jump to zzz ELSE"; Decrement hole; "IF hole is zero" THEN jump to 'error' ELSE; [jump to *-1]". After "the parse", the first thing a valid "instruction" would do would be to rebuild the emptied hole per its own number [increment hole, increment hole.... ]. After the rebuild, the decoded/parsed instruction send the machine to "execute" the chosen command. 
(iii) We need the "indirect" ability to do this -- i.e. we need "pointer holes to 'the next instruction' ". 
wvbaileyWvbailey 23:55, 22 September 2006 (UTC)
thread_title:  Melzak (1961) 

message: Some citations of sources are not matched with a full reference (e.g. Boolos et al. in the "Formal Definition: Random Access Machine" section) Itayb 10:04, 21 March 2007 (UTC)
replies: text: Fixed (keeping same ref-style). BillWvbailey (talk) 20:10, 6 May 2010 (UTC)
thread_title: article not properly referenced