Assembly Language: Still Relevant Today

by ingve • 11 years ago

135 75 11 years ago

gfody2• 11 years ago

No mention of graphics programming or signal processing? High level syntax just gets in the way when you're trying to pack six pixels into two registers just right. Assembly language is still pretty much the right tool for the job.

vox_mollis• 11 years ago

Or security, for that matter. Reversing, malware analysis, black-box auditing, &c require, at minimum, the ability to read assembly.

The article is begging the question. I'm unaware of anyone who thinks assembly is not relevant.

LogicFailsMe• 11 years ago

Talk to a data scientist.

nickpsecurity8• 11 years ago

There's a ton of people who don't need assembly. Including security engineers that work in C with tools like Astree or Frama-C. Then, tools such as CompCert compiler can handle the rest. ;)

Blackbox and reversing, though, certainly need or benefit from assembly. Depending one what one is analysing.

andrewflnr• 11 years ago

If students count, the other day I heard some griping about how they had to learn assembly even though "we're never going to use it".

tikhonj• 11 years ago

There's a big difference between "assembly is not relevant for anyone" and "assembly is not relevant for everyone". I suspect few people hold the former view and a bunch hold the latter, but shortened both sound the same.

pjmlp2• 11 years ago

Or writing compilers, OS drivers, to add two more.

eva1984• 11 years ago

There are a lot of engineers out there work on higher abstractions. If the task is to write a map reduce or spark job, for sure, most of the time I don't think you need to know what happens with your application at assembly level.

blt• 11 years ago

Tangent: I wish more (any?) high-level languages were capable of expressing self-modifying code safely. A lot of values are variable at compile time but constant within a significant block of computation at runtime. If compilers were designed to emit self-modifying code, they could propagate constants through the block and replace register/register instructions with register/immediate instructions, freeing up registers for other variables. This is the promise of JIT compilers but in practice the popular jit-compiled languages have too many other performance issues to be popular for serious CPU-bound work. Plus the jitter has to do a lot of analysis at runtime. It would be cool if you could mark a block of C code with `#pragma jit`, making the compiler emit a binary that contains some compiler IR and a peephole optimizer to make the code as tight as possible given the conditions at runtime.

gfody2• 11 years ago

I can't think of any language that has this as a feature. But there are some nice libraries for assembling machine code at runtime - there was one I used called "softwire" that seems to have disappeared. I just found this one on github: https://github.com/kobalicek/asmjit

ChrisLomont3• 11 years ago

C# (Microsoft stack, probably other stack, probably other .NET languages) lets you generate or input C# code at runtime, compile it, and run it through the jitter as desired. It's nearly trivial to do it. The Regex classes for example create code at runtime to do compiled regular expressions, but I think they do it with emitted IL instead of C# code directly.

All the pieces are there.

dx211• 11 years ago

.Net provides a couple of different ways to dynamically emit IL, but that's not quite the same as being able to emit your own native machine instructions, though. I think the challenge would be that you'd need to work out a calling convention between the jitted code and the emitted native code, at which point you might as well stick the native code in its own library function and compile or assemble it with a native tool.

dsharlet• 11 years ago

The LINQ expression compiler also lets you generate expressions at runtime and compile them, it's an amazingly powerful feature: https://msdn.microsoft.com/en-us/library/bb397951.aspx

yaur• 11 years ago

Have you ever seen the jiter use SIMD? Having written some test code that was the simplest use case (multiply an array of floats by a float constant iirc) I have not. C# is a great language, but not for compute bound problems.

gdwatson• 11 years ago

Selectively using code generation to implement closures over immutable variables could get you part of the way there while allowing a lot of the work to be done at compile time and avoiding the need for a full JIT.

How much it would help performance in practice I couldn't say.

kazinator• 11 years ago

If compilers were designed to emit self-modifying code

... then the high-level language isn't expressing self-modifying; the compiler is doing it to optimize the code while preserving the abstract meaning that is free of self-modifying.

mbrock• 11 years ago

Maybe you know that Common Lisp makes it easy to compile and recompile functions at runtime.

http://clhs.lisp.se/Body/f_cmp.htm

In fact, with the package system ASDF, you can recompile (incrementally) an entire package at runtime. This is a single blocking function call; something like:

(asdf:operate 'asdf:compile-op :my-package)

I have a web project where any request in dev mode triggers a system recompilation only if the git revision of the working tree is new.

(my-handler :did-recompile (when (revision-is-new) (recompile) t))

That recompiles the system including MY-HANDLER, and right after RECOMPILE returns, the new version of MY-HANDLER from the working tree will be active.

The way Common Lisp lets me do that as a ten minute hack feels like living in the future... except of course it's pretty old technology!

Edit: I realize this is not really what you are talking about as "self-modifying code." Having full access to the compiler at runtime is a good first step for doing some of what you want, though. And with S-expressions, constructing and manipulating "ASTs" is ridiculously straightforward.

_cbsz2• 11 years ago

Modern processors don't handle self-modifying code efficiently. https://en.wikipedia.org/wiki/Self-modifying_code#Interactio...

userbinator• 11 years ago

short sections of self-modifying code execute more slowly

Unless you're optimising for size, SMC'ing little pieces is definitely going to be slower. But e.g. in loops that do a few hundred iterations, saving a cycle or two by getting rid of some opaque predicates quickly adds up and the cache/pipeline-flushing overhead (few hundred cycles at most) becomes insignificant.

After all, as the parent comment says, a JIT is basically SMC'ing huge blocks of code, and it's definitely faster than the equivalent alternative of a bytecode interpreter.

easytiger2• 11 years ago

It would be cool if you could mark a block of C code with `#pragma jit`, making the compiler emit a binary that contains some compiler IR and a peephole optimizer to make the code as tight as possible given the conditions at runtime.

Even if that remotely made any sense, which i don't think it does... c code compiles to the end target of all jits anyway, you just have some if statements or use pointers to other executable code that you swap around. Not only do you get the executable code as efficable as any jit, its constant with no jit cost. Its called c programming.

creshal• 11 years ago

When you have variable types (say, you're deserializing foreign data, always fun), typical C code will end up having a huge switch() block do determine the type (expensive, e.g. due to branch prediction) and do something with it (trivial). Ahead-of-time compilation cannot optimize away the switch(), JIT can, by evaluating the data fed to the function at runtime.

What OP wants is a way to get the advantage of ahead-of-time compilation for the 99% of the code that benefit from it, and the advantages of JIT for the remaining 1% (or even less).

However, I'm not sure how feasible that would be.

exDM692• 11 years ago

Probably doesn't count as "high level" but you can embed the LLVM compiler backend to your project and compile and optimize code at runtime.

See the LLVM "Kaleidoscope" tutorials from the LLVM docs. They implement a simple toy compiler with a JIT-based REPL. Basically you use the LLVM framework to build a program and then run it through the compiler pipeline and get a callable function pointer to your newly compiled function(s), optimized for the CPU architecture you're running on.

eru3• 11 years ago

I've seen people use that for compiling regular expressions to LLVM assembly at run time.

mgraczyk• 11 years ago

I wrote up a small module to do this in C on x86 platforms. I called it a predicate replacer, but it can replace any integer constant. https://github.com/mgraczyk/fast_check_once

13of402• 11 years ago

Two or three years ago I was doing an informational interview, trying to move from a QA job to a developer job, and I mentioned to the guy that I used assembly code almost every day. He guffawed and said I was full of it, but it was true -- firing up a debugger and stepping through assembly might be pathological on the desktop these days, but when you're investigating a failure on a back-end datacenter machine that's running some interim build that's impossible to find matching symbols or source for, probably over a KVM...

otoburb• 11 years ago

Did you get a chance to prove it in the interview?

13of402• 11 years ago

Hell no. I was a dead man walking in that interview. When I was trying to transition from test to dev, half the people I interviewed with didn't even ask me technical questions. I had one interviewer show up half an hour late, spend the next 25 minutes trying to convince me to stay in test, then (literally) give me five minutes to whiteboard a linked-list problem in C++, and his feedback to the hiring manager was that I was lacking coding skills. I eventually got into a dev position, but it was it was an utterly medieval process. I wish I was kidding, but my take on the whole get-a-dev-job scene right now is that you have to be (a) young, (b) skinny, and (c) the same race as the hiring manager and interviewers (I shit you not). After that comes coding.

_cbsz2• 11 years ago

I don't think it's unreasonable to differentiate between reading assembly produced by a compiler and handwriting assembly. I do the former several times a month and the latter almost never.

gaius3• 11 years ago

It's never reasonable to laugh at someone you're interviewing. Too many so-called engineers treat an interviewee just as a captive audience to brag about their own skills.

hoodoof• 11 years ago

I can heartily recommend this book for beginners http://www.amazon.com/Assembly-Language-Step-Step-Programmin...

matt_d• 11 years ago

For more (in the x86-64 specific context), see also http://tinyurl.com/x86-64-assembly

yeureka• 11 years ago

I know a developer that earns well above 1500£ per day writing and maintaining x86 assembly embedded in C++ for finance applications.

That is higher than the going rate for Haskell in finance afaik.

So yes, still relevant.

marssaxman• 11 years ago

Huh. Too bad it's finance. Is there anyone in a non-parasitic industry still paying that kind of money for assembly coding? Maybe I should get back into it. I always loved the low-level world, anyway.

jackweirdy• 11 years ago

Furthermore, is any non-parasitic industry paying that kind of money for any coding?

bonobo30002• 11 years ago

Finance is the "parasitic" industry that powers every big VC and every tech IPO - the reason that founders can pay programmers as much as they do these days.

easytiger2• 11 years ago

Too bad it's finance. Is there anyone in a non-parasitic industry

Oh grow up

pmjordan• 11 years ago

I can't comment on £1500 specifically but there's plenty of (IMO) well-paying demand for low-level dev work out there in the tech industry in general. (Whether you consider the tech industry parasitic is of course another matter entirely…; I've never worked in finance and I do alright.) I don't know about predominantly writing assembly code, but that probably exists, too (SIMD…). Personally, I read a lot more (dis-)assembly than I write.

General advice for deeply technical consulting: you need to have a lot of deep practical experience in a few specific areas and you'll generally need to hit the ground running no matter what project you're dropped into and rapidly start generating corresponding value for the client. And expect to be continuously fighting off offers of permanent employment once you start picking up work.

copperx• 11 years ago

Still relevant for that developer? Yes, very much so.

For others?

eru3• 11 years ago

Is the going rate for Haskell in finance especially high?

I used to work with Haskell in finance, but as an employee not contractor. Money was OK, but not higher than for any other language as far as I can tell.

(I wouldn't be surprised if going rates for Cobol and Fortran were higher than for any sane language.)

mettamage• 11 years ago

I'm a bit surprised by the title of the article. The content was a fun and interesting read. When I read the title I thought to myself: "of course assembly is still relevant!"

Which group of people or school of thought would say that assembly isn't relevant? I'm genuinely curious.

ksherlock• 11 years ago

The group of people chasing the javascript framework of the week, writing text editors in javascript.

nickpsecurity8• 11 years ago

"writing text editors in javascript"

Just 5-10 years ago, that might have been considered a joke. Now I wonder if you're referring to a specific project. And if it's already deployed as a Droplet. ;)

kabdib• 11 years ago

An article I wrote a while back, largely about how assembly is not dead:

http://www.dadhacker.com/blog/?p=1911

That project was using a CPU costing less than twenty cents to control the power of a consumer product. Code space mattered a lot, and doing the project entirely in a high-level language would have doubled the part cost. When you're talking quantities in the tens of millions, saving ten or twenty cents on the cost of goods is a Big Deal.

Nano2rad• 11 years ago

Assembly Language is for understanding the processor.It is still relevant for that.

asveikau• 11 years ago

When I was at Microsoft, at least among several of the better developers, when debugging an issue, many would just ignore source code and enter a bunch of "u" (disassemble) commands into windbg. This is IMHO a great habit if you're writing C or C++. In many cases it ensures less distance between you and a bad pointer dereference. Your code, my code, source code, or none - doesn't matter. Just look at the faulting address and see what it expects.

From a certain vantage point, in these languages, if you aren't seeing assembly from time to time, you're not seeing reality.

Consequently, I kind of chuckle when I hear people say they can't debug optimized builds.

Assembly Language: Still Relevant Today

Related Stories