Slashdot Mirror
Is Assembly Programming Still Relevant, Today?
intelinsight asks: "Consider the following question given the current software development needs, and also the claims of the Assembly lovers for it being a language that gives one insights of the internal working of a computer. How relevant or useful is it to learn Assembly programming language in the current era? "
I'm glad I took assembly. I've never "used" it in the traditional sense of writing an application other than in school, but understanding how things work "under the covers" (whether at the CPU, hard-disk or network level) has provided valuable guidance in day-to-day design and troubleshooting.
I've worked with people with very focused high-level programming skills and found that while they could write mostly decent code, their code was also most likely to fail in production since they were completely mentally removed from concepts like disk-seek times or bandwidth constraints. Programmers with a deeper understanding of what actually happened when their code ran tended to make wiser programming choices.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
One day won't there be little nanobots floating around with 512 bytes of memory and a 1 mhz processor that need to buzz around your body and eat up your precancerous cells? I imagine as things get smaller, the miniturization fronteir of computing nescesitates limitations in computing power and memory. This may necesitate a new generation of assembly programmers. Even today in the minituarization/embeddedness/realtimeyness world where many enjoy programming away in plain old C (like me) that knowing assembly is useful. First to look at the compiler's output and figure out what the hell its doing, second to just have a plain basic understanding (not necesarilly a detailed one) of what your C statements/operations/etc is probably turning into in assembly instructions.
Another question, would assembly be more popular if it wasn't such a nightmare to write for Intel's x86 architecture? If we all had nice Motorolla PCs, would assembly be really cool?
Here are a few reasons you might need proficiency in assembly language:
I know far too many programmers who haven't a clue what is going on under the hood, so to speak, and have zero comprehension of what operations take longer than others. For instance, consider a C programmer I know who thinks strcat is a good routine to use.
(For the ignorant, it takes two string pointers and copies the second one to the end of the first one; this requires zipping all the way from the start to the end of the first string to find where said end is. It then helpfully returns the pointer to the beginning of the first string, the very parameter you passed in. Never mind that the new end of the first string would be very handy for the next strcat to that same string.)
This programmer is generally good at what he does, but the idea that strcat is woefully inefficient is not obvious to him. Even after explaining it to him, yes he will avoid it, but he does not really understand why. He, and far too many other programmers, measure their program's "speed" in lines of code. Sure, they know that a subroutine call has to count those subroutine lines of codes as well, but they simply have no concept of the fact that some operations take longer than others, that there are better ways of doing simple things.
I think every beginning programmer should have to spend a semester on some funky old z80, for instance, all in assembler, debugging in machine language, before they can call themselves a good programmer. The idea is not to get them skilled in z80s, but to give them a basic idea of how computers work.
It's the equivalent of learning to drive a stick shift car without understand why there are gears at all. If you are ignorant of the very basics of internal combustion engines and can't understand the dangers of lugging or redlining an engine and the importance of using the right RPM, you will never be a good driver. It matters not whether you ever drive a stick in real life, it's just a matter of knowing how to handle your equipment.
Infuriate left and right
We're in the process of doing a SOC ASIC, with a 32 bit CPU, analog sensing hardware, USB and other communications ports, sophisticated low power wakeup mechanisms, and RSA/AES/SHA-256 hardware. It only contains 32KB of ROM and 12KB of RAM. We expect the part to require less than 10ma of current in full-scale operation (generating 1 MB/sec of encrypted sensor data). We expect the parts to sell for less than $3, including several bits of external hardware, into a highly competitive marketplace. If our parts cost $0.10 more than our competitors or take 10 ma more current, we're out of business. We expect to sell millions of parts per month.
ROM and RAM comprise the largest space on the die. Die cost is about linearly proportional to area - doubling the size of the die doubles the cost. As a result, we don't have the luxury of embedding Linux, throwing a couple more MB of RAM at the problem, or increasing the clock speed. We certainly don't have the luxury of throwing this weeks latest, greatest academic language at the problem. 'C' and Assembly is the only way this product is going to survive.
I think you can be a fine Web programmer without knowing assembly or 'C'; I think you'd be a better one after one assignment to a project like mine, where every design decision is made and every line of code is written with a thought to "how fast is this going to run, how much code does this generate?", rather than "how do I get this done fastest and easiest?". There are many situations where the "throw more hardware at it" approach is valid; there are also many situations where it isn't.
And the worms ate into his brain.
I have always wondered what would have happened if the idea of using Lisp as the assembly language of a machine had actually taken off. If I understand the Lisp machines correctly, they were actually "lisp on the metal". Given the flexibility and power of the lisp language it would have been very interesting to see what the evolution of the Lisp Machines would have been, had they proved viable in the long term.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Knowing about optimising registers, partitioning the stack, minimising movs, and assembly tuning in general doesn't rely on the same concepts at all.
.net framework would be a major benefit and you cannot do that without an implicit understanding of assembler.
The GP is 100% correct in its uses and you are also correct that its current use is crap.
We have abstracted ourselves far enough away and insulated ourselves so much that I think we are in danger of losing the point of fast computers.
Anyone with visual studio can get a good example of this if you see how long the immediate window takes to calculate 1+1.
It might be great and super and empowers the developer to do more, but something has been lost that I feel Visual Basic classic is fast in comparison.
Finding a decent optimisation of the core
Every time this kind of discussion comes up I think of Mel.
Assemblers are a dying breed but their services are more than needed even today.
liqbase
Not all of us. I'm majoring in EET/ComET at ODU (they didn't offer the pure EE via distance-learning) -- and we're required to learn PIC assembly at least.
Granted, PICs are much MUCH simpler than anything running a modern OS -- but learning assembler, even on a simple device like a PIC, does teach a lot about how hardware and software integrate. Also, it's kind of cool to know that (for example) exactly 1,000,000 clock cycles after the program starts up, it will be calling *this* instruction, which moves the value in the accumulator to *that* register.
I can't be the only one out there who finds this extremely refreshing after taking a course in Java (and learning about font objects, GridBagLayouts, and other things so far removed from "real" programming that they might as well call it a Fine Arts course), can I?
Anyway, I wasn't really looking forward to learning Assembler -- until I got started and saw how powerful, elegant, and just plain beautiful it really is.
PICs are cool toys -- 5MIPS ain't much compared to the latest and greatest Intel and AMD have to offer -- but when you consider that they'll run for days (weeks? months?) on a CR2032 cell, and cost under a buck apiece, they're very impressive. (Freescale MCUs, too -- although I don't yet know those quite as well.)
Paleotechnologist and connoisseur of pretty shiny things.
You're writing software for a low-speed or low-memory chip for an embedded system (e.g. one of the PIC chips). Such chips are used either because they are cheap or because they need very little power. You can often program these chips in some variant of C, but if you need that last drop of performance, you use assembly.
You're writing software for any chip, on any platform, that requires direct hardware level access, e.g. device drivers, boot code, or core-features. No machine, no matter how fast can be programmed exclusively in C. For example, in C you simply cannot a DCR on a PowerPC. You need a special instruction w/o a high-level language equivalent. You can't cast a pointer to a physical address, it is not mapped to physical memory. You also cannot enable, or disable instruction cache from any C function call. The list goes on. There are a number of places it is totally impossible to use a high level language to do things.
There are a whole lot of these out there, in the consumer, enterprise, military, etc.
OK, First of all I'll blow my own trumpet. Over the last 20 years or so I've programmed 6502, Z80, x86 (16/32/MMX/SSE/SSE2), ARM and various proprietory SIMD & RISC machines and pseudo-MIMD machines. TBH the payoff for these skills simply isn't worth it.
;-)
As an asm coder I _may_ find a full time job but asm will take as little as 10% of my time. Contract asm work is out of the question and I haven't seen any in years (since I wrote a serial port driver for Win3.1). I actually like programming in assembler but for the sake of my pay packet and career I have reskilled in PHP, MySQL, CSS, XHTML, JavaScript etc simply because I can find contract work that pays well. Something that appears unachievable with asm. Maybe this is why we are a dying breed.
Lastly, you're right. This discussion crops up so frequently on BBS's, Usenet etc. It seems that the answer must be that asm coders are still needed and asm is still relevant! If they weren't why would we be discussing its relevance!
Incidentally, if anyone would like to hire an asm coder who like asm mail asm@burnttoys.net
Time flies like an arrow. Fruit flies like a banana.