I often think this could maybe allow fantastic runtime optimisations. I realise this would be hardly debuggable but still..
It already does, in the form of JIT compilation.
OK but I meant in already native code, like in a C program - no bytecode.
Writing a Self-Mutating x86_64 C Program (2013)
11–20 of 42 posts
Re: Writing a Self-Mutating x86_64 C Program (2013)
#12I often think this could maybe allow fantastic runtime optimisations. I realise this would be hardly debuggable but still..
Programs from the 80s-90s are likely to have such tricks. I have done something similar to "hardcode" semi-constants like frame sizes and quantisers in critical loops related to audio and video decompression, and the performance gain is indeed measurable.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#13It's impressive how well laid out the content in this article is. The spacing, tables, and code segments all look pristine to me, which is especially helpful given how dense and technical the content is.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#14I had a great experience writing self modified programs is a single instruction programming game SIC-1: https://store.steampowered.com/app/2124440/SIC1/
Re: Writing a Self-Mutating x86_64 C Program (2013)
#15Re: Writing a Self-Mutating x86_64 C Program (2013)
#16I often think this could maybe allow fantastic runtime optimisations. I realise this would be hardly debuggable but still..
Programs from the 80s-90s are likely to have such tricks. I have done something similar to "hardcode" semi-constants like frame sizes and quantisers in critical loops related to audio and video decompression, and the performance gain is indeed measurable.
> "hardcode" semi-constants
You mean you somehow avoided a load. But what if the constant was already placed in a register ? Also how could you pinpoint the reference to your constant in the machine code ? I'm quite profane about all this.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#17Earlier quoted context omitted.
Programs from the 80s-90s are likely to have such tricks. I have done something similar to "hardcode" semi-constants like frame sizes and quantisers in critical loops related to audio and video decompression, and the performance gain is indeed measurable.
> "hardcode" semi-constants You mean you somehow avoided a load . But what if the constant was already placed in a register ? Also how could you pinpoint the reference to your constant in the machine code ? I'm quite profane about all this.
> Also how could you pinpoint the reference to your constant in the machine code?
Not OP, but often one uses an easily identifiable dummy pattern like 0xC0DECA57 or 0xDEADBEEF which can be substituted without also messing up the machine code.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#18Earlier quoted context omitted.
> "hardcode" semi-constants You mean you somehow avoided a load . But what if the constant was already placed in a register ? Also how could you pinpoint the reference to your constant in the machine code ? I'm quite profane about all this.
> Also how could you pinpoint the reference to your constant in the machine code? Not OP, but often one uses an easily identifiable dummy pattern like 0xC0DECA57 or 0xDEADBEEF which can be substituted without also messing up the machine code.
If you’re willing to parse object files (a much easier proposition for ELF than for just about anything else), another option is to have the source code mention the constants as addresses of external symbols, then parse the relocations in the compiled object. Unfortunately, I’ve been unable to figure out a reliable recipe to get a C compiler to emit absolute relocations in position-independent code, even after restricting myself to GCC and Clang for x86 Linux; in some configurations it works and in others you (rather pointlessly) get a PC-relative one followed by an add.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#19Earlier quoted context omitted.
Programs from the 80s-90s are likely to have such tricks. I have done something similar to "hardcode" semi-constants like frame sizes and quantisers in critical loops related to audio and video decompression, and the performance gain is indeed measurable.
> "hardcode" semi-constants You mean you somehow avoided a load . But what if the constant was already placed in a register ? Also how could you pinpoint the reference to your constant in the machine code ? I'm quite profane about all this.
All the registers were already taken.
You use a label.
Re: Writing a Self-Mutating x86_64 C Program (2013)
#20Earlier quoted context omitted.
It already does, in the form of JIT compilation.
OK but I meant in already native code, like in a C program - no bytecode.
LuaJIT has a wonderful dynamic code generation system in the form of the DynASM[1] library. You can use it separately from LuaJIT for dynamic runtime code generation to create machine code optimized for a particular problem.