Who Still Codes In Assembler? 61
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."
Re:Um, anyone who _really_ cares about performance (Score:1)
Re:Don't Forget About Portability (Score:1)
I fear the day when this poster's "painfully obvious" statement comes true and distributions are afraid to ship the kernel, because parts of it are in assembly. I await the day (soon, hopefully) when distros can ship with a DVD player program which has some ASM optimizations so that it can work on a system that mere mortals can own.
// mlc, user 16290
--
Re:You don't code in assembly!? (long) (Score:1)
So do you know exactly what sort of signals does your opcode generate in the CPU? You better track those electrons or you don't know what you are doing. And them orbitals! Are you sure you know where your orbitals are?
I know that
If I need to know more, I'll dig up that glibc source, but if I don't and find more enjoyment from pretty perl scripts than obscure platform-specific tricks, don't call me a loser.
Keep systems programming alive ;) (Score:1)
Who programms in assembly? Lots and lots! (Score:1)
Re:You don't code in assembly!? (long) (Score:1)
SE '2k [se2k.dk]
dream hack [dreamhack.org]
Scene [scene.org]
There are more..
I only wish that NAID (Montreal, where I live) still existed.. ):
Re:You don't code in assembly!? (long) (Score:1)
Re:lots of folks -- but you don't see it (Score:1)
Are these some fundamental laws of computer science? Please clarify these (seemingly) odd requirements.
Re:Quake 3 - id found new "Pentium Optimizations" (Score:1)
Cool. BSD is my main server, so now I can make all the ignorant comments I want!
Re:You don't code in assembly!? (long) (Score:1)
In a way, assembly is also just rearranging "smaller programs of others" into larger programs. How? On x86 (and other CISC-style architectures) assembly is not the lowest level of programming, microcode is. It's just like using functions in C, except that you're functions are written in extremely low level microcode rather than another HLL.
Re:Anyone who cares about performance (Score:1)
Speed-wise, machine optimized code won't overtake Very Smart Geeks
True, but that's if you're having VSG(in Assembler) write your code. What do you do if the code is written by physicists who aren't expert coders ?
PS - To the spelling pillock. Get a life. Yes, I'm a Brit, and I spell things with an "ess" not a "zed" because I don't still use a 17th century spelling that we abandoned to you colonials centuries ago.
Re:Anyone who cares about performance (Score:1)
when you're running calculations which would take ASCI Red a couple weeks.
I used to write that sort of thing, and I used Algol and Fortran, not assembler.
The Very Smart Geeks who had written the Fortran's code generator knew far more about optimising assembler than I ever would. Speed-wise, machine optimised code overtook hand-crafted some decades ago.
Um, anyone who _really_ cares about performance.. (Score:1)
For one thing, a higher-level language is simply too vague for conveying processor-specific instructions, and there are plenty of times when an astute programmer can apply her understanding of an algorithm to prefetch data intelligently, structure code to jive with a particular processor's branch prediction rules, exploit pairability of certain simple operations, and so forth.
Mind you, an intelligent compiler will try to employ these same strategies, but its ability to do so is dependant on the choice of higher-level instructions given by the programmer. For instance, a particular processor might have an instruction that can test for zero and jump in a single clock cycle. In this case, the difference between iterating up versus down to zero in a for loop might determine if the compiler can actually exploit this.
A programmer who is intimately familiar with the vagaries of a particular compiler will have better luck, but this generally ends up being more trouble than it's worth.
For some applications, the importance placed on performance justifies the time necessary to hand-optimize code in assembly. This is not exclusive to people writing, say, memory allocation routines for an os. If any piece of code is called often enough, a difference in execution time of a couple dozen clock cycles may make the difference between a usable application and one that sucks. (Of course, this all assumes that the overall algorithm/design is sensible in the first place. Assembly will not save you from shitty code.)
Re:Graphics and Embedded systems... (Score:1)
Really? I got into programming for one thing: THE WOMEN!!
web dev ho (Score:1)
I do, when it's necessary (Score:1)
asm
end;
So, if I need to, I do. My main reason is when Borland's handcoded assembly code sucks... For instance, string searching uses REPNE SCASB. Which was the best way of doing searching on 8086 and possibly 80286 processors. But on todays Pentiums, a tight loop is faster. So, if I have a lot of string searching to do....
Re:You don't code in assembly!? (long) (Score:1)
I still code in assembly (x86 'natch) and I find it a great deal of fun on two levels: it focuses my perception of how HLL's "work" and (well to put it frankly:) it is Power (humbling too at times).
I would recommend learning asm to anyone programming in C/C++ or Java or even coding stuff for Linux (setting up the parameters on the stack for your C calls (and not crashing the program) is a transcendental experience); it may not help on your job immediately but do it in your spare time for a little while and you'll see improvement in how you approach your coding. Just be careful not to reinvent the wheel too much (I happened to love writing my own utilities and macros but you may not)!
Hmmm, does anyone know how much, if any, of the Quake III Arena engine is in asm??
Re:Quake 3 - id found new "Pentium Optimizations" (Score:1)
linnucks is my firstest favorite workserver to. I can be all ignorant n stuff.
Bingo Foo
---
Re:Who uses assembler? (Score:1)
Re:Anyone who cares about performance (Score:1)
Re:You don't code in assembly!? (long) (Score:1)
When you build a house, did you create all the building materials yourself? If not, did you really build that house, or are you just rearranging things (lumber, concrete, etc) that were already there?
When you write a song, did you invent all the notes that you used? If not, did you really create that song, or did you just re-use notes that other songs have already used before you?
I'm sorry, but saying that function calls are "cheating" is missing the point entirely. The true creative exercise in programming is deciding what your program is going to do, and then finding/writing/using the appropriate functions to do it. When you think about it, I didn't invent any of the words I've used in this post, someone else did, I merely arranged them in a way that gets my point across. As did you.
--
Who codes in Assembly? (Score:1)
Re:Anyone who cares about performance (Score:1)
If I want a calculation to run for several months, I'll code it in Visual Basic and run it on Windoze 2000 - assuming the pc stays up that long.
Graphics and Embedded systems... (Score:1)
I'd say the most important reason why people do not code is asm is just that it is difficult.
Most of the programmers out there are just people in the industry out there to make money. I do not mean to offend all the guys out there, but the truth is that most of the programmers who give into the hype of learning the 'latest a.k.a coolest' language are those who do it hoping that they'd be able make more money out of it.
Are you telling me that the web-designers and Java guys out there are actually interested in learning something for the heck of it? Hell, they do it because it helps fatten their wallets. Period.
And programmers out there who do it because they like it, would continue to do it whether or not they like it.
This is highlighted esp. for assembly language programmers. Had people coded the same way they did back in the days of PDP's/286/386, optimising that lines of assembly code, we'd really be making use of the awesome computing power we have today.
I still just hope that there are Mels still out there.
"...Fear the people who fear your computer"
Re:lots of folks -- but you don't see it (Score:1)
As much as I regret to feed this troll again, allow me to rebut. Firstly, my "mild retardation" must make my D. Phil (that's "Ph.D." for you Yanks) in computer science all the more impressive. Secondly, neither Gray nor I said "X has to be written in N instructions"; rather, the statement was "less than 100 instructions" and "less than 10 instructions". For those of you who are having trouble following, those numbers are what people who have at least high school maths experience refer to as "orders of magnitude". So that's "a lock must be set 'on the order of' 100 instructions, as opposed to a latch, which must be an order of magnitude faster.
Hopefully, this won't burst your small head.
Re:lots of folks -- but you don't see it (Score:1)
"High Level" assembler (Score:1)
You have to point out, that assembler isn't necessarily programming on bare metal. Borlands Turbo Assembler 5.0 even provides some object oriented features as classes with one level of inheritance. And the IA64 assembler has a very nice syntax, and is close to high level languages as the entire platform was designed for better support of compiled languages. It seems paradox that this makes building good compilers for this platform harder, as it is a very complex instruction set that heavily relies on dependencies.
And I'm a big friend of embedded assembler code, as the main advantage of higher level languages is the organisation framework of the code. Writing some methods in assembler combines the structure of the higher level language and the control of the assembler. You can support different platforms by #ifdefs as it is done in the Linux Kernel, even for some normal C code lines.
For a lot of simple standard tools there should be an assembler version, as I cannot understand why a "one bitter" like true should take more than 4k.
And there are of course these low level system initialisation routines, device drivers and all those classical examples.
Being realistic (Score:1)
Re:Stupid joke (Score:1)
Exactly. [dilbertzone.com]
Stupid joke (Score:1)
Re:Stupid joke (Score:1)
Re:Anyone who cares about performance (Score:1)
In fact, on that DSP, they have a special 'optimizing linear assembler' so you don't have to think about parallel instructions and pipelining. And it STILL is very very complex.
The time of hand coded raw assembly is ending soon....
Heh. How embarrasing. Thanks for catching that. NT (Score:1)
Re:Links to a search engine (Score:1)
Re:You don't code in assembly!? (long) (Score:1)
Don't Forget About Portability (Score:1)
Did I just point out something painfully obvious? Sorry...
__
Video Games (Score:2)
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.
Re:Stupid joke (Score:2)
Well, are you smart enough to spell "British English"?
Re:Stupid joke (Score:2)
Re:Who uses assembler? (Score:2)
Re:Anyone who cares about performance (Score:2)
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?
Re:You don't code in assembly!? (long) (Score:2)
Is there even a compiler for c-- yet? I was under the impression that it was still at the proposal stage.
Re:Anyone who cares about performance (Score:2)
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
I do .. sometimes.. (Score:2)
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 [steve.org.uk] 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
---
Re:You don't code in assembly!? (long) (Score:2)
----
Too difficult? Try unwarranted. (Score:2)
--
Knowledge is power
Power corrupts
Study hard
Microcontrollers (Score:2)
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.
Algorithms more important (Score:2)
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%.
Anyone who cares about performance (Score:2)
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.
Quake 3 (Score:2)
Who uses assembler? (Score:2)
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)
Re:Who uses assembler? (Score:2)
I remember back in high-school I was having fun with JMP FFFF:0000 in debug. I once sneaked the generated .COM-file into my teacher's computer's boot-sequence. He couldn't for his live figure out what was wrong, so he released the class for the rest of the day.
I grew up some years later.
Re:lots of folks -- but you don't see it (Score:2)
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.
Re:Algorithms more important (Score:2)
Code optimizing can be best done on well documented code, that has been tested and the sub-routines optimized.
I would think that with the current state of tech, most software houses would create the program then issue "addon/upgrades" to specific operating systems ( mac os or win or linux ) and specific processors. If i recall right i think autocad did this back in the late 80's and early 90's
spambait e-mail
my web site artistcorner.tv hip-hop news
please help me make it better
Gameboy programmers do it... (Score:2)
Same as the Linux kernel, for raw system-level (Score:3)
In most modern, general-purpose programs, assembler has rarely been used to "increase performance" over traditional program language code -- with rare exceptions going to heavily used functions that a profiler might pick up. And even then, most assembly is part of a larger program and a fraction of the total code -- usually in-line in the high-level language, or a self-containted object referenced by the other high-level language code. But even then, today's compilers are good optimizers and can even best you on your assembler if you don't know what you are doing.
No, for the past decade, assembler is still in use for raw, system-level details. Just like the Linux kernel, some things need to get done with GAS. Even NT's init loader is like this as well.
Most CS and engineering programs still teach assembler not to be proficient, but to understand the machine code v. man code relationship. It's not a full-up course where you write programs only in assembler -- in fact, I had a class on system-level programming where I wrote an assembler in C and binutils (lexx, awk, etc...). Why? It taught me not only assembler fundamentals, but the concepts of machine code and organization, basic parsing, hash tables, referencing and other concepts -- all in one course, in a very practical manner!
No, people why say "why code in assembler anymore?" are the people who continue to fail to understand why assembler ever existed. Heck, even Cobol and Fortran were available in the 50s! It was rarely a matter of "speed", but the fact that speed and size are "real-world constraints" at the system-level.
-- Bryan "TheBS" Smith
Re:Quake 3 - id found new "Pentium Optimizations" (Score:3)
With the Quake series, idSoftware found the Intel 32-bit integer loads from memory to 32-bit general-purpose register to be piss-poor slow. With a little tinkering, they found that on the Pentium, loading two 32-bit integers into a 64-bit floating point register, and then moving those integers from register to register was much faster. Why? With the Pentium, Intel really worked hard on FPU to bring it up to more common RISC-implementation performance (the 80x87 ISA has always been a poor FPU implementation, remember Weitek? ;-), and created a well pipelined FPU in the Pentium (over other x86 processors at the time). Pipelining means that more than one instruction can be worked on by a unit simultaneously -- if similiar instructions follow one another.
Most fast, interpolated 3-D geometry usually involves sets of regularly, well-timed, memory loads of four to sixteen (4-16), 32-bit reads for each operand into registers (usually 1x4 or 4x4 matrix of 32-bit, interpolated integer coordinates in 3-D space). Again, loading through the traditional integer opcode was piss-poor slow -- and id, again, found that the new Pentium chip offered a "workaround" via its new, pipelined FPU.
Because this was "unorthodoxed", most compilers simply did not implement this. If you tried to read integers from memory, it would use the integer load opcode. So idSoftware had to write their own replacement memory read/write routines and functions. Undoubtably, this was done easiest in assembler.
BTW, this "Pentium optimization" was why the first generation of AMD and Cyrix processors lagged in Quake performance. Not because their FPU "sucked", but the idSoftware optimizations relied on the performance of a pipelined FPU -- not something AMD or Cyrix had in their first generation of Pentium ISA-compatible products. In fact, AMD's K6 (Nx686 core) had an excellent, non-pipelined FPU that was faster at execution -- provided your program was comprised of random integer/ALU, FPU and control opcodes. And if idSoftware would have just left the regular integer load in, the K6's integer memory load was upto 3x faster than the non-MMX Pentium and would have smacked the Pentium silly.
-- Bryan "TheBS" Smith
Where you really find assembler (Score:3)
Appliances may have teensy-weensy little microcontrollers in them. Some of them have as little as 256 bytes of program ROM. You aren't going to get much of a C program into that, but assembly can do quite a bit.
Okay, I'll quit the mine-is-smaller-than-yours code-size contest now. ;)
--
Knowledge is power
Power corrupts
Study hard
lots of folks -- but you don't see it (Score:3)
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
Re:You don't code in assembly!? (long) (Score:4)
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. =)
You don't code in assembly!? (long) (Score:4)
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