Earlier quoted context omitted.
It's quite widely used for dynamic library jump tables. When calling a function in a dynamically linked library, it calls a stub, which is initially a call to the lazy linker, but gets replaced with a call to the resolved function. You may be remembering early x86 chips that didn't properly invalidate the instruction cache after a write. Modern chips are fully cache-coherent.
This is interesting. I've read documentation about dynamic linking and it describes this replacement process but I never truly understood the fact it was self-modifying code. Doesn't this imply the program's code is writable? I know that JIT compilers also emit code into writable and executable pages. Aren't there security implications?
Assembly Language Programming: Still Relevant Today (2015)
61–70 of 100 posts
Re: Assembly Language Programming: Still Relevant Today (2015)
#62I'm rarely keen on posting negatives on articles that clearly took a lot of time to make, but I think this requires a bit of correction. I think this article is very, very simplistic. All of it relates to a 8 bits CPU that is 40+ years old. I switched to HLL as soon as I could get my hand on a compiler, namely, UCSD Pascal at the time! Then the Pascal, then to C and then myriads of other languages. I covered 6502, Z8…
Re: Assembly Language Programming: Still Relevant Today (2015)
#63As that 6502 example in the article shows, you don't great great productivity with assembly. And even macros don't improve on it that much.
Re: Assembly Language Programming: Still Relevant Today (2015)
#64I'm rarely keen on posting negatives on articles that clearly took a lot of time to make, but I think this requires a bit of correction. I think this article is very, very simplistic. All of it relates to a 8 bits CPU that is 40+ years old. I switched to HLL as soon as I could get my hand on a compiler, namely, UCSD Pascal at the time! Then the Pascal, then to C and then myriads of other languages. I covered 6502, Z8…
Yup. Explains all that neat hand-written AVX asm code in your video decoder, strcmp() implementation, lzma decompressor, utf8 parser, and the base64 decode logic in your browser.
A lot of people put in a lot of hard work so that you can have the cute thought that there is no more reason to write assembly. Many of them wrote your compilers, some of them wrote some of the logic I mentioned above. Quite sure that none of them appreciate being called "pretty much stupid".
Re: Assembly Language Programming: Still Relevant Today (2015)
#65"...self-modifying code, [is] sometimes appropriate to solve certain problems that have no other solution, or for improving efficiency, as in double-indirect addressing." I have read that self-modifying code on the x86 architecture is pretty dangerous at the assembly level. More broadly, this kind of comes back to all the issues in the "C is not a low level language" thread. Some level of assembler certainly gives th…
X86 is particularly friendly to self modifying code, going so far as to require fewer fences and hints when code is modified. It’s generally easier to implement self- and cross-modifying code on x86 than other ISAs, like say arm. (I manage a team thag writes self modifying code for a living.)
Re: Assembly Language Programming: Still Relevant Today (2015)
#66And I feel assembly should be more a core building skill in a programmers toolbox. So this article is very welcoming for o me.
Re: Assembly Language Programming: Still Relevant Today (2015)
#67You can still do it if you care about debug build performance.
Re: Assembly Language Programming: Still Relevant Today (2015)
#68Earlier quoted context omitted.
X86 is particularly friendly to self modifying code, going so far as to require fewer fences and hints when code is modified. It’s generally easier to implement self- and cross-modifying code on x86 than other ISAs, like say arm. (I manage a team thag writes self modifying code for a living.)
Sounds interesting. What does your team do?
Re: Assembly Language Programming: Still Relevant Today (2015)
#69Re: Assembly Language Programming: Still Relevant Today (2015)
#70Earlier quoted context omitted.
> I have read that self-modifying code on the x86 architecture is pretty dangerous at the assembly level. Dangerous in what way?
The original 8086 had a six byte instruction cache (the 8088 in the original IBM PC had a four byte instruction cache). If you modify an instruction less than six bytes away, it won't be seen by the CPU unless you issue a JMP (or CALL) instruction. It was not normally that big of an issue (just make sure you modify the instruction from far enough away). You can use the fact that the 8086 has a six byte instruction ca…