Self modifying code, lambda calculus - Re: ENIAC programming

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 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