Content deleted Content added
Peter Flass (talk | contribs) →Massalin's Synthesis kernel: new section |
→Disadvantages: new section |
||
| (7 intermediate revisions by 5 users not shown) | |||
Line 1:
{{WikiProject
{{WikiProject Computer science |importance=Mid}} {{WikiProject Computing |software=y |software-importance=Low }}
==TODO==
Line 10 ⟶ 13:
Is a [[thunk]] and/or a [[trampoline (computers)]] also a kind of self-modifying code?
--[[User:DavidCary|DavidCary]] 03:01, 18 August 2005 (UTC)
:Not unless the code is generated at run time - and, even there, unless existing code is overwritten, ''I'' wouldn't call it self-modifying code. (I.e., I think this article should apply only to cases where existing code is modified; I don't think the generation of ''new'' code at run time can reasonably be described as code doing "self-modification".) [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 08:10, 15 May 2022 (UTC)
-----
Line 69 ⟶ 74:
:Awww, go on, it's not all that bad. What is required is a calm attitude and appreciation of the actual environment. By using the stack working area, you ensure the avoidance of clashes in a quite proper way. This is what multi-stack designs are all about, and by writing in assembler (with proper commentary) you need not be constrained by the shibboleths of the prating orthodoxists of flabbier computer languages that constrain themselves and declare it good. In other words, I have misbehaved also, and declare it good. [[User:NickyMcLean|NickyMcLean]] ([[User talk:NickyMcLean|talk]]) 19:51, 18 December 2008 (UTC)
:I'd call that "run-time code generation", not "self-modifying code". Unfortunately, this page covers both topics; there is some overlap, in that code could generate other code at run time on top of existing code, which involves both run-time code generation and self-modifying code, but some self-modifying code doesn't involve particularly sophisticated code generation, and run-time code generation may generate ''new'' code into "empty" memory rather than replacing ''existing'' code. I'd classify what you did as the latter; the generated code is on the stack, the code you copied is just a template used by the code-generation process. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 08:18, 15 May 2022 (UTC)
== JIT? ==
Line 125 ⟶ 131:
:I don't see "von Neumann" anywhere in the article, but I think that the relationship is that the [[von Neumann architecture]] envisaged a computer with a single memory space comprising both data and instructions. Self-modifying code would require that a program be able to treat a piece of memory as data and then reach it as an instruction, and would not be possible on a non-von Neumann computer with, for example, separate code and data spaces. (Who is King John?) [[User:Spike-from-NH|Spike-from-NH]] ([[User talk:Spike-from-NH|talk]]) 00:26, 25 April 2012 (UTC)
::I'm not sure what a "modified" von Neumann architecture is; a [[modified Harvard architecture]] could be one of at least three types:
::*an architecture with one address space for both instructions and data, but with separate instruction and data caches and separate buses between the CPU and the two caches, i.e. what the "modified Harvard architecture" page calls a "[[modified Harvard architecture#Split-cache (or almost-von-Neumann) architecture|split-cache architecture]]";
::*an architecture with separate address spaces for instructions and data, but with instructions that allow fetches from, or stores into, the instruction address space, i.e. what the "modified Harvard architecture" page calls a "[[modified Harvard architecture#Instruction-memory-as-data architecture|instruction-memory-as-data architecture]]";
::*an architecture like that of the [[Maxim Integrated]] MAXQ family of processors, which the "modified Harvard architecture" page calls a "[[modified Harvard architecture#Data-memory-as-instruction architecture|data-memory-as-instruction architecture]], and which is not exactly easy to explain (MAXQ is ''different'').
::The only one of those that I might call a "modified von Neumann architecture" would be the first of them, as, for the vast majority of operations, it is indistinguishable from an ''un''modified von Neumann architecture. The primary difference visible to most user-mode code is that, on ''some'' such architectures, stores must ensure that all caches, whether instruction, data, or unified, be updated or flushed (this is the case on [[x86]], for backwards compatibility with older processors without any caches or with only a unified cache) and, on others, a store is not guaranteed to flush instruction caches, and the architecture defines an instruction or instructions to force a flush, and attempts to execute the code being modified are not guaranteed to work correctly until after the instruction completes (this is the case on [[SPARC]], for example).
::In the case of x86, I think there ''might'' be instruction-pipeline issues that require some care when modifying code, dating all the way back to the [[8086]]; a case could perhaps be made that ''any'' architecture on which there is no guarantee that casually storing into the instruction stream will Just Work is a "modified von Neumann architecture", even if it's not a "modified Harvard architecture" in the sense of "it has, at some level, separate buses for fetching instructions and data, even though code and data are in the same address space and the same physical memory".
::So I don't see any way in which "any hardware that can allow self-modifying code to run in at least one operating system" is required to be "a "modified von Neumann architecture" computer" - no modification to the von Neumann architecture is necessary to support that. A particular architecture might be "modified" in the sense that it requires that care be taken when storing into code space, but an architecture could also require that no code need be taken, and require implementations to do whatever is necessary to make that be the case.
::I.e., being a von Neumann architecture in the address-space sense is sufficient; a "split-cache architecture" is a pure or modified von Neumann architecture in the address-space sense, and a modified Harvard architecture in the "bus between the CPU and the lowest level of caches" sense.
::Even the other flavors of modified Harvard architecture could conceivably support self-modifying code. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 07:22, 15 May 2022 (UTC)
== Apple II copy-protection citation? ==
Does anyone know if there is a citation for the anecdote of using self-mod code as a copy protection technique on the Apple II? I remember reading about it somewhere 20 years ago when I was 'into' the Apple II in high school (back when "20 megabytes" was considered "really in-humanly humungously big" LOL) [[User:Jimw338|Jimw338]] ([[User talk:Jimw338|talk]]) 21:35, 14 March 2013 (UTC)
:Don't know about Apple II, but I hae one PC game that used self-mod as copy protection. One had to käy in sequence from The manual and If it was correct The software rewrote some instructiins so that The program would run. The reason I sound it was because I had copied disk and no manual. Used assembler debugger to check what was going on and found that self modifing codes. Bypassed IT and The game functioned like it should. [[Special:Contributions/217.140.200.97|217.140.200.97]] ([[User talk:217.140.200.97|talk]]) [[Special:Contributions/217.140.200.97|217.140.200.97]] ([[User talk:217.140.200.97|talk]]) 20:06, 9 April 2025 (UTC)
== Really bad ==
Line 175 ⟶ 192:
Is Massalin's Synthesis kernel really relevant here? I propose removing it. [[User:Peter Flass|Peter Flass]] ([[User talk:Peter Flass|talk]]) 16:26, 11 January 2019 (UTC)
* '''Keep''' - surely it is an example of self-modifying code, and done by an operating system to itself? As distinct from an operating system modifying its various internal tables or linked-lists to activate or terminate a new task.[[User:NickyMcLean|NickyMcLean]] ([[User talk:NickyMcLean|talk]]) 08:49, 12 January 2019 (UTC)
== Reality check from Redmond. ==
Article should mention that self-modifying code is essentially incompatible with '''digitally signed executables''' (which is a common practice and gradually becoming a de facto requirement within the Microsoft Windows OS ecosystem). [[Special:Contributions/94.21.160.52|94.21.160.52]] ([[User talk:94.21.160.52|talk]]) 23:06, 5 December 2024 (UTC)
== Disadvantages ==
This does not seem to belong in the "Disadvantages" section: ''"Self-modifying code can be rewritten as code that tests a flag and branches to alternative sequences based on the outcome of the test, but self-modifying code typically runs faster."'' The statement that it can be rewritten doesn't seem to be a disadvantage, and the statement that it runs faster seems clearly to be an advantage.
So, this could possibly be listed in "Advantages" as: ''"Self-modifying code typically runs faster than equivalent code that tests a flag and branches to alternative sequences based on the outcome of a test."'' - but seems a bit redundant with the existing "Fast paths can be established for a program's execution..." statement. Comments? [[User:Harris7|Harris7]] ([[User talk:Harris7|talk]]) 12:00, 21 June 2025 (UTC)
| |||