On 9/16/2015 9:25 PM, Toby Thain wrote: 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. 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. paul

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.... <<<< It is easy to prove that a computer does not need the ability to run self-modifying code*: Assume the contrary Write a emulator running on a non-self-modifying machine for the machine that has self-modifying code (does anyone think that this is not possible? Mathematically - if not practically - this is trivial) Then the emulated machine can solve the problem and thus the machine running the emulator can. (there are some loose ends to tidy up to make this a formal proof but none of them are game-changers.) * Obviously (!) to load a program into memory for execution is, in a sense, self-modification. However I don't think that is what you mean. Early 3rd generation machines had special instructions to finagle their way around self-modifying code: The/360 had EX The 1900 had OBEY The GE6xx had a rather fancy variation but I forget what it was called. However it was soon discovered that these were almost as dangerous as self-modifying code, not actually necessary. Also with the introduction of re-entrant code (and paging) self-modifying became /really bad/ (tm) Andy

I'm not sure if there is a universally agreed to definition. It also matters why the question is asked. I can think of a couple of answers: 1. the contents of instruction memory is subject to change. 2. the contents of instruction memory is subject to change during execution of the program. 3. individual instructions in a program are changed by the execution of that program. 4. individual instructions in a program are changed by explicit data manipulation actions of that program. #1 is true for most computers past and present, because they allow a program to be loaded into memory from external storage. #2 is true in any program that uses overlays, or if the program is controlled by a debugger that uses "software breakpoints". #3 is true for some older ISAs where subroutine call writes a return address or jump back to the caller into the program address space. Examples are CDC 6000 systems (CPU and PPU). #4 is perhaps the best definition to capture the particular programming style that was once common and is now quite rare (though not quite extinct). It might be as simple as modifying the address field of an opcode, to do indexing when the ISA does not have indexing instructions or registers. Or it might be something trickier, where a function does one of two similar things depending on an argument passed in, which then causes the body of the function to be modified in the prologue. There's a bizarre variant of #3 seen in the Electrologica EL-X1, where there is an addressing mode ("C") that adds the B-register contents to the base address that's in the opcode, but then writes the resulting address back into the instruction. (So doing repeated C mode operations with B == 1 will walk through consecutive addresses in memory, leaving the code pointing at the first word after the end of the buffer referenced.) Needless to say, this makes no sense, was probably in practice rarely if ever used, and disappeared in the successor to that machine (the EL-X8 -- where the same opcode encoding was used for stack addressing, with B incremented or decremented to produce the standard stack access patterns). See Dijkstra's Ph.D. thesis for details. paul

What he said. In the narrow viewpoint, "self-modifying" could be construed as "altering the order of instruction execution based on computational results " I'm sure that there are those who would consider the "Execute" instruction on the S/360 machine (and lots of others) to be self-modifying code. Others would consider only those cases where executed code is actually modified actively (e.g. doing I/O to a variable port number on an 8080. The 8080 has only two I/O instructions (IN and OUT); both take an immediate (literal) operand). The difference between the three cases, is, to my mind inconsequential. --Chuck

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

On 9/17/2015 2:27 PM, Paul Koning wrote: Don't / didn't some machines do/did this by setting an address trap register rather than modifying the breakpointed instruction? Also, if the machine had explicit handling of overlays/segments, then that part of this becomes identical to #1. (Burroughs?)

On 2015-09-17 18:30, Dave G4UGM wrote: Say what? So if you run through the code/function twice, it won't work? That would be pretty ugly. I know architectures like the VAX keeps such state in registers. So there are some instructions that destroy some register content. Not that fun perhaps, but at least it means the code works if you run it several times, or even if you run it as reentrant code. As far as self-modifying code though, on some architectures it is more or less necessary. The PDP-8 for example cannot really work without self-modifying code. (Except in some limited scope.) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

On 2015-09-18 01:29, Dave G4UGM wrote: True. But while I have worked a lot on machines where you did it, and I have written more than my fair share of self-modifying code, I have not before seen a machine where the code would get modified behind your back. Oh well. I guess I should be happen I never had to deal with that architecture. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

From: Paul Koning Sent: Thursday, September 17, 2015 9:02 AM All right so far. <choke><spit><soda on keyboard> Excuse me???? A Turing machine is the very essence of self-modifying code, by its very definition! You have the infinite memory tape, divided into cells, a reader, and a writer. The reader looks at a cell and performs the action required by the symbol read there. Possible actions include erasing the symbol already present and writing a new symbol; once that is done, the reader looks at the new symbol and performs the action required by *that* symbol. Lather, rinse, repeat. (Interrupt when out of shampoo.) Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

As a total thread-drift, I have in my hand a machine that anyone would class as a a programmable calculator. It looks like a calcualtor, it has key-per-function operation (that is, a 'SIN' key, etc). And yet... Using totally documented instructions you can create a string containing the text of a program. You can then convert that string _into_ a program. And execute said program (as a subroutine of the program you are running that created the string and converted it to a program, in general). If that's not self-modifying code, I don't know what is... I refer of course to the excellent HP RPL machines. -tony

On Wed, Sep 16, 2015 at 4:18 PM, Dave G4UGM <dave.g4ugm at gmail.com> wrote: computable function can be computed by a fixed program. For a particular computable function, there may be a more efficient implementation using self-modifying code. On the other hand, computing a particular computable function may require an arbitrariy amount of recursion, so it may take an arbitrarily amount of writable memory. The recusion may, of course, be implemented as some equivalent that doesn't require the computer to have explicit subroutine calls or stack, but the memory may still be required.

What is the "that" you're referring to? Real time control just adds time constraints to the correctness properties. Any programming technique is valid, so long as those additional constraints are also satisfied. There's nothing in the use of recursion, or its avoidance, that has anything particular to do with real time programming. It may be true that some programming techniques are hard to analyze as far as their timing is concerned. (If so, their correctness in general is likely to be hard to establish, as well.) But recursion isn't necessarily one of those. paul