Self modifying code, lambda calculus - Re: ENIAC programming

[Mouse]

> What I don't understand is what problem they thought they were fixing
> by outlawing self modifying code.

As the discussion illustrates, and as I point out below, in some of the
weaker senses it's still alive and well, not outlawed at all.

In the usual sense, approximately "code which writes memory and then
executes it as machine code during the same program run"?  That's what
I'm going to treat the term as meaning in the rest of this mail; in
particular, I am not even trying to discuss things, like Turing
machines, that aren't relatively conventional von Neumann or modified
Harvard machines, executing relatively conventional machine languages
out of relatively conventional memory.  That said, then, I see there
being basically three kinds of systems:

(1) Such code works just fine, and in some cases is necessary to do
     certain useful operations.

(2) Such code is not really supported, but might work if you happen to
     be lucky (or unlucky, if you prefer to think of it that way).

(3) Such code will crash unless it takes special precautions, such as a
     syscall to re-protect the relevant memory.

Type (1) machines are the oldest, including things like the 8080 whose
I/O instructions were cited upthread.

Then in came things like pipelined CPUs and instruction prefetch, and
separate instruction and data caches, leading to hardware that did (2).
The usual justification for breaking the then-traditional programming
model this way is "performance" - such machines generally run
significantly faster than type (1) hardware.  In some cases there
was/is support for flushing/invalidating caches, purging execution
pipelines, and the like, making it possible to still write
self-modifying code if you're careful.  (As an amusing example in this
connection, the VAX architecture reference manual points out the need
to purge prefetch buffers and such after writing memory and before
executing it - but also says that code running in PDP-11 compatibility
mode (on hardware that has it, of course) does not need to take any
such precautions.)

Then along came networks and the September than never ended and
suddenly it's the rare machine that isn't facing a hostile environment.
This led to things like hardware supporting W^X, giving us type (3),
which is mostly where we are now[%].  On such hardware, self-modifying
code still exists, even in the sense I'm using here (consider the
patchups involved in loading dynamic libraries on a modern system), but
it requires significant assistance from the kernel - or, more
precisely, from code that has the ability to fiddle with the memory
protection hardware, which generally means the OS kernel.  (Such code
inherently owns the machine if it wants to; it's one of the few pieces
of an OS that _has_ to be highly trusted.)

[%] Okay, on this list perhaps "we" is the wrong word here.  Where most
    of the computer world is now, then, perhaps.

So, the answer is threefold.  First, they haven't really; even today
you can do self-modifying code on most hardware/OS combinations if you
make the right syscalls to re-protect the relevant memory, purge
prefetch buffers, and the like.  Second, the older problem they were
fixing (to the extent that "they", and the problem, exist) is "poor
performance".  And finally, most recently, the problem is security
against certain depressingly large classes of attacks on buggy
software, like smash-the-stack buffer overruns.  (It doesn't stop them
all, of course, but it makes them harder.)

And, finally, in passing, could whoever's using the software
responsible for syntax errors like the

> References: <082901d0f166$21f3fa20$65dbee60$@gmail.com>,
>  <754580134.385014.1442509410772.JavaMail.root at md02.topaz.synacor.com>,
>  <BLU168-W489EC1A1ADC71D63C67FE7A35A0 at phx.gbl>,
>  <AC8E698B-C14B-4460-A4C4-F59DA7558311 at comcast.net>,
>  <55FB2C18.1030903 at sydex.com>

I found in this list mail please either fix it or stop using it?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B