21–30 of 100 posts
Earlier quoted context omitted.
When I was young I imagined that when I'll be an advanced programming/CS student I would learn advanced stuff like self-modifying code. Too bad real life is not that exciting...
You can get a job in compilers if you want. Message me via my profile if you don't know where to start.
Earlier quoted context omitted.
I know it's abstracted away, but it's still relevant to how the programs run because almost all programs go through an assembly language phase.
What languages don’t? All of them execute on the processor in some way.
"...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…
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.
Earlier quoted context omitted.
I know it's abstracted away, but it's still relevant to how the programs run because almost all programs go through an assembly language phase.
What languages don’t? All of them execute on the processor in some way.
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.
That’s not self modifying code, though; it’s just an indirect jump through a pointer.
Earlier quoted context omitted.
What languages don’t? All of them execute on the processor in some way.
I could be mistaken, but, don't JVM languages avoid assembly steps? They use bytecode and are translated directly to machine code; I'm not sure there is an translate-to-assembly step. I'm also not sure how much of this confusion is semantics vs actually different components of the compilation and running process.
https://github.com/openjdk/jdk/blob/e73ce9b406c34bd460f0797f...
Also if you look at the compiler's intermediate representation at the very last phases you'll see it basically looks like an assembly program.
> Assembly language yields maximum control and execution speed. It yields the only control and execution. Almost programs are generated through an assembler and assembly language. How could it possibly not be relevant?
> Assembly language yields maximum control and execution speed. It yields the only control and execution. Almost programs are generated through an assembler and assembly language. How could it possibly not be relevant?
I read that line as suggesting that when using HLL the programmer generally does not have control over the assembly that is generated. I guess that is why sometimes, as the author suggests, the programmer may write part of a program in HLL and another part in assembly in order to achieve increase execution speed.
Earlier quoted context omitted.
That’s not self modifying code, though; it’s just an indirect jump through a pointer.
I think the op is saying that the instruction call gets rewritten by the instruction call .