Who Still Codes In Assembler?

rednax asks: "We see a lot of discussion on /. regarding many 'high level' languages (PERL, Python and JAVA for example are all well covered) rather than assembly language. There are a few exceptions such as this discussion from waaaay back when, which touched on it. Assembly level languages obviously have a place in all systems at the lowest level to provide basic services, but what about other areas. Obviously there are trade offs. Speed and compact object code are the two main arguments for assembler, but how much do these matter when we can get 1GHz processors, and large amounts of RAM? How many /.ers do use assembler, and what for?"

"Obviously assembly code is needed in embedded systems - I do not mean embedded Linux systems here, but rather the specialised, dedicated processor systems that do control work. Gibson research is one of the few advocates for programming down at the bare metal level that I have seen recently, and I think his products show what can be done in an incredibly small space, when Assembler is used. This too is one of his works."

Comments

Same as the Linux kernel, for raw system-level

[BitMan]

In most modern, general-purpose programs, assembler has rarely been used to "increase performance" over traditional program language code -- with rare exceptions going to heavily used functions that a profiler might pick up. And even then, most assembly is part of a larger program and a fraction of the total code -- usually in-line in the high-level language, or a self-containted object referenced by the other high-level language code. But even then, today's compilers are good optimizers and can even best you on your assembler if you don't know what you are doing.

No, for the past decade, assembler is still in use for raw, system-level details. Just like the Linux kernel, some things need to get done with GAS. Even NT's init loader is like this as well.

Most CS and engineering programs still teach assembler not to be proficient, but to understand the machine code v. man code relationship. It's not a full-up course where you write programs only in assembler -- in fact, I had a class on system-level programming where I wrote an assembler in C and binutils (lexx, awk, etc...). Why? It taught me not only assembler fundamentals, but the concepts of machine code and organization, basic parsing, hash tables, referencing and other concepts -- all in one course, in a very practical manner!

No, people why say "why code in assembler anymore?" are the people who continue to fail to understand why assembler ever existed. Heck, even Cobol and Fortran were available in the 50s! It was rarely a matter of "speed", but the fact that speed and size are "real-world constraints" at the system-level.

-- Bryan "TheBS" Smith

Re:Quake 3 - id found new "Pentium Optimizations"

[BitMan]

With the Quake series, idSoftware found the Intel 32-bit integer loads from memory to 32-bit general-purpose register to be piss-poor slow. With a little tinkering, they found that on the Pentium, loading two 32-bit integers into a 64-bit floating point register, and then moving those integers from register to register was much faster. Why? With the Pentium, Intel really worked hard on FPU to bring it up to more common RISC-implementation performance (the 80x87 ISA has always been a poor FPU implementation, remember Weitek? ;-), and created a well pipelined FPU in the Pentium (over other x86 processors at the time). Pipelining means that more than one instruction can be worked on by a unit simultaneously -- if similiar instructions follow one another.

Most fast, interpolated 3-D geometry usually involves sets of regularly, well-timed, memory loads of four to sixteen (4-16), 32-bit reads for each operand into registers (usually 1x4 or 4x4 matrix of 32-bit, interpolated integer coordinates in 3-D space). Again, loading through the traditional integer opcode was piss-poor slow -- and id, again, found that the new Pentium chip offered a "workaround" via its new, pipelined FPU.

Because this was "unorthodoxed", most compilers simply did not implement this. If you tried to read integers from memory, it would use the integer load opcode. So idSoftware had to write their own replacement memory read/write routines and functions. Undoubtably, this was done easiest in assembler.

BTW, this "Pentium optimization" was why the first generation of AMD and Cyrix processors lagged in Quake performance. Not because their FPU "sucked", but the idSoftware optimizations relied on the performance of a pipelined FPU -- not something AMD or Cyrix had in their first generation of Pentium ISA-compatible products. In fact, AMD's K6 (Nx686 core) had an excellent, non-pipelined FPU that was faster at execution -- provided your program was comprised of random integer/ALU, FPU and control opcodes. And if idSoftware would have just left the regular integer load in, the K6's integer memory load was upto 3x faster than the non-MMX Pentium and would have smacked the Pentium silly.

-- Bryan "TheBS" Smith

Where you really find assembler

[Tau Zero]

There are hordes of devices and sub-devices (modules in larger devices) where a MB is the designer's wet dream. Look at your car. Going forward from the trunk, you might have a CD player in it with a micro with between 4K and 32K of program ROM in it. Beneath the driver's seat is a memory-seat controller module which runs in 8K of ROM and 224 bytes of RAM, plus a little EEPROM. In the front doors there are a pair of modules which read switch inputs, control the window, door lock and mirror motors, and read back status/failure information on all of them. The instrument cluster has several microcontrollers, the overhead console trip computer has another, the electronic climate control another (probably 32K for a sophisticated one), the body controller another one... The larger modules are increasingly programmed in C, but the smaller applications still have parts (if not the entirety) written in assembly code getting down and dirty with the metal.

Appliances may have teensy-weensy little microcontrollers in them. Some of them have as little as 256 bytes of program ROM. You aren't going to get much of a C program into that, but assembly can do quite a bit.

Okay, I'll quit the mine-is-smaller-than-yours code-size contest now. ;)
--
Knowledge is power
Power corrupts
Study hard

lots of folks -- but you don't see it

[Socializing Agent]

The Solaris kernel is between 10-15% fine-tuned assembly language. You think Duff's Device is odd? Wait until you see the Solaris bcopy() routine. It's like a switch statement without labels, except harder to understand.

Also, RDBMS vendors will likely always use assembly. The locking code for an RDBMS needs to operate in fewer than 100 instructions to guarantee the possibility of concurrency -- and that includes deadlock detection. Furthermore, the "latches", or internal locks on the buffer pool, etc., must execute in under 10 instructions.

Assembly language is important, especially since highly-optimized C code is faster than unoptimized C code by a factor of 5 or more. How do you think that those optimizations get into the compiler? Sure, no one writes applications -- or even, at this point, games -- in assembly, but today's processors are so complex that

• You NEED to hand-optimize some speed-critical things
• A simple syntax-directed translation scheme is more inadequate than ever for today's compilers -- if you're writing compilers, you really get to worry about speed.

Re:You don't code in assembly!? (long)

[ksheff]

Your tolower code doesn't work. ORing a value with itself, produces itself (that and you are assigning ch[0] to be 'Z' in the if statement). This is probably what you wanted (assuming input is ASCII):

if ((c >= 'A') && (c <= 'Z')) c |= 0x20;

or as a macro:

#define TOLOWER(c) ((((c) <= 'A') && ((c) >= 'Z')) ? ((c) | 0x20) : (c))

However, you wouldn't want to use the macro if it was evaluating a function or math expression, since that would get evaluated anytime (c) was actually used. The original mistake was probably due to your 4:45am posting w/o sleep. =)

You don't code in assembly!? (long)

[Sivar]

Most programmers that I consider truely skilled still use assembly for a variety of tasks. Many things are MUCH easier to do in assembler than in any high-level language (Just try writing self-morphing code in C--And yes that is useful, it is very difficult to crack self-morphing programs)

Assembly language is control. Control over every instruction that the processor recieves. Control over every byte of memory that is shifted throughout memory.
You can control the exact number of bytes that your program occupies.
You can make TINY programs.
How about a webserver in under 600 bytes? (Granted, it can't outperform Apache...) How about a GLibC clone in under a meg? I have seen demos from the Finnish assembly competitions that included such feats as real time raytracing of a translucent sphere on a 386. How about much of the first level of Interplay's Descent in exactly 4096 bytes? (Including music!)

Want to talk to hardware, directly, without any overhead? Try accessing the 64-bit register that counts the number of clocks so far on modern IA CPUs without ASM. You can't do that in an HLL because nobody has done it for you yet. HLLs are largely about piecing together others' work into a new pattern. In ASM, it's just you and the CPU.

Many people also use assembly because it is also great for people who want to not only code a program, but actually know how it works. you can write a program in C you say? Or PERL, Eiffel, or whatever? I consider using function calls cheating in a way. Did you write any of those standard C functions that you are using?

If not, did you really write that program, or did you simply arrange the smaller programs of others (functions) in such a way that they work differently than the particular arrangement of another person's program.

(I'm not saying that function calls are bad--they sure speed up development--I am trying to make a point about assembly)

As an added benefit, those who code in assembly are generally better at coding in HLLs because they know better how those HLLs work. Knowing how they work means being able to write faster code. For example, if you are using a language that has no tolower() equivalent, you can write something like:

switch(ch[0]) {
case 'A':
ch[0] = 'a';
case 'B':
ch[0] = 'b';
...etc...

The coder that learned how his system works at a binary level might choose the much faster:

if((ch[0] >= 'A') && (ch[0] = 'Z')) ch[0] = (ch[0] | ch[0]);

The bitwise OR doesn't even take a clock cycle to execute (but admittedly it is harder to read)

discLamer: I'm not trying to tell anybody that their HLL coding skills are unimportant or easy. I'm not saying that HLLs are bad. (My favorite language is C). I am saying that many very skilled programmers still use assembly because it is very good at certain things that no other language can do well or at all. I am also saying that assembly is not dead. Just unpopular. I am also posting this at 4:45AM and have had no sleep or caffiene for quite some time. Just ignore me.

Here are a some answers to some common complaints about assembly language blatantly stolen from Randall Hyde's book, "The Art of Assembly Language Programming." If you are interested, the whole book is freely available at http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/f wd/fwd.html
-=-=-=-

Assembly is hard to learn.
So is any language you don't already know. Try learning (really learning) APL, Prolog, or Smalltalk sometime. Once you learn Pascal, learning another language like C, BASIC, FORTRAN, Modula-2, or Ada is fairly easy because these languages are quite similar to Pascal. On the other hand, learning a dissimilar language like Prolog is not so simple. Assembly language is also quite different from Pascal. It will be a little harder to learn than one of the other Pascal-like languages. However, learning assembly isn't much more difficult than learning your first programming language.

Assembly is hard to read and understand.
It sure is, if you don't know it. Most people who make this statement simply don't know assembly. Of course, it's very easy to write impossible-to-read assembly language programs. It's also quite easy to write impossible-to-read C, Prolog, and APL programs. With experience, you will find assembly as easy to read as other languages.

Assembly is hard to debug.
Same argument as above. If you don't have much experience debugging assembly language programs, it's going to be hard to debug them. Remember what it was like finding bugs in your first Pascal (or other HLL) programs? Anytime you learn a new programming language you'll have problems debugging programs in that language until you gain experience.

Assembly is hard to maintain.
C programs are hard to maintain. Indeed, programs are hard to maintain period. Inexperienced assembly language programmers tend to write hard to maintain programs. Writing maintainable programs isn't a talent. It's a skill you develop through experience.

Assembly language is hard.
This statement actually has a ring of truth to it. For the longest time assembly language programmers wrote their programs completely from scratch, often "re-inventing the wheel." HLL programmers, especially C, Ada, and Modula-2 programmers, have long enjoyed the benefits of a standard library package which solves many common programming problems. Assembly language programmers, on the other hand, have been known to rewrite an integer output routine every time they need one. This book does not take that approach. Instead, it takes advantage of some work done at the University of California, Riverside: the UCR Standard Library for 80x86 Assembly Language Programmers. These subroutines simplify assembly language just as the C standard library aids C programmers. The library source listings are available electronically via Internet and various other communication services as well as on a companion diskette.

Assembly language programming is time consuming.
Software engineers estimate that developers spend only about thirty percent of their time coding a solution to a problem. Even if it took twice as much time to write a program in assembly versus some HLL, there would only be a fifteen percent difference in the total project completion time. In fact, good assembly language programmers do not need twice as much time to implement something in assembly language. It is true using a HLL will save some time; however, the savings is insufficient to counter the benefits of using assembly language.

Improved compiler technology has eliminated the need for assembly language.
This isn't true and probably never will be true. Optimizing compilers are getting better every day. However, assembly language programmers get better performance by writing their code differently than they would if they were using some HLL. If assembly language programmers wrote their programs in C and then translated them manually into assembly, a good C compiler would produce equivalent, or even better, code. Those who make this claim about compiler technology are comparing their hand-compiled code against that produced by a compiler. Compilers do a much better job of compiling than humans. Then again, you'll never catch an assembly language programmer writing "C code with MOV instructions." After all, that's why you use C compilers.

Today, machines are so fast that we no longer need to use assembly.
It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware. There are many raging debates about the speed of machines versus the speed of the software, but one fact remains: users always want more speed. On any given machine, the fastest possible programs will be written in assembly language.

If you need more speed, you should use a better algorithm rather than switch to assembly language.
Why can't you use this better algorithm in assembly language? What if you're already using the best algorithm you can find and it's still too slow? This is a totally bogus argument against assembly language. Any algorithm you can implement in a HLL you can implement in assembly. On the other hand, there are many algorithms you can implement in assembly which you cannot implement in a HLL.

Machines have so much memory today, saving space using assembly is not important.
If you give someone an inch, they'll take a mile. Nowhere in programming does this saying have more application than in program memory use. For the longest time, programmers were quite happy with 4 Kbytes. Later, machines had 32 or even 64 Kilobytes. The programs filled up memory accordingly. Today, many machines have 32 or 64 megabytes of memory installed and some applications use it all. There are lots of technical reasons why programmers should strive to write shorter programs, though now is not the time to go into that. Let's just say that space is important and programmers should strive to write programs as short as possible regardless of how much main memory they have in their machine.

Assembly language is not portable.
This is an undeniable fact. An 80x86 assembly language program written for an IBM PC will not run on an Apple Macintosh. Indeed, assembly language programs written for the Apple Macintosh will not run on an Amiga, even though they share the same 680x0 microprocessor. If you need to run your program on different machines, you'll have to think long and hard about using assembly language. Using C (or some other HLL) is no guarantee that your program will be portable. C programs written for the IBM PC won't compile and run on a Macintosh. And even if they did, most Mac owners wouldn't accept the result.

Don't flame me too much... This is my first post on /.!

sivar@NoSpam.email.REMOVE.com