Slashdot Mirror
Is Assembler Still Relevant?
quarnap asks: "I'm a system administrator running mostly NT boxes. I got into a discussion with a unix admin over whether a knowledge of assembler was of any use in either of our jobs. He insists it is since it provides a fundamental level of understanding of how computers work. I disagree; I say it isn't needed for ANY system administration work since that level of understanding is way below the level at which system administration operates. What do you think?" We've discussed this issue in a general sense in a previous Ask Slashdot, yet when it comes to System Administration it's a toss up. I can see situations where Assembler experience might be a boon to a sysadmin, but not a requirement for the job. What about you?
So, does assembler directly impact the degree to which a person might be capable of administring a system?
Yes and no.
It may not directly be of use when installing & configuring things, but I think it indirectly is of great value to an administrator who is troubleshooting things; and actually has some knowledge about computers and software that didn't come from a course or book purely on administration.
Are programmer admins that common though? I've done admin work, but I moved on to whatI wanted to do, programming, quickly.
-- Eric
On the other hand, thats exactly all some people want. I guess it depends on what your goal is - true understanding, or simply getting by.
-- Eric
If you are the sort of admin who get's asked "hi AdminMonkey, my email doesn't work, can you sort it please" or "i need nfs access to foo, sort it"
then assembler probably isn't much use.
But if you are the type who get's asked "bar program keeps core dumping on me, could you fix it please" then it most probably is.
You can close this discussion now.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
If you're a sys admin and need to learn a language, you're much better with Perl or Python or similar, since they are more useful for actual systems administration work.
I cna see though if you were the kind of heavy sysadmin who gets into the bowels of the system and also works on bug fixing in-house software, assembler might help, although I tink you'd want to get very up on C first.
~~~~~ BigLig2? You mean there's another one of me?
I'm a system administrator running mostly NT boxes. I got into a discussion with a unix admin [added emphasis mine] .BAT files, is alright. The system will let you cope. (Yes, yes, you will be crippled, but that's aside the point.) This is not true in *NIX land- as any native, immigrant, itenerant or visitor will be able to tell you (if only by their total lack of understanding). *NIX demands that you know why the system works- just to configure it properly- and that requires a knowledge of programming (though I've never encountered needing to know real assembler, knowing the concepts sure helps every once in a while).
Look, don't try to talk this over the OS advacacy gulf. In Windows, not knowing how to program at all, even to the extent of never writing
So if you want the answer in simple terms- sure, you're both right, but only in Windows can you get away with no knowledge of programming and still administer a box (yes, yes, poorly, but a MCSE will help. That doesn't teach programming, IIRC).
Do you like Japanese imports?
If you spend any time trying to choose hardware, fix hardware, optimize performance, resolve application crashes or otherwise go beyond user-level application support and swapping components, you would benefit by a second, more rudimentary view of your system.
If your job is pretty basic or you never worry about growing past your departmental budget, the extra 10% that a system-level view provides probably isn't worth the work. But it's still fun to know stuff, damnit.
please don't get me wrong, but actually the
.dll, .lib) or compile them to executables,
language is called "assembly" and the compiler
"assembler".
Assembly surely is fine, and even today you can
write native {DOS, Win32, NT native, UN*X}
applications fully in it - or even sedecimal
machine language, but no one tends to do it, even
if one can. The effort isn't worth it.
But you can, for example, as I do, code important
parts of you code in (portable !!) assembly, the
other parts in C. The C files I compile with gcc
(BSD and Linux) or BC++ (Win32), the assembly
files with nasm (http://nasm.2y.net/), with a
%ifdef for the cases ELF, A.OUT/BSD and OMF
differ (the object formats).
I can bind those object files to libraries (.a,
.so,
and they yield me funtionality at speed never
seen.
I recommend the newsgroup comp.lang.assembler.x86
for a start, _if_ you really want to code in asm.
But I do not recommend to do so if you didn't
understand coding in before, and for a NT sysadmin
I'd rather recommend php (or perl, but I dislike
it), or, as another poster told, python which I
didn't use yet.
This should give you a first shot.
On the other hand, these languages, as well as,
e.g., VBA, do not have typical programming language
structures such as type checking, so, if you want
to start "real" programming, download BC++ 5.5
(http://www.borland.com/) - there's a free download
edition, command line tools only, and start coding
in C. Mostly I'd recomment command line code for
a start, as GUI programming is way more difficult.
I personally dislike C++, for example because it
is too complex - noone can hold the whole of the
language definition in back-mind as I can easily
do with C or some assembly environment.
Of course there is also cygwin32, and my programmes
would compile no differently under it than they
do under BC++.
If you still want to do assembly, don't use MASM.
If you want, use TASM, but if you CAN, use NASM.
There's a linker (VALX) that can even produce
Win32 executables at http://members.tripod.com/~ladsoft/
included in the C compiler package, but here I
take ilink32 of the BC++ package for stability
reasons.
You can even write your own import libraries
under NASM if the provided packages are too
complicated (I do).
Google for "win32 nasm" and you will find some
more sites, or "win32 assembly".
Puh, this's a long and partially-OT post, but I
hope this will help you.
My Karma isn't excellent, damn it! (And
Learn stuff, kids, it won't kill you. It's like differential equations - there are some things that just about everyone should take a class in, it proves they're smart enough to have a university degree and gives them a good general understanding of how something else in the world works.
Many system administrators work with people who not only know assembly, but think in it. Freaky, I know, but I'm in EE and it's basically how we are, and it's who we want to work with. Deal.
spacefem.com
For admins? No. But DSP coders still make the BIG bucks.
If Chaos Theory has taught us anything, it's that we must kill all the butterflies.
I think a competent UN*X sysadmin should be a competent C programmer. Since you can't be a competent C programmer without knowing how C translates into asm, a familiarity with asm is a given.
-Steve
Developers obviously have a benefit to knowing assembly, if no reason other than debugging skill. Those who don't know it are reduced to blaming Bill, other components of the system, or the hardware, all of which are counterproductive excuses at best.
I believe sysadmins have a benefit to knowing it as well, simply because you know whats going on under the hood, so to speak. This kind of knowledge allows you to actually understand the worth of things like 3DNow!, SSE/SSE2/MMX, pipeline length, cache consistency, hyperthreading, and all the other things that vary from processor to processor and from software package to software package. I believe this is important because you aren't reduced to cointosses for whose hype to believe, when deciding what things to buy/download and deploy.
In addition, if assembly wasn't relevant for administration of a system, why would you include register dumps in bluescreens/Oopses? Rebooting doesn't cut it, that only temporarily alleviates symptoms and doesn't solve the problem. I believe "keeping a system running smoothly" definately counts as a sysadmin's role, therefore a sysadmin should have good debugging skills. Even if you pass the debugging off to someone who would know, wouldn't it be nice to know WHICH hex numbers on that bluescreen would be helpful to him/her in finding the bug?
If you're constantly answering questions like "I forgot my password", "is the network down?", and "I need a damned good kicking please?", then perhaps assembly wouldn't help you here (unless you're trying to achieve BOFH-style *DUMMY MODE*). However, this means you are either not a sysadmin or are wearing multiple hats - this stuff is commonly called "Tech Support".
Paranoid
Bwaahahahahaa.
What is your role in the administration of the network? Shellcode for
penetration testing is asm (though you can arguably use code written
by others who do have the knowlege of asm you're lacking). Writing
any kind of lowlevel tools where speed is critical is asm. Debugging
any odd behavior of lUserland software is asm. Changing the paper in
the paper tray or pressing the on/off switch on the fileserver when it
misbehaves does not. You CAN get by without a knowledge of
assembler or any programming language at all, but I personally wouldnt
feel very comfortable with job security unless I was the boss's nephew
because the person who does know these things you deem as
unimportant WILL be better qualified and do a much better job that the
one who doesnt.
Of course this is just my own opinion based on my own observations,
take it as you will.
--Ks9
I'm in the middle of a sparetime project based around an Analog Devices DSP. I'm curious why your statement is true, especially since its so easy... anyone who knows algebra can read AD DSP assembly fairly easily. The only tricky part to writing it is sorting out your algorithm to take the most advantage of parallel instruction execution.
Are other vendors' DSPs (TI comes to mind) more difficult to understand?
Paranoid
Bwaahahahahaa.
I've provided post-sales support for a number of proprietary products for a number of years and having an understanding of programming from assembly and bare metal up certainly helps me. It has baffled my (non-programmer) colleagues who wonder how I appear to pull correct diagnoses and solutions out of thin air, though. This sometimes causes problems if they think I'm being unprofessional and guessing.
At the very least, knowing what strace/truss is telling you, being able to find the executable or binary producing a certain error message (strings) and being able to distinguish between the static and the dynamic parts of error messages (so you can search using Google for the static parts) helps enormously.
Having said all that, the combination of x86 and C/POSIX is the first platform I've not bothered to learn how to write assembly for... might come in handy for implementing l33t 0-day sploitz though.
--
The majority of the opinions here so far seem to say that learning assembly isn't important for non-hardcore-programmer types.
I agree, if we're talking about any particular assembly. PowerPC assembly, for instance, or MIPS assembly.
But everybody who programs-- even people who just want to understand programming-- should slog their way through Knuth's TAOCP. The abstract stuff in that book is implemented in concrete terms through a really simple fictional assembly language called MIX. When you're reading the first chapter of Volume 1, you'll be so frustrated with it that you'll wanna strangle the first person you see. But by the time you get through it, you won't be an assembly programmer, but you will find yourself saying things like, "I should arrange the loops this way, because then the inner loop will fit entirely in registers and the data fetches will be less than one cache line."
Saying stuff like that makes you sound really smart, which leads directly to better paying jobs.
Asm, while maybe not relevent right at this moment, may be useful sometime in the future. It is true it gives you a greater understanding of exactly what is going on if an error should occur. The other thing you might consider is: Do you really want to be a system admin for the rest of your life? An NT one no less?
If you're ever interested in progressing your career further you might consider picking up a programming language or three, asm might be a fun choice.
An admin friend of mine once said something to me that changed my mind about being interested in the admin field:
"Just wait until they figure out, we're just janitors for thier computers"
A basic knowledge of assembly (and basic compiler theory) is absoluely essential to efficient programming in C. If you program in a higher level language (not C++) that knowledge is perhaps less useful.
Another good use for knowledge of assembly is in analysing certain crash dumps from software that was built optimised. When a highly important customer sends in a crash dump it's nice to be able to at least determine the line in the software that the error occurred, if for no other reason than to use as evidence to pass the buck to someone else.
... you could have learned some of the basics. As a techie you should constantly be trying to learn, both inside and outside of your specific domain. Learn what interests you.
Sysadmins are probably better off with perl, shell scripts, and WSH first. Then, if you want to push yourself, learn a language like C++.
Asm should come later, and most people gan get along just being able to read it. Learn about the registers, the stack, and addressing; then learn the most fequently used instructions such as mov, conditional branches, jumps, and call. After that just look up the ones you don't know when you run into them.
In my opinion, the value of assembler is vastly overstated these days. It makes you work so close to the metal that it become too difficult to keep track of how a large, complex system has to work. It can be useful for optimizing critical components of important systems, and I'm sure it's invaluable in situations like embedded & realtime systems, but for a sysadmin? No way.
In my opinion, it would be much more valuable to have a good grasp of relatively high level & abstract subjects like networking techniques and protocols, file structures, and most importantly data structures. The last one is particularly important, because knowing how to rewrite a bad algorithm in assembler is sure to be much more painful and much less effective than rethinking the algorithm itself. You're likely to get a better performance gain by implementing systems with optimal algorithms in a "slow", high level language than you are with a naive algorithm in a "fast", low level assembler, and with hardware power increasing as fast as it does, you're better off taking the high road anyway -- *especially* as a sysadmin.
Knowing how the machine works is important, and I'm not trying to dismiss that. But knowing how to manually push the bits around is just going to be an exercise in tedium & frustration. The machines are designed to abstract away that monotonous stuff for you, and you have to be in a pretty specialized situation for it to be worth second guessing the compiler writers. RTOS/embedded type stuff is one of those situations. Sysadmining, either on NT or *NIX, isn't.
You'll get much farther by knowing how to bang out a stream of high level utilities in a language like Perl, Python, Shell, DOS, or Visual Basic, than you ever will by slaving away at little functions in assembler that take forever to gel into useful systems...
DO NOT LEAVE IT IS NOT REAL
... we seem to be heading, as a society, towards Black Box mentality. We don't care how it works so long as it works. You see it every day when you look at people using computers. Many (most?) of them have no clue about how the computer works at all. They're doing pretty good if they know how the application (or game) that they want to use works. And when the magic Black Box breaks, they call tech support. And many (most, it seems) tech support people are almost as clueless as the people they're trying to help.
Now we're taking it up a level and worsening the problem, by saying it's okay if Sys Admins and programmers don't understand the intricacies of the Black Box. They just need to learn how their portion of it works, and they'll be okay.
Back to the original question: Does a Sys Admin need to learn Assembly? Probably not. But it's a disservice to the profession to only learn what you need to know.
Nothing to see here. Move along.
Any computer system consists of layers upon layers of abstractions: machine programming models, procedural programming models, OOP models, message passing models, networking protocols, application frameworks.... Nobody can master all of them. You can't even hope to master all the ones that you (directly or indirectly) use! The best you can hope for is to master the abstractions that are directly relevent to your work, and have a schematic knowledge of those that indirectly affect you.
That being said, studying low-level programming actually does help you understand how computers work -- provided you study it in context. You need to study it not as a "fundamental" programming model, but as one piece in a very big puzzle. And you need to avoid focusing on one particular processor -- that will only tell you about specific, possibly obsolete, design decisions, not fundamentals of "how computers work".
Without assembly, John Carmack and Michael Abrash wouldn't be putting out cutting-edge gaming engines. There's a lot of money going through them based on the various Quakes and Dooms and the licensing of those engines to other projects. People love those engines based on performance, and good performance means knowing assembly -- otherwise we'd need 2GHz machines to do what Id was able to do on 400MHz (or whatever). So, assembly can still be relevent even if we aren't the one's coding it.
That said, with the evolving speed of chips it isn't the CPU that's the big bottleneck anymore. So, if you're thinking games at all, you might want to consider looking at chip programming for video cards and leave the rest of it in C/C++.
As for the rest of us... I don't really know. Being a specialist in a specific chip architecture really lets you flex your geek and might lead to a specialist's salary and sort of lets you in on that whole nebulous zen of programming out there, but it's not really needed (IMO) if you're only working with APIs on small task-based things, and not building or refining high-performance engines (servers, databases, games, whatnot), and arguably even in those cases assembly programming should only be the last stage once the prototype's been worked out. Plus, there's the possibility that we really are on the verge of seeing the death of the desktop machine, in which case all our x86 knowledge might be useless in the next five to ten years...
Now, those PDAs would probably be fun to get at the guts of. I can imagine that there's a need for performance at that level, given the low amounts resources (RAM, Hz, etc) available. I'm sorry to say I know nothing about these things. Is there chip-level programming available for those? That might be an interesting side discussion.
Here endeth the offtopicness.
-------------------------------------------------
charlton heston is more of a man than yo
Think again. Don't believe me? Then read this story. A nice hack to say the least.
I code in the highest level language that does what I need to do.
Sometimes that means Assembly Language. Most of the time it is something else.
A long time ago it even meant patching machine language (object code) to get things right.
I have never regretted knowing more than I might need for a particular task. Neither will you.
Unless you have other functions as well, your job as sysadmin is to keep the system running as often as possible - this means fixing problems as quickly as possible, and also keeping the system maintainable by other admins. Using any given scripting language - especially on a *nix platform - will let you carry out any standard sysadmin task quickly, efficiently, and in a way that is easy for admins less talented than yourself to understand. So in a non-development shop, you should certainly feel free to learn asm for the joy of learning (I intend to), but don't use it on the job.
In a software dev house or other highly technical environment, of course, you may actually be called on to do debugging work. In that case, yah, you need assembly. That's actually a pet peeve of mine, though: it seems to me that having a hopefully well-trained individual with experience and skill in system administration do a programmer's job is a waste, just as having a programmer take over sysadmin roles in inefficient a lot of the time. Let your programming gurus do their think, and your admin gurus do theirs, I say.
I'm the stranger...posting to
There's no argument that a Visual C++ or even VB programmer is going to be useful or at least informative when Office 97 bombs out with a GPF.
I've worked with alot of other techs, and they didn't pay attention to alot of Windows internals that I would, because they had no clue about them. Whats a specific DLL do? No clue. They could go to Microsoft's support site, and look up a fix, but you can't beat knowing where the problem lies.
And to do any kind of UNIX admin you've got to know your way around gcc, make, etc.
But do you need to know assembly language?
Probably not....
Knowledge of general programming is very useful though!
Sysadmins probably shouldn't write the equivalent of shell scripts in assembler, but having a firm grounding in it helps to:
1: Analyze core dumps, blue screens, etc. (regardless of platform)
2: Understand tricky things like big and little endian, binary, octal, and hex notation, etc.
4: Have a firm fundamental understanding of what object code is, what linkers and loaders do, why it's important, etc. In a world of DLL hell, at least understand what's going on "behind the scenes"
5: Have a theoretical framework to hang concepts like processes, threads, priority, scheduling, interrupts, etc. -- it might not be _the_ correct model for a particular platform, but it will give a much better starting frame of reference.
On the other hand, if by "sysadmin" you mean "village idiot", and the only requirement is to know how to walk people through rebooting their PC and knowing how to call 1-800-dial-a-vendor and sit on hold, then NO, you don't need to learn assembly. In fact, you could probably get away with not knowing math, history, economics, or much of anythig else. Better yet, how about totally untrained sysadmins? I mean, c'mon, NT/2k/XP is virtually self-administering and it's all "point and click", you could entrust all of your corporate systems to a high school dropout for a fraction of the cost of even an incompetent sysadmin!
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
I do embedded programming, and for me assembly is vital.
Even though the company I work for is going to C for everything (even PIC chips!), I couldn't do my job without knowing assembly.
All the chip reference manuals give assembly language examples.
There is a lot of old code that needs to be maintained or re-written.
Some things just can't be written in C. In-line assembly or externally linked routines are needed.
And if you are going to use in-line assembly in a C program, you have to know what the compiler is going to do with your C code, and how your in-line code is going to interact with it.
Would I use it doing NT administration? Probably not. But having a clue is never a bad thing.
You remind me of me. A lot.
It's not that assembler programming is a skill you will use much, if at all. It's about learning exactly what's going on, to pay attention to your data types, buffer lengths, and function call setups.
It's like studying karate. You'll probably never use it in earnest, but you're a better person for undertaking the discipline of learning to do so!
In fact Knuth wrote an article under the title Structured Programming with Go To Statements :-)
Regards,
Marc
But those little hacks aren't nearly the bulk of sysadmin work, and they CAN be done in scripting languages - not as quickly, but you do gain the advantage that more people will know the scripting language, and be able to maintain your hack. I don't know about you, but I find other peoples' assembly code a bitch to read.
If you want to do it quick and dirty, asm is very nice. But I still don't think it's worth the time to learn if you're only using it as a sysadmin.
I'm the stranger...posting to
its actually assembly language which is assembled using an assembler. assembler is not as language.