Live data from Hacker News

Writing a Self-Mutating x86_64 C Program (2013)

ephemeral.cx

31–40 of 42 posts

Re: Writing a Self-Mutating x86_64 C Program (2013)

#31
post #7

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

The 80's:

Say you set a value for some reason. Later you have to check IF it is set. If the condition needs to be checked many times you replace it with the code (rather than set a value to check some place). If you need to check if something is still true repeatedly you replace the condition check with no-ops when it isn't true.

Also funny are insanely large loop unrolls with hard coded valued. You could make a kind of rainbow table of those.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#32
post #26

Fun article, but the resulting code is extremely brittle: - assumes x86_64 - makes the invalid assumption that functions get compiled into a contiguous range of bytes (I’m not aware of any compiler that violates that, but especially with profile-guided optimization or compilers that try to minimize program size, that may not be true, and there is nothing in the standard that guarantees it) - assumes (as the article a…

They check all those assumptions by disassembling the code.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#33
post #26

Fun article, but the resulting code is extremely brittle: - assumes x86_64 - makes the invalid assumption that functions get compiled into a contiguous range of bytes (I’m not aware of any compiler that violates that, but especially with profile-guided optimization or compilers that try to minimize program size, that may not be true, and there is nothing in the standard that guarantees it) - assumes (as the article a…

> self-modifying code > brittle

I mean that is to be very much expected, unless someone comes up with a programming language that fully embraces the concept.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#35
post #26

Fun article, but the resulting code is extremely brittle: - assumes x86_64 - makes the invalid assumption that functions get compiled into a contiguous range of bytes (I’m not aware of any compiler that violates that, but especially with profile-guided optimization or compilers that try to minimize program size, that may not be true, and there is nothing in the standard that guarantees it) - assumes (as the article a…

The author clearly explained that the whole article is more a demonstration for illustrative purposes than anything else.

> Changing compiler flags can already break this program.

That's not the point of the article.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#36
A program that can generate, compile, and execute new code is nothing special in the Common Lisp world. One can build lambda expressions, invoke the compile function on them, and call the resulting compiled functions. One can even assign these functions to the symbol-function slot of symbols, allowing them to be called from pre-existing code that had been making calls to that function named by that symbol.

Re: Writing a Self-Mutating x86_64 C Program (2013)

#39
Someone correct me if I am wrong, but self-mutating code is not as uncommon as the author portrays it. I thought the whole idea of hotspot optimization in a compiler is essentially self-mutating code.

Also, I spent a moderately successful internship at Microsoft working on dynamic assemblies. I never got deep enough into that to fully understand when and how customers where actually using it.

https://learn.microsoft.com/en-us/dotnet/fundamentals/reflec...

Re: Writing a Self-Mutating x86_64 C Program (2013)

#40
post #36

A program that can generate, compile, and execute new code is nothing special in the Common Lisp world. One can build lambda expressions, invoke the compile function on them, and call the resulting compiled functions. One can even assign these functions to the symbol-function slot of symbols, allowing them to be called from pre-existing code that had been making calls to that function named by that symbol.

I know that no other language can match Lisp, but many languages can generate and execute new code, if they're interpreted. Compile, too, if they're JITted. They all require quite a bit of runtime support though.
Post reply on HN