Slashdot Mirror
Learning Computer Science via Assembly Language
johnnyb writes "
A new book was just released which is based on a new concept - teaching computer science through assembly language (Linux x86 assembly language, to be exact). This book teaches how the machine itself operates, rather than just the language. I've found that the key difference between mediocre and excellent programmers is whether or not they know assembly language. Those that do tend to understand computers themselves at a much deeper level.
Although unheard of today, this concept isn't really all that new -- there used to not be much choice in years past. Apple computers came with only BASIC and assembly language, and there were books available on assembly language for kids.
This is why the old-timers are often viewed as 'wizards': they had to know assembly language programming. Perhaps this current obsession with learning using 'easy' languages is the wrong way to do things. High-level languages are great, but learning them will never teach you about computers. Perhaps it's time that computer science curriculums start teaching assembly language first."
Although unheard of today, this concept isn't really all that new -- there used to not be much choice in years past.
While starting Computer Science students off with assembly (without first introducing them to a high-level language) may be a relatively new concept these days, the idea of teaching low-level languages to Computer Science students is not a revolutionary technique whatsoever. Every decent Computer Science curriculum includes several semesters of courses in which assembly language is required, to demonstrate their knowledge of basic computer processes.
That reminds me of a great fortune:
"The C Programming Language -- A language which combines the
flexibility of assembly language with the power of assembly language."
My Grandfater worked for IBM in the 70's and 80's. He did all his coding in assembly and machine language. His motto is "Anyone who doesn't know machine language has no business using a computer."
There has to be a happy medium IMHO, and I think this is a great start. While my Grandfather was on the cutting edge of the PC revolution, he now has trouble figuring out email, etc, because he operates at too LOW a level (and I feel that he now has no business being online!). Then you have the users who have the same problems because they operate at too HIGH a level (AOL, etc...). The majority of programmers nowadays fall about smack in the middle of these two groups, but I'd argue they should be a little closer to the lower levels than they currently are.
I learned LOGO and BASIC as a kid, then grew into Cobol and C, and learned a little assembly in the process. I now use C++, Perl, and (shudder) Visual Basic (when the need arises). My introduction to programming at a young age through very simple languages really helped to whet my appetite, but I think that my intermediate experiences with low level languages helps me to write code that is a lot tighter than some of my peers. Let's hope this starts a trend, it would be great if more young (and current) programmers appreciated the nuts and bolts!
Sounds more like a programming book than compsci book.
writing an RB tree or an A* search an assembly would be a huge pain in the ass, if you ask me.
compsci is a large part about data structures, how to choose the right datastructure, how to get the most out of an algorithm by picking the best datastructure, etc...
but i didn't read the book, so i'll just go back to my websurfing now...
https://www.accountkiller.com/removal-requested
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I started out learning to code in asm on my c64 and I'd have to say it was a very rewarding experience.
Anyone who disagrees with this probably doesn't have much experience coding in assembler to begin with. Asm really is fairly easy, the trick is that most who teach asm actually spend too much time on those computer concepts and not enough time on actual real coding. It's wonderful understanding how the machine works, and necessary to write good assembler but you should start with the 2 pages of understanding that is needed to "get" asm at all.
Then teach language basics and THEN teach about the machine using actual programs (text editor, other simple things) and explaining the reason they are coded the way they are in small chunks. Instead of handing a chart of bios calls and a tutorial on basic assembler, introduce bios calls in actual function in a program, most of them are simple enough that when shown in use they are quite clear and anyone can understand.
After all assembler, pretty much any assembler, is composed of VERY simple pieces, it's understanding how those pieces can be fit together to form a simple construct and how those simple constructs form together to create a simple function and how those simple functions form together to create a simple yet powerful program that teaches someone programming. Learning to program this way keeps things easy, but still yields a wealth of knowledge about the system.
It also means that when you write code for the rest of your life you'll have an understanding of what this and that form of loop do in C (insert language here) and why this one is going to be faster since simply looking at the C (insert language here) concepts doesn't show any benefit to one over the other.
The idea isn't to actually use the language but rather to learn it to help you understand other languages.
It's like learning Latin. Nobody actually uses it, but it can give you a deeper understanding of the languages that are based on it.
TW
Of all the processors out there, yes the x86 is common but it has to be one of the WORST instruction sets - one of the most difficult to work with.
Is it just me???
I DO think it's a good idea to be teaching assembly, not so sure as the core of a comp sci program however. I started playing with assembly fairly early, on 6052, z80, and then later with 68000 and IBM 370. It's good to know, but I would do major stuff in it anymore. That's what high-level languages are for. You only drop to assembly when you have to for speed or space.
``Bad Idea: Teaching CS by starting with one of the most cryptic languages around, and then trying to teach basic CS fundamentals.''
I completely disagree. Assembly is actually one of the simplest languages around. There is little syntax, and hardly any magic words that have to be memorized. Assembly makes an excellent tool for learning basic CS fundamentals; you get a very direct feeling for how CPUs work, how data structures can be implemented, and why they behave the way they do. I wouldn't recommend assembly for serious programming, but for getting an understanding of the fundamentals, it's hard to beat.
Please correct me if I got my facts wrong.
There are a million fields in CS-- you can view them as points on a line that stretches from engineering to mathematics. The people who work in architecture are at the most extreme end of the engineering section. If you want to go into systems programming or into architecture, then I can see how would want to base everything off of asm. But if you specialize in ai, or algorithms, or theory, you really don't encounter assembly that often... for the most part, the need isn't there to develop extremely high performance, system dependent apps. In these fields, you could do of a cs curriculum (through graduate) entirely in Matlab, Prolog and ML. The emphasis is on the mathematical structures the program represents over how the computer actually deals with them.
On that same note, I consider that as one of the better arguments against OO code - It simply does not map well to real-world CPUs, thus introducing inefficiencies in the translation to something the CPU does handle natively
maxim: cycles are cheap, people are expensive. For the *vast majority* of software it is significantly better value to design and build a well architected OO solution than to optimise for performance in languages and methodologies that are more difficult to implement and maintain. Who cares if it's not very efficient - it'll run twice as fast in 18 months, and will be a lot cheaper to change when the client figures out what the actually wanted in the first place. But I guess you already knew that.
"The new wave is not value-added; it's garbage-subtracted" - Esther Dyson, Dec 1994
My first IBM PC job was C, but I had to learn 8086 so that I could debug since there was no source level debugging when using overlays.
Anyways, how do you find a compiler bug, if you can't read the code the compiler generates?
Fight Spammers!
True. This topic, however, goes beyond mere maximizing of program performance. Pur simply, if you know assembler, you can take the CPU's strengths and weaknesses into consideration while still writing readable, maintainable, "good" code. If you do not know assembly, you might produce simply beautiful code, but then have no clue why it runs like a three-legged dog.
.1% of code needs to be so optimized that CPU architecture matters. For the other 99.9% speed improvements are much more likely to come from algorithmic improvements. Not only that but real world experience shows that code written in ASM is NOT maintanable, the indepth knowledge of a specific architecture is fleeting while knowledge of most high level languages lasts a LONG time.
About
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
For the other 99.9% speed improvements are much more likely to come from algorithmic improvements.
Gack! I perhaps have phrased myself rather poorly. Throughout this entire thread, I have not meant to refer to writing even a single line of actual assembly code. I don't mean that humans can do it better than compilers (though often true, for small sections of code), I don't mean that asm always runs faster than the comparable C (again, often true), and I don't in any way mean that asm reads more clearly than a high-level language (about as false as they come).
Perhaps an example would help...
In C, I can make a 10-dimensional array (if the compiler will let me) as a nice, easily-readable organization of... Well, of something having 10 dimensions (superstrings?). I can make a pointer to a structure that contains an array of pointers to linked lists (which sounds obscure, but I can imagine it as a straightforward way to implement, say, a collection of variable-length metadata on a set of files). I can choose to have my loop indices run in row-major or column-major order, with no high-level reason to choose either way.
From an assembly point of view, I realize exactly the hellish task involved in dereferencing the first two example. I realize that row-major vs column-major ordering has a significant impact on the quantity of dereferencing needed. Even further, I realize that by choosing row-major or column-major indexing, I can ensure cache integrity, or obliterate it.
The specific examples I just gave perhaps seem absurdly obvious to any decent programmer. But countless other, more subtle, differences in how I would choose to lay out my code, come from an understanding of what the compiler will likely do with that code, and how the CPU will eventually have to deal with it. Rather than having a superficially obvious relation to the CPU, such choices would look more like stylistic preferences than careful decisions with significant implications to performance.
How about the size of an array, for example? Sometimes using a power of two will help immensely (if it allows a constant shift vs a multiply), and sometimes it will hurt immensely (if you plan to use it such that almost every access competes for the same cache line). Things like that, which a high-level-only programmer simply will not know without experiential (ie, programming in assembly) knowledge of the underlying architecture.
The problem is that computer scientists don't make good programmers and vice-versa. If you're good with code and hunker down to write lots of programs, then you tend to clash with the all-theory-no-code camp that delights in big-O notation and graph theory. Of course there is a lot of middle ground, but in general the PHd professor types that staff CompSci departments I've been in tend to have stopped learning about computers as soon as they finished their doctorate and instead concentrate on internecine politics, incomprehensible papers, and teaching the occaisional class (leaving most of that to T.A.'s who actually teach the class and understand how to compile programs).
Meanwhile the coder types graduate with a B.S. or maybe a masters then go into commercial development shops and crank out code, forgetting as much as they can about red-black trees and other subtle CompSci concepts.
So if you want to crank out programmers, then assembly is probably a good thing. God knows I learned a lot from the assembly classes I took.
If you're trying to scare students away then assembly is also a good tactic. Nothing like a good hex dump to get some non CompSci students eyes to glaze over. Sort of like making people take Biology or Physics, but instead of teaching about cells and newtonian motion, jump right into the finer points of quantum mechanics or amino acid chemistry.
On the other hand, for 2nd year CompSci students, Assembly is probably a good thing to get out of the way. It really sucks, for example to take economics for 4 years only to learn at the end "just kidding, reality is too complex to model so these are all just gross oversimplifications." Sort of like thinking programming == Java then finding out how it all _really_ works.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
Not only that but real world experience shows that code written in ASM is NOT maintanable, the indepth knowledge of a specific architecture is fleeting while knowledge of most high level languages lasts a LONG time.
That is not the point. The point is that knowing one assembly language gives far more insight into what higher level languages actually do. It is, e.g., very difficult to explain the actual workings of a buffer-overflow exploit to somebody without any assembly knowledge. Or what a pointer is. Or what pageing does. Or what an interrupt is. Or what impact the stack has and how it is being used for function arguments. Or how much memory a variable needs....
The only processor I know that actually made assembly programming almost a c-like experience was the Motorola 68xxx family. On the Atari ST, e.g., there were complex applications writen entirely in assembly. Today it would indeed be foolish to do a larger project in assembly language, but that is not the point of the book at all.
Bottom line: You need to understand the basic tools well. You don't need to restrict yourself to their use or even use them often. But there is no substitute for this understanding.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Perhaps it's time that computer science curriculums start teaching assembly language first.
It's more critical they actually teach computer science first, instead of programming. A new CS hire, assuming their school was worth a damn, can learn a new language. I want to know if they have the math background to understand the problems that will be handed to them and that they have the ability to self-learn.
To me, not teaching assembly in a CS major would be insane. It would be like teaching physics without any of the history of how it was discovered and without showing how to derive the various equations from the more fundamental equations. My first 3 semesters were in java. My fourth semester I was in a C, Assembly, and an intro ECE class and I am very glad that I was. The combination of these 3 classes at the same time was great. Sometimes it is a lot more helpful to learn why something works or how something works than just learning (heard countless times in my java classes) "Oh don't ask questions about that, its not something you need to know. Java handles this for you automatically." If you want it to only be taught like that thats great; just don't expect any of your students to ever create the next java.
Also, you do know that compilers are written by programmers don't you?
--
WHO ATE MY BREAKFAST PANTS?
Assembly has little to nothing to do with either programming or computer science anymore. Computer science (IMHO) deals with the study of software engineering and algorithms
If it truly is a science, then someone who finishes a Bachelors and Masters program in Computer Science had better be capable of contributing to the advancement of this field.
This could be through the development of new languages, in which case I hope they know a thing or two about assembly in the first place.
Otherwise, a couple of Computer Science degrees would simply mean someone is a techno-wonk, a professional student, or just a technician rather than a professional engineer/scientist.
--
Disclaimer: 90% of the programmers out there do not
need a Computer Science degree, and 90% of the jobs
out there for developers don't need CS graduates
I have yet to see a project where more than a handful of objects from older code would provide any benefit at all, and even those that did required subclassing them to add and/or modify over half of their existing functionality.
Have you never used a decent class library? Writing reusable classes requires a much more careful approach to design and implementation than writing classes for one time use, and most people can't afford to spend that kind of time. The power of reusability lies in the fact that I can go out and buy a library of useful classes and feel pretty good that the code therein has already been well tested, usually at much lower cost and higher quality than I could produce myself.
Whether it's building a user interface with PowerPlant, Cocoa, or MFC, or manipulating data with STL, the amount of code that I reuse far exceeds the amount that I write myself.
Computer science isn't "knowing computers on a deeper level." Computer science is algorithms and lots of math. Computer scientists don't care about how a computer works. They don't care about the language either. They are interested in data structures and how to work with them. What language is in use is really unimportant, be it Java or Assembly.
Join Tor today!
I have say that trying to program in low level languages, or worrying about the details of the machine archtecture has usually been (in my experience) counter productive in terms of efficiency.
I'm not saying that there aren't places where low level details aren't critical, but for the most part they just draw attention away from the thing that has the most impact on performance.
Application Architecture.
The choices of algorithms and data structures are far more important than any low level details. But low level details are more fun, and tend to make us feel more manly or guruly or something so we tend to focus on them instead. In practice I find that using low level languages or super optimized tools make it hard to worry about high level structure, so the structure gets ignored.
I once worked on a project in which people were seriously freaking out over the performance hit in using virtual functions while parsing the configuration file.
At the same time, the application (a firewall) was performing multiple linear searches through linked lists of several hundred items per packet. These searches were very carefully optimized, so they had to be fast... (sigh). When I switched the system to use STL dictionaries (and later hashes), total throughput jumped three fold, yet some of the developers were worried about the cost of the templates and virtual functions used.
The fact that the algorithm is more important thatnthe details of implementation is a lesson that everyone (myself included) needs to keep getting pounded into them, because it's so easy to forget.
There are places where assembler and hardware details matter a great deal. But they are usually places that contain a lot of repetition that can't be removed algorithmically. Graphics are the obvious example.
A recent example:
My brother in law gave me one of those boards with pegs in which you try to jump your way down to a single peg remaining. I have no idea what it's called, but anyway....
I decided to be cute, and wrote a 100 line python scrpt over lunch to find all possible solutions. I was suprised when it hadn't found a single solution by the time I was finished eating. I was a lot more suprised when it hadn't found anything by the end of the day.
So I killed it and started in optimizing for performance and tweaking and trying different things. This kept me occupied over lunch for a couple of weeks, but didn't produce anything else. Finally I started doing some analysis of the problem. The first thing I found was that the search space (for the board I had) was roughly 10**18.
I didn't matter how much I tweaked the details of my search, it wasn't going to find very many solutions in less than a century (actually, it looks like a naive full search will take several thousand years).
So, after wasting several weeks of lunch breaks, I have redefined the problem. Find A solution, and rewritten my search to use a heuristic. I finished everthing but the heuristic at lunch a couple of days ago. The new system will take 100 or even a 1000 times as long to perform a jump, but I'm expecting to find a solution before I'm dead.
So, don't get bogged down in the details of an implementation. They won't usually take you very far.
plus-good, double-plus-good