Slashdot Mirror
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."
I work for Midway Games.
Many programmers here have only used assembly. Virtually all of the coin ops have been 100% assembly up until very recently.
Assembly is still used on all machines on all platforms in the rendering system - there's no other way to get the performance you need.
Some systems, like the Playstation 2, don't even have a C compiler available for two of the four CPUs.
Well, are you smart enough to spell "British English"?
Except, perhaps, the ones at Bletchley Park who are part of the reason you aren't spending your life bowing and scraping to some S.S. thug.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Infidel! This only works on DOS/Windows systems!
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I have to admit that I've not followed the link, so apologies if I am making incorrect or redundant statements here.
I suspect that a human's insight might be mainly which parts are worth optimising.
Given the devlish difficulty in hand scheduling and hinting assembly code for modern processors, I wonder if the proper thing isn't to write a superoptimiser. Optimal register allocation and instruction choice is NP complete, so the only way to solve it in some cases is exhaustive search.
I'm envisaging a system where human input is basically which code blocks to superoptimize and leave the computer to chug away at it overnight. Perhaps genetic algorithms (with test data to check for valid executions) would work?
Has this ever been attempted?
I thought c-- was pointer artithmetic-less, which would make it impossible to write self modifying code? Unless you're suggesting some staged programming techniques?
Is there even a compiler for c-- yet? I was under the impression that it was still at the proposal stage.
But the human always has the advantage that it can use the computer's insights, so therefore the humans code should always be at least as fast as the compiler, if they're humble enough to use the compiler's output whan it makes sense to do so...
y /f wd/fwd.html
;-])
Read the art of assembly language programming for a good intro for this debate:
http://webster.cs.ucr.edu/Page_asm/ArtofAssembl
I personally know assembly, and only use it when doing intensive 2d graphics stuff, but just knowing how the machine works so that all your coding is improved is the best reason to know assembly. Use it when it makes sense(which for me is after C coding, optimizing algorithms, and profiling... Coding in straight assembly just ain't worth it for the machines I work on [well, except for my TI-85 programming endevours
Blessed are the pessimists, for they have made backups.
I started programming originally on a 48k, rubber keyed, Spectrum. After finding the BASIC too limitting I progressed to z80 machine code.
After that when I was first exposed to PC's I wanted to find an assembler straight away. (Not having ever heard of C/C++/Perl by then - I was only 16 or so ;).
I wrote major, single-person, projects in pure x86 assembly language. Nowadays I wouldn't dream of doing that any more - but I have written Win32 programs in pure assembly; just to see if it could be done easily...
One of the few times I ever bother with assembly language nowadays is when I'm decompiling drivers - to reverse engineer protocols, and the like. (eg. My attempt at a Linux driver for the MPIO MP3 player).
As I'm interested in security I occaisonally find an exploit of my own, and being able to code in assembler is pretty essential for this.
I have to say that even if I never used assembly language again I'm so glad I learnt it, because it really has helped me understand how computers work; something that the current generation of programmers, fresh out of college, miss .. IMHO.
(Recent graduates seem to think the computers talking greek when presented with a stack dump/core file... I find that very depressing.)
Steve
---
do you have a link to these "Finnish assembly competitions"? sounds pretty cool..
----
---- I made the Kessel Run in under 11 parsecs.
- The compiler yields code of sufficient speed and compactness for the intended application.
- Precise control of execution time is not required.
- The additional difficulty of designing, coding, documenting and testing an assembly-language implementation is not warranted by the benefits; it is far cheaper to throw more CPU cycles at the problem than more man-hours.
I can write code that's tighter than an IRS auditor's asshole, and I'm damn proud of it. I still don't pretend that what I do is the way everything should be done. There is a time to throw hardware at the problem because hardware is cheaper than software, and that cut-off point in the PC world changes by half every 18 months. If you aren't in the PC world, your tradeoffs are different. That's life.--
Knowledge is power
Power corrupts
Study hard
Time is Nature's way of keeping everything from happening at once... the bitch.
Assembly is very much alive and well with microcontrollers, especially the 8 bit micros (PIC, AVR, Scenix/Ubicomm, etc.). C is making inroads, but for any sort of optimization, you still need to be able to look at the code the compiler generates and understand what it is doing. This is very important when you are trying to deal with low latency interrupts, tight timing loops, and small memory sizes.
For the most part, developing in a higher level language is faster, more robust, and a heck of a lot easier. Knowing assembly greatly enhances the understanding of what the computer is actually doing, and how the computer is doing it. If speed and size are important, do assembly. The speed on many applications is strongly limited by I/O- it doesn't make as much sense to use the considerable strength and difficulty for those type of applications, but if you're trying to do real time DSP, the speed of assembly, especially when dealing directly with fast I/O, is very valuable.
It really is a matter of using the most appropriate tool for the job. High level languages do a lot of things very well. Assembly also does many things very well. C can map very closely to assembly in some circumstances. Any sort of programming language is just a layer between your ideas and the op-codes that the computer executes. Assembly is just a bit more precise, like a surgeons scalpel, compared to the dull broadsword that is Visual Basic. Insert your own cutting implement metaphor for your favorite language.
I'm sure assembler still makes sense for mass-distributed desktop video and mega-production videogames, but the uses for it are getting more limited. A good algorithm, data alignment strategy, caching strategy, and pre-calculation strategy can be expressed well enough in C/C++.
And as a side note, even for my modern rare uses of assembly I try to use the in-line assembler since assemblers are no longer the staple tool that every developer has installed.
And as another side note, I laugh at people who try to get their processor faster by another 10%, 50%, or 100%. If these people would learn to optimize code, they could speed up by 20,000%.
I know that in the days of forking webservers, perl cgi scripts, and relational databases the idea of performance is considered somewhat unimportant, but there are cases where it really does matter.
For example, when you're running calculations which would take ASCI Red a couple weeks.
Yes, there are optimizing compilers out there. Yes they do a good job on some systems. No, they don't come within a factor of two of the performance well-written assembly code achieves on x86 processors.
Programming in assembly is slow work. To optimize code well it will often take a few hours per instruction. (I've spent weeks optimizing 50-instruction loops). But if you're going to have a calculation running for several months, it is worth it.
Tarsnap: Online backups for the truly paranoid
I know that Quake 3 uses assembly code to optimize some things...I know that on the Mac they (either Grame and/or John C) have rewritten the assembly portions which supposedly has resulted in a significant speedup (They just need to release the code so WE can find out for ourselves :-) )
Doh!
0CA5:0100 B402 MOV AH,02What does it take
0CA5:0102 B249 MOV DL,49to convince the
0CA5:0104 CD21 INT 21lameness filter
0CA5:0106 B44C MOV AH,4Cthat this is ok?
0CA5:0108 CD21 INT 21(Too many caps indeed)
Actually, you're quite wrong. First, note that I said "instructions", not "cycles". All modern processors provide a test-and-set or compare-and-swap instruction. So it does not depend at all the architecture. RDBMS locking is not done at the OS level -- that is FAR too much overhead. An RDBMS maintains its own locks, its own file structure, etc. Typical instruction-count costs for seeking through a highly-optimized B+-tree, doing a hash join, or marking a page as "dirty" have not changed since the introduction of virtual memory support in hardware, and neither has the cost of setting and releasing locks. Furthermore, for a scalable system, the cost times for updating those locks need to be as Gray said.
Kindly find someone else to troll, or perhaps ask your parents to buy you the newest Quake game if you're really frustrated.
Although the upcoming AGB is likely to diminish that pool of coders back to near extinction, the Color Game Boy has probably been one last "hurrah" for the bare-metal game programmer. I've optimized cycles and opcode bytes on the thing (older gb first) for a decade - I hand converted line-by-line the 6809 source code for Defender & Joust to run them on the Color Game Boy. So I say, we're still out here. For a little while. (The AGB supports C++, woo hoo!)
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
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
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
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
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
Time is Nature's way of keeping everything from happening at once... the bitch.
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
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):
or as a macro: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. =)
the good ground has been paved over by suicidal maniacs
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)
f wd/fwd.html
/.!
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/
-=-=-=-
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
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra