Self modifying code, lambda calculus - Re: ENIAC programming
dave.g4ugm at gmail.com
Thu Sep 17 11:30:14 CDT 2015
> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Paul
> Sent: 17 September 2015 17:02
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Subject: Re: Self modifying code, lambda calculus - Re: ENIAC programming
> > On Sep 16, 2015, at 11:36 PM, ben <bfranchuk at jetnet.ab.ca> wrote:
> > On 9/16/2015 9:25 PM, Toby Thain wrote:
> >> On 2015-09-16 6:18 PM, Dave G4UGM wrote:
> >>> ...
> >>> It is notable that in order to solve all problems, a computer must
> >>> permit self modifying code.
> >> Is that true? AFAIK Lambda calculus can describe any computable
> >> function (as can a Turing machine), and it has no concept of "self
> modifying code".
> > I never studied any of that, but you do have to LOAD and RUN the
> > program ToSolveAnythingBut42 some how so I guess that would count AS
> Self Modifying Code.
> "load" is an operation in a RAM stored program computer, sure. But self-
> modifying code means a program that modifies its own code during
> execution. That is a scheme that has on rare occasions been used in
I actually think its pretty common, at least on certain machines, especially
for character manipulation.
There are machines, I think the Honeywell L66 is one, which make character
sting moves interruptible by updating the addresses and lengths as the
instruction is executed.
COBOL includes the ALTER verb which can be implemented as self-modifying
I know when I first started working on Honeywell H3200 code someone modified
a very slow program to use ALTER...
.. and afterwards the program ran many times faster, but of course became
.. so probably rare but totally un-maintainable...
> You could also apply the term to instructions that store state in the
> instructions in memory for later use, such as "return jump" in CDC
> But I wouldn't apply the term there; that's just a particular mechanism
> different from, but functionally equivalent, to a return address stack.
> In any case, I do not believe the original statement. First of all, it is
> known that no computer can solve "all problems" (see Gödel). For those it
> *can* solve, as far as I know, a Turing machine can solve a superset of
> stored program computer can handle, and a Turing machine does NOT have
> self-modifying code.
I took it from Crispin's paper and I assumed it was correct as he has done a
lot of work on this...
.. and I assumed when he said "solve all problems" we were referring to
problems that can be solved on a Turing Complete computer....
More information about the cctalk