Live data from Hacker News

Assembly Language Programming: Still Relevant Today (2015)

wilsonminesco.com

41–50 of 100 posts

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

#41

"...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…

> 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 cache and the 8088 a four byte instruction cache to determine which CPU the program is executing on.

These days, I think you would need to 1) have memory pages with code with write permissions, 2) possibly flush the instruction cache and 3) hope no other thread is using said routine. With today's security concerns, 1) will not be likely, 2) possibly requires elevated privileges (I don't recall---I've only really done ring-3 level code on x86) and 3) is probably okay in a single-threaded program.

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

#42
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.

I don't know much about x86, but on other cpus/architectures (PowerPC, MIPS, and possibly others) one might still need to fiddle with the instruction cache.

On modern IA32 and AMD64 architectures it involves the instruction cache in the cache protocol, so it's all done for you.

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

#43
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…

You can get around 1 by having the page be mapped multiple times with different permissions. Modern x86 processors don’t need a cache flush.

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

#44

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…

You haven't written any Assembly, because the guys and girls that implemented the compilers you use have done it for you.

Someone has to create those tools.

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

#45
post #18

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

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?

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

#46
post #8

As recently as a year ago I used built in assembler in Delphi to perform some low level timing. It was not for just super-duper performance though. Surprisingly it was the most straightforward and simple way. Meanwhile my firmware for 3-Phase AC motor torque and speed control for really low power micro controller was doing fine with plain C without any assembly.

What do you do for a living?

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

#47
Not sure why HN is saying it is obvious that assembly is relevant because compilers... The article's intent is around a programmer writing assembly. I'm sure there are niches but I can see web developers getting away without writing assembly in their professional career.

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

#48

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

There are a huge number of software engineers today, dare I say most, who cannot read or write assembly and are isolated from it by multiple layers of abstractions.

I would probably struggle to write assembly without difficulty and blowing something up but... is most macro assembler really that hard to read? The examples the author of the article gave seemed reasonably easy to parse out for anyone who has a conceptual model of control flow, variables, memory locations, and basic operations.

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

#49
post #47

Not sure why HN is saying it is obvious that assembly is relevant because compilers... The article's intent is around a programmer writing assembly. I'm sure there are niches but I can see web developers getting away without writing assembly in their professional career.

Might see that flip in the coming years, if you consider web assembly (wasm) to be assembly. I do.

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

#50
Excerpt:

"Jeff Laughton (Dr Jefyll on the 6502.org forum) says, "I recall hanging out with a programmer pal o' mine and a younger fella who was in college. The young fella was complaining, 'We have to take assembly language,' and Len corrected him immediately, saying, 'You get to take assembly language!'"

Post reply on HN