Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Are there major differences between assembly language and higher level languages when it comes to coding and/or managing projects? Obviously it takes more statements in assembly language to carry out a particular operation than in most other languages, but are there differences that affect how a project needs to (or should) be run based on targeting assembly language (specifically x86/x64 assembly language)?

To the extent that there are differences between assembly language and other languages, it seems reasonable to guess that at least some of these are advantages for the other languages. Can anybody point out specific disadvantages of assembly language, and ways to mitigate those disadvantages?

One specific example would be staff availability. Has anybody had trouble finding experienced assembly language programmers, and if so, what steps can be taken to mitigate this problem?

share|improve this question
    
Why would anyone write a complete project solely in assembly language today? Or are you asking about a mixed-language environment, which is how assembly is typically used today? –  Martin Vilcans Jul 25 '11 at 21:07
3  
Note that there are areas of non-[PC|web|enterprise] programming, where Assembly is predominant or very popular. I'm talking micro-controllers, industrial automation or robotics. Sure, there are high level languages in these areas too, but you see Assembly a lot. –  Mchl Jul 25 '11 at 22:05
1  
@Mchl: Aren't these projects made in C (or even C++) and possibly assembly? I would have guessed that it's very uncommon to use assembly exclusively. –  Martin Vilcans Jul 31 '11 at 18:14
    
Actually in industrial automation you can meet a whole branch of languages that simply do not exist outside of that field. Part of that comes from differences in hardware (Harvard architecture as opposed to von Neumann architecture we're so used to). as well as from history of making these controllers accessible for electricians, who were used to work with switches and relays. That's how LD (en.wikipedia.org/wiki/Ladder_logic) come into existance, which is actually a graphical interpretation of assembly. See the linked article for some more languages used in automation. –  Mchl Jul 31 '11 at 21:02
    
I've got a small installer that I support now that's in assembly. It was as easy to write in assembly (with Windows API) as anything else, so why not? I've also got a credit card swiper interface written in assembly. Started in high level languages, but had so many difficulties getting it to work that I rewrote in assembly to get better control of all the bits flowing... –  Brian Knoblauch Jan 14 at 19:23
add comment

4 Answers

Yes - but not often.

In one sense, assembly is really just a proxy for machine language, so of course you can do anything in assembly that you could with a higher level language.

The opposite is not always the case. For instance, a few years ago, I worked on an ARM CPU that had some funky opcodes for changing graphics states that could only be used from kernel mode. They would have no direct equivalent in a higher level language, and I'm sure the function in the Linux kernel driver for changing those states included some assembly.

On microprocessors back in the '80s and into the early-mid '90s, if you had some code you needed to run really fast, you'd often write it in assembly, because a skilled human could easily write more optimized assembly than most C compilers could generate. Some early Mac programs were written entirely in assembly, and they were astonishingly fast for the era. Even without writing the whole program in assembly, I certainly did my share of optimizing inner loops in C via embedded assembly.

But things started changing in the mid-1990s. CPUs began including features like pipelining and branch prediction, so the most efficient instruction ordering was not always obvious to a human. Worse than that, the most efficient ordering varied among CPUs in the same family; for instance, PowerPC compilers typically offered target switches for G3, G4, and G5 series. The same object code would run on all of them, but it would run on one of those series more efficiently.

Since then, instruction ordering has gotten progressively more complicated, especially on the more architecturally complex CPUs like x86, PowerPC, and SPARC. (I believe ARM is still pretty simple that way.) A big added factor is code size - code that uses more CPU cycles but can remain in the CPU cache will often run much faster than code that uses fewer CPU cycles but triggers slow memory fetches. The major modern compilers can do a far better job of optimizing code on those CPUs than a human reasonably can.

I haven't found a good reason to write assembly in at least 15 years. I think in 2011, the main uses for assembly would be:

  • To read disassembly dumps when debugging, which I occasionally do even today.
  • Dealing with non-standard CPU features, like that funky graphics mode.
  • Compiler writing - it provides an intermediate, human-readable format to translate higher-level languages into.
share|improve this answer
    
And even your reason #3 is starting to disappear with compilers targeting either a high-level compiler framework like LLVM, nanojit or libjit or something like JVM, CIL, Parrot, Rubinius or Neko bytecode. –  Jörg W Mittag Jul 26 '11 at 1:16
    
It's still sometimes necessary to do a bit of SSE2 in graphics/video work. Although benchmark against TBB/OMP first! –  Martin Beckett Jul 26 '11 at 1:18
    
@Martin: OMP is orthogonal to SSE2. (assuming good data layout practices) –  rwong Jul 26 '11 at 11:45
    
@rwong - but the process is still, 1, discover it's too slow. 2, hope OMP/TBB speeds it up enough. 3, resort to hand writing SSE2 version! (in order of pain) –  Martin Beckett Jul 26 '11 at 17:40
    
As an example, the entirety of Roller Coaster Tycoon was written in assembly (minus the graphics which were done in c) and was amazingly powerful for it's time. Hundreds of individual AIs acting independently, almost seamlessly, when most game had a few 16x16 pixel sprites doing predefined motions. I always like to use that to show the power of assembly. –  Ampt Jan 16 at 14:47
show 1 more comment

Try programming a microcontroller for a "small embedded" - a car alarm remote, a phone battery monitor, a keyboard controller, fan speed regulator, without using assembly.

While the border moves, there is always room for assembly.

15 years ago your bicycle odometer was mechanical, a microwave oven was in analog circuitry, TV remote was in digital circuitry, Sat TV tuner was written in assembly, a phone firmware was in C and a computer applet was in Java.

7 years ago a microwave oven was in digital circuitry, a TV remote was written in assembly, TV set-top box was written in C, your phone ran Java-based UI.

Nowadays, a bicycle odometer is in digital circuitry, a microwave oven gets firmware in assembly, a TV remote has firmware in C, TV set-top box runs Java, your phone got Linux.

Wanna bet the next 7 years? As more technology gets more advanced control languages, assembly gains new grounds, and it will keep getting them. Look at what is done today with mechanical or analog circuits. You can bet assembly there in a few years. Your light switch? Your water tap? Your kettle? Your toothbrush?

There will always be a new device, appliance, toy, common-life item to be programmed in assembly.

share|improve this answer
1  
good answer. How many folks would rather pay twice as much for something that the batteries last half as long just because java or something was used as the development platform? Look at groupon and all the other ways folks look to save money, look at the green movement saving resources. Why drive the cost and power up on all embedded products just to avoid assembly? –  dwelch Jan 12 '12 at 22:57
    
You forgot to add that now computers run Javascript (Chromebooks). To me that progression is pretty sad but true. –  Hawken Jan 6 '13 at 2:55
add comment

I'm basing this primarily the assemblers I've used -- primarily MASM, NASM, and (to a lesser extent) TASM. Some of the later versions of TASM had (have?) some features to support OO, but I haven't used them much, and I'm not trying to comment on them.

First: most languages have moved toward a structure that's at least somewhat tree-like. Whether object oriented, or object-based, or exactly what, there's quite a bit defined about the relationships between different parts of a system. There's also quite a bit to "protect" one part of a system from accidental "meddling" but other parts (even though the protection can usually be bypassed if you want to). By contrast, assembly language is relatively "flat" -- most of the relationships between the code (and data) in different parts of the system are established primarily by documentation and to a lesser extent naming conventions.

The result of this is that it's often much easier to couple code much more tightly than would be ideal. The requirements that drove the choice of assembly language to start with (higher performance, smaller size, etc.) often reward this as well -- by bypassing approved interfaces and such you can often get code that's smaller and faster (though not usually a lot better in any dimension). The language and tools themselves do much less to restrict what you do (good or bad), which places a much greater burden on the managers to prevent problems. I wouldn't say it's qualitatively different, but quantitatively it is -- i.e., management has to work to prevent problems either way, but in the case of assembly language it generally takes more (and often tighter) guidelines about what is or isn't acceptable.

Mitigating this is largely a matter of more careful guidelines, more guidance from more experienced personnel, and more specific, carefully enforced naming conventions.

Staffing is something of a problem. The problems I've encountered, however, where not primarily the ones I expected. Finding guys with a bit of a "fighter jock" personality who were happy to jump into assembly language code was fairly easy. Most did quite a reasonable job, despite an almost total lack of prior experience in using assembly language.

The difficulty I encountered was in finding more senior personnel -- people who could keep the project under at least some semblance of control, and weren't completely accustomed to languages that would provide (and largely enforce) the guidelines necessary to keep the code reasonably maintainable and understandable.

Looking back, I may have been/caused some of the biggest problem in that respect. I can see two sources of problems on my part. First, by the time of the project I'm thinking of, I'd been coding primarily in higher-level languages for quite a while, and using assembly language only as a last resort. As such, when I did use it, nearly every possible trick to gain performance was not only fair game, but expected. Second, back when I had worked on some systems written entirely (or primarily) in assembly language, it was under some rather iron-fisted project managers. At the time I'd been relatively young, and quite frankly resented the way they'd run things, so tended to do the opposite. In retrospect, what they were doing really was important, and not done just because they were old and inflexible (which, I'm pretty sure was how I saw things at the time).

share|improve this answer
    
I have fond memories of TASM and Orca/M assemblers =) –  Patrick Hughes Jul 26 '11 at 4:11
add comment

in my opinion assembly as a development platform may not be relevant for everyday use. the main reason for this opinion may be because the amount of computational power that is removed from a given process Versus the amount of development time needed to optimise the same given process usually is not worth the time and energy (there is a specific term for this.. it sounds like man/hour or something..please edit if you know what i speak of..) there are the obvious exceptions mentioned above but as far as mainstream programming goes assembly is not used often.

this being said..assembly is still relevant today when learning programming in the context of software engineering studies,it teaches what a low level programming language looks like feels like and behaves. i'll go on and give the example of what we use in class these days. we use the pep/8 assembly that is developed by Stanley Warford (Pepperdine University USA) and its open source software given here. mainly used because it virtualizes the cpu and shows the memory contents while stepping through the code while it's running (quite useful for learning,debugging).

So depending on your usage assembly may or may not be relevant in my opinion.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.