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? "
It's good to know how things work underneath the hood.
Isn't knowledge of assembly language for microprocessors required to create a higher level programming language?
Previewing comments are for sissies!
Please remain ignorant of all lowlevel details of your deployment and development platforms.
Please continue to treat both computers and the tools you use to program as magic black boxes.
That way old dogs like me will still have a job.
How we know is more important than what we know.
Nobody has to learn assembly language anymore to create piddly things like compilers or program ultra-small devices or anything like that. You can do all of those things with Ruby on Rails now.
For good programmers, yes.
Hire someone else to code in assembly.
If you know DSP, are adept with fixed point arithmetic, know a bunch of fun tricks, can schedule well... there are many people who would like to hire you. Including the group I work in.
Simply, compilers cannot produce code of the same quality that great hand coders can produce code, especially for complex embedded devices like DSPs. But it's not enough to know how to write assembly, you need to know all the tricks the compiler knows, all the tricks you can play with the algorithm, and all the ways in which you can tinker with the code to fit it nicely into the architecture.
Those things are still highly valueable; people need to get really optimized code for their media players. If you can squeeze 20% out of your MP3 decoder, you can get 20% lower energy usage on your programmable logic.
-- Erich
Slashdot reader since 1997
You really only need to know how to program assembly if you want to be a good programmer. If you want to be a crappy one, learn Java or C#, pretend pointers are magical, and be happy with your life. (I'm not saying those are bad languages, I'm just saying they're opposite from assembly)
Also, a lot of embedded work is still done in assembly because with a lot of low-level industrial work having very precise clock-counts on everything is very important.
-Bill
Well, given that the world runs on embedded systems, and will probably become more reliant on even greater numbers of even more complex embedded systems, I'd say assembler will be around for quite a while. However, in terms of game programming or something, it's probably not amazingly useful any more. It is my understanding that most of the API calls to advanced graphics libraries are about as optimized as they are going to get. Clearly you don't need it to write a medical billing application.
I would not encourage universities to start pumping out CS graduates who have never seen assembly laguage, and don't expect it to phased out of the average Electrical Engineering curriculum any time soon.
Frankly, I don't think it's a very good question. It's sort of like saying, "Given that we now have calculators and computer algebra systems that will do the math for us, is it really worth it to waste students' time learning the nuts and bolts of mathematics?" It has been my (limited) experience in software engineering that knowing how something works on a deeper level will almost always be an asset, and at the worst have no effect at all.
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?
Do you write drivers? Or do you need highly optimized algorithms? What about really low level firmware stuff?
In other words, yes, there are good reasons for knowing assembly. Whether or not you'll actually use it is another matter entirely. Just depends on what you're working on.
Actually I wouldn't be surprised if in about 10-15 years assembly programmers are in higher demand since none of the CS schools these days ever teach assembly anymore.
Give me a moment. I've still gotta figure out the six nested timing loops I need to toggle the speaker cone in and out in such a way that it sounds like a cricket instead of a bird.
I just got a SDK-86 to start learning it!
Shiny. Let's be bad guys.
How do compilers know what to compile to? Magic? Imagine if all the assembly programmers died: who'd maintain & update compilers, embedded devices, many realtime instruments, etc. ?
Trolling is a art,
That's a pretty fine line there. If you can understand asm well enough to debug such issues, I would argue that you also probably know enough to write it, or at least very nearly so.
I would say that you need to know how to program in assembly language, though it doesn't really matter much which ISA you use---MIPS, x86, PPC, ARM, whatever. What matters is the ability to understand what's really happening at a low level so that you don't do stupid things in high level code that cause your machine to have a seizure.
For example, once you understand that your CPU only has a limited number of registers, you'll understand why (on some CPU architectures) it is a good idea to limit the number of function arguments so that they can be passed via registers, and that you should put the arguments that you are most likely to use at the beginning of your prototype so that they have the best chance of already being in a register.
Check out my sci-fi/humor trilogy at PatriotsBooks.
If you never learn assembly language, it's a very strong possibility that:
- You can't write a compiler
- You can't debug C/C++ programs
- You don't really know why buffer overflows are bad
- You don't really understand memory management and what the heap and stack really are
- You don't really know why threads are different than processes
- You can't write a device driver
- You don't know any computer architecture at any depth that matters
- You won't ever understand garbage collection
- You don't know how your CPU works
- You won't think the movies with "hacking" in them are as funny as the rest of us do.
If not being able to do those things doesn't bother you, by all means, don't learn assembly.
The thing is, in order to be a really good programmer, you have to know how the machine works, all the way down. Once you do, you can pick up any language very easily, because you know what they're trying to do and how.
Just learn it. It's really one of the simplest languages to learn. Realize it's not a programming language, but simply the actual machine code represented by mnemonics. So you'll have to learn an architecture. Intel 386 is a great place to start, and it couldn't be easier than on Linux. You have a flat, protected memory model, GNU "as" is likely already installed, and you make system calls using interrupt 0x80 after setting up the arguments.
You should be printing stuff to the screen within minutes, and interfacing with C object files in hours. You can write the GTK "hello world" program in a combination of C and assembly fairly easily.
Get to work.
If moderation could change anything, it would be illegal.
The best way is gcc --save-temps; write your c code and then understand what gets generated and how it differs depending on what you write in a language you're already familiar with.
I spent 6 months recently working for a company that programmed mainly in C++ and visual basic (I'm a mac programmer, so I was a fish out of water there, which is ultimately why I left...) But the developers there didn't / couldn't / wouldn't understand assembler in any way shape or form. Without the high level debugger, they were lost. So when their app would crash, they'd be helpless to understand how.
I was appalled. I've spent 20 years debugging crashes and even though I don't speak x86 fluently, I can at least find my way around it. How do people that aren't able to read assembler ever able to ship quality products?
Of course, the best way to learn it is using an interactive assembler: go back in time to 1998 and use TMON Pro with MPW. With an 11 minute link time, you'll quickly learn that its easier to patch your bugs in assembler and continue execution, or write a little subroutine in "playmem" to do something, rather than terminate your app, make a small change, and relink.
God I miss TMON.
Here are a few reasons you might need proficiency in assembly language:
Try the "Art of Assembly Language Programming" available free at this website http://webster.cs.ucr.edu/AoA/index.html it should get you started.
...that learning assembly will teach you is that a libc is really a convenience, rather than a necessity. If you know what you're doing you can accomplish pretty much anything either via system calls directly to the kernel, or by writing your own asm functions for various things (print, etc) and then simply calling *them* via includes. If you end up writing your own asm includes for things you'll still get some bloat, but I can guarantee you that it will be an order of magnitude less than using glibc. There are times when that can be valuable...like if you're needing a system which will fit on a floppy or usb stick, or for an older system with less ram etc.
I strongly recommend checking out asmutils if you want examples of asm programs that actually do something useful. Some of these (such as ls and the basic httpd) are less than 1k in size.
You might also be interested in Menuet, which is an entire (small) OS including GUI written completely in either 32 or 64 bit asm.
While I have not written any assembly since college, I am really glad I know it. As an engineer who works in C/C++, sometimes it is really helpful in debugging to see what is happening at the assembly level.
So, I would definitely recommend at least being acquainted enough with assembly so that you can semi understand a listing.
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.
There are limitations to what high-level languages can do. When I started out on the Amstrad CPC, I remember the computer booted up into a very inefficient non-standardised BASIC, which had many added commands which were really functions to allow access to the unique hardware of the CPC (sound and graphics). These were ridiculously slow, with the Z80 processor and 32K memory available for programs. If you wanted to make a simple animation for example (say, a little 2D sprite walking across the screen), you needed to do it in Z80 assembly language IF you wanted the computer to do ANYTHING else at the same time (e.g. scan for keyboard interrupt, play sound chip in background, or even just a second sprite).
x86 assembly language isn't hard, but it's the only way you're going to be able to play control freak with your PC hardware. Many excellent Linux applications are done almost 100% in assembly language, including the excellent SNES emulator ZSNES (which makes much the same demands on Linux as the old 8-bit Amstrad, and keeps perfect time). If speed is really important then there's no other way. For some reason I think secret organizations like GCHQ would employ skilled assembly programmers so they can keep looking for ways to brute force public-key encrypted messages in the shortest possible time.
In my opinion, a lot of people are able to use a few libraries in VC++ or similar to be able to make useful programs, and also new things like Python, Perl, etc. but that doesn't necessarily make them a "coder" just because they're able to use some built-in functions. To be a "coder" means you PREFER to use plain C, and know assembly language (even though assembly language is different for every platform - an assembly language programmer knows exactly what info he needs to find out re opcodes and registers and memory addressing and interrupts, to program his program with the same techniques).
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
First, I'll give the disclaimer that I am a hardware engineer, not a software engineer.
My experience has been that when bringing up new hardware, when you don't yet have a stable bootloader, let alone a compiler or operating system, then being able to write in assembly is very valuable.
More accurately I think I should say that being able to write in machine language is very valuable, as you might not even have a working assembler depending on what you are working on.
Being able to peek and poke a few registers, hand code a loop or two, and maybe write some sequential values across a bus can go a long way in helping you get the hardware going. Hook a logic analyzer to the bus and you're golden.
Even if you do have a whole infrastructure of compilers, device drivers, and operating systems available, none of that helps you when the first damn batch of prototypes (made of the first revision of the PCB, containing the first ever silicon of a new CPU, and the first ever silicon of the the new chipset) won't even boot, and you are trying to get to root-cause ASAP because you've got a whole army of testers ready to have at the hardware as soon as you get it running code.
In short, if you are the guy designing the raw iron that the software is going to talk to, you better be able to step up and take control of the raw iron when the software can't.
Knowing assembly language is like knowing how to an internal combustion engine works.
.NET, or web-based programming, knowing assembly language won't help much.
For most drivers, it's a curiosity.
For most auto mechanics, it's somewhat useful.
For anyone doing engine repair, it's very important.
If you are programming at a hight level like Java,
It's only when you are using a language like C where knowing how the chip works can actually help you write your code does it really matter.
Anyone doing systems programming, real-time programming, or anyone who needs fine control over their program's execution should learn assembly.
For non-programmers and very high level programmers, it's about as useful as studying Shakespeare or business law. It'll make you a more well-rounded person but it won't help your code run faster.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Now, if you were to ask "isn't knowledge of assembly language for a given microprocessor required to create a compiler capable of directly generating native code?" then the answer would be yes, because all the other possibilities have been excluded. Alternatively, if you asked "isn't quality knowledge of assembly language for a given microprocessor required to create a compiler that can generate code that is compact, efficient on resources and fast?" then the answer would also be yes.
However, as most modern programs are anything but compact, efficient on resources or fast, that is a rather moot point. The best compiler in the world can't turn junk into quality, although a trashy compiler can certainly turn quality into junk.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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
Frankly I think a good programmer is somebody who writes well documented and designed code. I don't think somebody's knowledge of the low level assembly programming necessarily helps with that. I'd rather somebody wrote somewhat inefficient code that I could read and, as needed, optimize, then have some spaghetti pile that nobody could understand but was lightning fast.
This sig has been temporarily disconnected or is no longer in service
I realize that assembly is very useful to know and can be useful in certain instances.
But writing in assembly has always given me the same feeling as eating rice with a single chopstick.
I stole this Sig
Seriously, assembly is important for all the reasons you noted, but also for some others. If you know assembly, the chances are:
All software engineering, computer science and programming courses should start by requiring people to program a non-trivial application on an ARM processor, or something with an equally limited instruction set, in pure assembly. Why? Because then you get people who think, who program with care and forethought, who think of bloat not in terms of adding more RAM, but in terms of opportunities for bugs, glitches and gremlins. Sure, you'll get more dropouts. The computing world doesn't need more code monkeys, so it's no loss if they did. Who needs a society of half-baked, semi-literate coders?
This is not elitism, because I'm not saying that anyone should be excluded from the profession. I don't think they should. What I do think is that society needs to make damn sure that the typical coder isn't the worst coder, which is what you get if people are trained to NOT think but to let the computer do the thinking for them. Windows may act like a HAL-9000 at times, but trust me, it isn't remotely capable of anything resembling thought. A bad design or a poor implementation will not be rectified by some magical intelligence in the machine, because there isn't any.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
from http://www.grc.com/smgassembly.htm
Huh? . . . Windows in Assembler?
Am I sick? Perhaps. Am I a dinosaur destined for early extinction? Yeah, probably. But I truly love programming. It's what I do. It fulfills me and sustains me . . . and I'm never in a hurry to "just be done with it." I can't stand sloppiness in my work, so for me that means writing the smallest, tightest, fastest, most economical computer programs possible. And THAT means authoring Windows applications in Assembly Language.
Though the rest of the world may argue that they're more "productive" (when measured by hard disk space consumed per second), I stand by the principle that: "Small Is Beautiful".
Nothing to CX here, MOV along.
Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
Hmm. Assembly is still relevant and useful for certain tasks, of course.
/David
But two things come to mind:
1: Handcoders can code better than good compilers?
Yeah, in some cases after a lot of refining. But it is not as easy as it once was.
Compilers have gotten much better and processors have gotten a lot more complex. It's not just "how many clock cycles does this instruction use?", you also have to take various forms of micro-parallelism (pipelining, branch prediction, etc.) and cache hierachy issues into account.
2: It's good to know what goes on under the hood, sure.
But in many, many software developer tasks, early optimization is the root of all evil.
I would actually much rather recommend a top-down approach for most problems, abstracting away low-level details, rather than going bottom-up. The teaching approach of the great "Accelerated C++" comes to mind.
A lot of developers that know a little or a lot about low-level programming write less than excellent code in other regards (algorithmic complexity, design, re-use, etc.) and they can't seem to stop focusing on performance throughout the process.
For most problems, performance isn't critical, and even when it is, it might be better to look for algorithmic enhancements (lowering complexity) rather than do low-level fiddling.
I see it this way: assembly is still used today, but only in a smaller niche. But that's not the only reason it's relevant. I think it's a good knowledge to have, even if you'll never use in practice, but it's concepts help you understand the whole. Much like Math, or basic Physics.
factor 966971: 966971
I think some assembly knowledge is important, at least to understand pointers.
But, shaders are hardly written in assembly anymore, for all the good reasons.
"La presi e te la pagai (480.000 Lire)"
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.
Communicating in Morse code. It's a pain in the ass to learn, but when you do, you find the rewards more than justify the effort spent.
:-)
Also, it's good to remember that Assembly language is just one more tool in a programmer's tool box. I wouldn't write throw-away scripts in Assembly language, just like I wouldn't use C. I'd probably use Perl, Python or shell script, as necessary. When you need to hand-tune that algorithm to get that last little boost in performance, being able to drop down to Assembly language can save the day. Too bad it is a dying art.
On another note, I agree with the other posters that said learning Assembly language allows you to learn the hardware better. 8086 Assembly language was my second language (after BASIC), and I used it for several years, until I started using Windows and found it was much easier to write a Windows program in C
No matter where you go... there you are.
They stare at the code for a while, make wild guesses about how the problem could have happened, add a lot of couts, and hope for the best. Seriously.
I think you're suggesting that for certain kinds of optimization it's as important to know about machine architecture and organization, I.e. things like cache associativity and size, relative speed of memory vs. registers vs. cache, etc., as it is to know or optimize the use of particular "assembler" (actually machine) language instructions. Good point. Still, if you want to know how many memory accesses either the presupplied strcat or your own alternative are going to issue, and which addresses they're going to hit, knowing machine language is a big help.
I saw that Francisco - You're getting a special
version of the Computer Org test tomorrow.
One just for you.
Your computer org professor.
:(){
I've found myself in need of CPU burn-in software. Tools I've found apparently weren't designed for multi-core systems, and that's the kind of system I need to push.
What I'd like to do is write a bunch of assembler routines that repeat different classes of instructions. One would run simple FPU operations several hundred times, another would run integer ops, another, logic ops, more would run mmx ops, sse ops, sse2 ops, sse3 ops, etc.
The program would poll the CPU temperature every couple seconds, find the routine that causes the greatest amount of heat, and concentrate on it.
The overall program would be a C/assembler hybrid. The burn routines would be in assembler, but the analysis and scheduling routines would be in C.
tasks(723) drafts(105) languages(484) examples(29106)
Answer to "What's hard about pointers?"...
There are people who cannot grasp the difference between "a thing" and "a respresentation of a thing". In fact, there was an entire century where almost the entire school of French philosophers were unable to grasp that there was a difference.
For pointers, it comes down to realizing that a pointer to memory is not the memory, it's a representation, and the real memory lives somewhere else: at the dereference of the pointer. And at that location it takes up real space. And so does the representation (but it's comparatively tiny).
The ability to make this disctinction comes naturally when you've written assembly code of any complexity, since you've had to manage the memory yourself. But if you've never done that, or, worse, you've only ever programmed in languages which eschew pointers and try to pretend that their own internal implementations don't use them, even if they won't let you use them, well, then, you've got a conceptual problem. An that conceptual problem is going to be very hard for you to overcome.
It also makes it very, very hard for someone to understand row-major vs. column major languages, or how you would link a program in one against a library in another, and be able to usefully communicate your data between the two. Or it makes it hard to understand the difference between "call by value" and "call by reference.
If I'm interviewing someone, and it becomes clear that they need a "code interview" because some things don't add up between their banter and their resume, the first thing I whip out is a pointer problem.
-- Terry
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're certainly right, but programming language extensions could get around these limitations. For instance, I think the PIC C compiler, which is not really standard C, has an extension that lets you write and install an interrupt service routine without any assembly. One could imagine such extensions for almost any hardware feature; it's just that compiler-writers rarely bother to offer such extensions.
Maybe, except that not many assembly programmers can make faster code than a C compiler anyway. It's no use being a mediocre assembly programmer.
You are too thoughtful sir. Thank you! Did I ever tell you how fabulous I think IBM assembly language is? You know, it has all those wonderful registers (yes, all 16 of them, if you count those 4 or 5 registers that you can't use). Ah well, I should know better than to post on Slashdot with my name about a subject on the eve of that test. If you answer this, don't just answer "Indeed". :) Oh, and I know you're going to show this to class tomorrow. Hi his class. :)
Anyway, enough that's enough of me mongering around on /. for today. Time to work on Calculus. See you tomorrow. :)
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C1 bottles of beer on the wall. Take one down, pass it round... Oh, umm...
There's no 'PIC C Compiler' for the PIC10F200.
It's basically a little grain of rice if you buy it in the surface mount package.
A fairly powerful little grain of rice at that.
As a marketable skill, assembly won't get you anywhere. There are a handful of places were knowing a specific assembly language is a prerequisite (boot loaders, deeply embedded applications, etc.) but these are just a fraction of the overall job-space for software engineers. Most software engineers never mess with assembly; they are, in fact, afraid of it and think that it's evil.
Given all of that, assembly language *is* the hardware/software boundary. It's where all of the fancy abstractions from CS dissertations meet reality. Understanding computer architecture is a huge asset as a software engineer, and to properly understand how software and hardware interact, you have to learn at least one assembly language. There is no alternative. For most people, it is an unpleasant experience, but the payoff is enormous. The learning process that you undergo while learning assembly will change the way that you see your software and will help you understand why your code is so slow and how to make it fast by design.
I have one last point. When you tell a potential employer about the low-level stuff that you know or work that you've done, your assembly skills are a proxy for understanding how hardware works (at least to interviewers with half a brain). If their software needs to run fast, they'll be happy that you understand the deep magic of hardware.
(Incidentally, I think that the fraction of software jobs that require an understanding of hardware and knowledge of assembly languages, linker internals, etc., are the only fun ones and the only ones worth having. So I learned MIPS, ARM, PowerPC, and TMS320C6 assembly, and they have all served me very well because I don't have to refactor C# for a living.)
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
As a guy who kept programming in assembler for many years after C was around, I would point out that BIOS code is often written in assembler becauses it is so low level and it gets used a lot, or at least it used to. Now days the operating systems take over most of the hardware after the system comes up, but in the original IBM PC, the BIOS provided the interace layer to all the hardware.
This is particularly true for programs that
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
> Real-time Raytracing (a myth, yes, but a good one nonetheless)
2005 called, they want their hardware back.
--
How can you understand Life if you don't even understand what happens after Death??
100% agree. There are a lot of missing features in C which require assembly nowadays :
:-(
- bit rotations => have to be coded by ORing bit shifts and masks
- bit counting (FFS/FLS) => have to be cleverly coded to avoid iterations
- locking => you need the lock instructions/prefixes of CPUs
- prefetching => idem
- memory barriers => idem
And the list is long. What do we do instead ? typically, bit operations are done by hand with 100 times slower operations and using jumps and loops while a single instruction almost always exists. Locking accesses is performed through calling functions from heavy and slow libraries such as pthreads.
It always strikes me to see code doing such a thing :
pthread_mutex_lock(&counter_lock);
counter++;
pthread_mutex_unlock(&counter_lock);
While in assembly you would be able to do this on many platforms :
LOCK INC counter
Which is basically what is done in the mutex_lock (with added tests).
We really need some C extensions to access the lower level, but unfortunately,
the trend is the other way
Willy
Assembly for shaders isn't written in stone. Graphics hardware is moving so fast that the concept of a fixed assembly for them is limiting. It's limiting for the hardware makers, limiting for the software developers.
One can always squeeze that cycle somewhere, but it doesn't make sense. The problem with shaders are different ones, like integrating them with CPU code and balancing between dynamic branching and code permutations (combinations of features in a shader are selected either with an IF or with a bunch of includes.. so to speak).
Knowing assembly for shaders is definitely not worth it in my opinion. I highly doubt anyone uses it in the game industry.
LUTs are very much used for common techniques such as PCF shadow mapping and what not in Cg and HLSL.
"La presi e te la pagai (480.000 Lire)"
]1 BIT $C030
]2 DEY
That'll give you one cricket-like chirp. Throw some more loops around it to make it repeat with the right cadence. :-)
(Remove the dots...they're there only to get the columns to line up.)
20 January 2017: the End of an Error.
Sorry, but that "multiplatform code" you speak of requires a lot of Assembly code under the covers. For the most part assembly is delegated to hardware integration, drivers, and performance tweaks. It is still vital to the industry... I will say that most developers have no need to learn it, but it is far from obsolete. C is still widely used for lower-level libraries and APIs, I wouldn't suggest it as a career path for most developers, but it's still pretty necessary.
Personally, I like higher-level languages that abstract a lot of the inner workings such as C#/.Net, Python or Java. I like to concentrate on solving problems or making things work. However without those that *DO* write in assembly, nothing I write would *RUN* anywhere.
Michael J. Ryan - tracker1.info
To consistently beat a C compiler: Write your code in C with inline assembly if required, then compile through Assembler to get assembler source code. Next, hand tweak the assembler code and add C as comments. Pretty soon you will start to think like a compiler and your C code will get better too!
I'm building my own computer (no, not getting some random PCI cards and plugging them into a motherboard), but designing a simple Z80 system for fun.
0 -Project-Pages/Image19.html
If you want to mess around with this sort of thing, you cannot avoid writing things in asm. I've got this far:
http://www.alioth.net/Projects/Z80/Z80-Project/Z8
- having laid out a double sided PCB, and got everything shoehorned onto a 160x100mm 'Eurocard' sized motherboard.
However, I've also retargeted the z88dk (Z88 Development Kit, originally designed for the Cambridge Z88 portable computer) to my Z80 board because while it'll be best to have all the low level stuff done in assembly language, writing things that use floating point will just be ten times faster to write in C.
But even if you never intend to hack hardware, it's still important to at least be familiar with assembly language - if only to know why unchecked buffers are bad. If you've ever written a program in asm and accidentally overwritten the stack and tromped all over your return address, you fundamentally understand why this is a bad thing. We've got into a whole world of hurt because many programmers didn't understand this.
Oolite: Elite-like game. For Mac, Linux and Windows
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?
Now I'm picturing something like Alfred Hitchcock's The Birds, only with ZX81s.
If you use Win32, you can use InterlockedIncrement( &counter );
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
One of the best reasons to learn to do assembly programming is because it's fun.
;-)
Though I can't say that's why I did it. In my case (back in the early fourteenth century), we all wrote assembly code because that's how serious programming was done. Sure, we had COBOL to update ledgers and write reports, and FORTRAN to take the hard work out of maths computation, but for anything that really needed any kind of optimisation on those old core-memory machines, assembly was the only way to go.
There were other reasons too; I worked in a computer bureau with several Burroughs B3700 machines, and we had one or two clients for whose packages the source code had been long since mislaid.
So rather than re-writing the thing from scratch whenever mods needed to be made, a couple of us used to hack directly on the binary. It's not all that easy, but it's job security.
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.
/., not many would want to admit to being a Group 2er but I have no problem with it. For example, Group 2ers would also know when a Group 1er's code sucked, from a performance standpoint. Coders with a trailblazer mindset are rarely good optimizers.
I'm not a great programmer, but I've always had a good "sense" (for lack of a better word) about technical things. I worked a bit at a company doing mid to high level (V)FoxPro programming. They put me on the least desired machine and I set to work. Within minutes I realized the machine was not running right, CPU at 100% or close to it most of the time. Turns out it was virus-infected (despite NAV, of course). I found the name of the EXE, renamed it in autoexec.bat before it loaded, then deleted same. Problem solved and the oldest 'clunker' became a quite acceptable computer.
I think this story illustrates the two broad classes of programmers. (1) those able to get a task done, no matter how nerdy or obscure (but who are pathologically incapable of documenting their work, or teaching others) [e.g. my co-worker who had used that computer for months or years without noticing the virus] and (2) those who are good at interface, optimization, and documentation but lack the penetrating power to solve the more difficult problems [e.g. myself -- I had to leave that job because I couldn't 'crack' the OO stuff].
Speaking to this thread's main question: both classes of programmer would need to understand some assembly, but for different reasons. Group 1ers would likely end up using it (or having to debug/change it) from time to time -- and it would be no big deal to them to learn it, use it, whatever. Group 2ers would likely want to know _when_ to use it, and probably get someone else to do that coding.
In the geek cred hungry world of
BTW, in considering where Woz, Ciarcia, Kahn and Hertzfeld fit into this, I think they are Group 1ers who simply took an interest in Group 2 stuff. If you can learn both mindsets, you are one powerful programming dude, IMO. [Pity that 2ers like myself can't easily (ever?) become 1ers.] Most 1ers just want to get the job done and move on, yet so much can be learned after you think you have finished your program. [MS deserves props for realizing this and assigning a second unit to work on optimizing the code already working -- Win95 crap became slightly less crappy Win98 through this process (pdf)]
I come here for the love
They stare at the code for a while, make wild guesses...
;-P
Sure. But that's only because "The C Programming Language [is] A language which combines the flexibility and power of assembly language with the readability of assembly language".
The original post asks if Assembly is still relevant today. I'll ask some rhetorical questions (the only kind in a blog) and see how they apply:
a nalysis/architecture/whatever). The difference is training vs. education.
n dex.html.
* Would you want an astronaut to understand physics and math?
* Would you want a doctor to understand chemistry and biology?
* Should somebody studying to be a Literature teacher take their full set of liberal arts courses, including history?
* Should somebody earning a business degree take music appreciation?
Most of us probably said, "Yes" to most or all of those above. Even if the study seems irrelevant or too "low-level" or too "high-level" at the time, there are areas of coursework that help us understand things better.
I see a lot of dead wood in the IT industry. There are enormous numbers of people who either have no passion or who do not have a deep-enough or broad-enough knowledge of computer science to do their daily data processing job well. They are dependent on others around them for everything, even though they may be very skilled in one area.
By having both a broader and a deeper knowledge, people are necessarily better at troubleshooting and at understanding the areas outside their particular specialty. It makes them be better at all of IT and helps them do their specific role.
You should learn IT two ways -- deeply and broadly. You should deeply learn specific skills (Java/C#/Linux/Windows/scripting in Ruby/whatever) and you should learn broad skills (computing theory/relational databases/networking/troubleshooting/programming/
There is an enormous difference between training and education. Training is learning specific skills for specific tasks (narrow/specific), while education is broader and teaches you how to think, understand, and apply (broad/general).
While taking Assembly may not seem relevant at the time and you may never directly use it again, for every programming task, having a strong background in all of computing theory (including how the CPU handles its low-level instructions) educates you and gives you a deeper understanding. (Don't just be trained, be educated!)
My recommendation is the book My Job Went to India (And All I Got was this Lousy Book). If you can't afford it, read the sample chapters, especially the "Being a Generalist" and "Being a specialist" chapters at http://www.pragmaticprogrammer.com/titles/mjwti/i
Personally, unless you need the specific class/training, I'd say that FORTRAN or COBOL ought to be abolished as required material in all colleges and shouldn't be in the degree program. Those should be electives only. Assembly, on the other hand, should remain required, for a deeper and broader education. (Don't settle for a dumbed-down program).
The difference, again, is training (specific/skill-oriented/task-oriented) vs. education (general/broad/understanding-oriented). Education and being a generalist will reap large rewards, long term. So stick with it and take that class. Assembly is a very important foundation class that educates you, long-term....
Another rhetorical question I have is this: "Are you passionate for IT or is it just a high-paying (presumably) job?" If it isn't a passion of yours, find you passion and do it well. If it is, take Assembly and like it -- it'll help you appreciate IT, your computer, your high-level language, and give you a more educated view of the "soul" of your computer.
(They don't make you take Assembly at many/most schools for their health. It would be a crying shame to remove it from the required courses).
Xenon, where's my money? -Borno