Self modifying code, lambda calculus - Re: ENIAC programming

Dave G4UGM 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
> Koning
> 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
history.

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
code.
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
totally un-maintainable.

.. so probably rare but totally un-maintainable...

> You could also apply the term to instructions that store state  in the
form of
> instructions in memory for later use, such as "return jump" in CDC
machines.
> 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
well
> 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
what a
> 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....

> 
> 	paul

Dave




More information about the cctech mailing list