Live data from Hacker News

Assembly Language Programming: Still Relevant Today (2015)

wilsonminesco.com

61–70 of 100 posts

Re: Assembly Language Programming: Still Relevant Today (2015)

#61
post #18

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?

There are. That’s why dynamic linking typically doesn’t use self-modifying code and JIT compilers take a number of precautions to prevent attackers from being able to execute arbitrary code.

Re: Assembly Language Programming: Still Relevant Today (2015)

#62

I'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…

This article is specific to the 6502 where the commonly used CC65 C compiler the author references produces much, much worse code speed wise than what you can with pure assembly. In that regard, the article is not simplistic in the least. Coincidentally, I messaged the author just yesterday about the for loop example to point out that it was generated without optimization. Even with optimization enabled, the code is still about 3 times slower than hand written assembly. I know this may not be typical for other architectures like AVR but it certainly is for 6502.

Re: Assembly Language Programming: Still Relevant Today (2015)

#63
Even back in the 1980s, author Lance Leventhal who wrote some great programming books on assembly always warned that productivity wise you write the same number of lines of code whether its 6502 or C.

As 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)

#64

I'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…

> Today, hand writing assembly is pretty much stupid on modern CPUs

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

Sounds interesting. What does your team do?

Re: Assembly Language Programming: Still Relevant Today (2015)

#66
To me, assembly is one of the things while self studying CS that I felt lacked good support in resources such as this, MOOCs, or just plain explaining it. Usually when I post a topic trying to Demystify the topic I am greeted with an extremely hard to digest read about said topic that is more meant for people Already knowledgeable in the subject.

And 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)

#67
On modern x86 it's not very useful at all anymore. An ICC or LLVM backend with compiler intrinsics will get you quicker performance, with reduced maintenance and cost. Performance will also move over time with backend optimizations getting better.

You can still do it if you care about debug build performance.

Re: Assembly Language Programming: Still Relevant Today (2015)

#68

Earlier 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?

Among other things, just-in-time compilers for the WebKit JavaScript engine, JavaScriptCore.

Re: Assembly Language Programming: Still Relevant Today (2015)

#70
post #41

Earlier 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…

I remember using the instruction-cache as a way to catch debuggers single-stepping through my code. If you rewrote a near instruction to be a jump-to-self single-steppers would fall victim to it..
Post reply on HN