Learning Computer Science via Assembly Language 1328
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."
Linux x86 assembly? (Score:3, Insightful)
Not So New Concept (Score:5, Insightful)
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."
Somewhere in the middle... (Score:5, Insightful)
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!
Programming or CompSci (Score:5, Insightful)
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...
Good idea, Bad Idea (Score:3, Insightful)
New? (Score:5, Insightful)
nah (Score:2, Insightful)
just my 2 cents
Assembly language IS EASIER (Score:3, Insightful)
Re:Linux x86 assembly? (Score:3, Insightful)
Probably a bad idea (Score:3, Insightful)
1) Difficulty - Assembly is harder to learn (and create meaningful programs with) than C++, or Java, which is replacing C++ in a lot of college curriculums. This means that students will be spending more time learning assembly, and less time learning about complicated algorithms and the things you really should be learning about (since languages change but algorithms are standard).
2) Job practicality - 99% of CS grads aren't going to use assembly in their day to day jobs. They will most likely be programming in Java, or VB, or some web language (PHP/ASP/etc). Maybe some C++. But unless you are doing something that requires the control that assembly can provide, like real-time software or game engine development, you simply aren't using assembly at work.
If it's harder to learn/teach, and you won't use it after you graduate, I can't see the point in teaching it at universities.
Mark
A good idea (Score:3, Insightful)
Teach architecture, not assembly (Score:2, Insightful)
Re:Not So New Concept (Score:5, Insightful)
I will agree with the parent post, this is not a new concept. Now teaching assembly to beginners, that might be new.
And I don't know if "great" coders know assembly, but I think knowing assembly is a useful tool in being able to program efficient code. If you understand concepts like division, how bad it is, what the computer is actually doing when your C/C++ or whatever language (that is not interpreted) is compiled, then you are well on your way to being able to produce efficient code.
Great concept. (Score:5, Insightful)
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.
CompSci's about more than that... (Score:3, Insightful)
Re:Whatever (Score:2, Insightful)
Being knowledgeable about low level operation of the machine will take you farther, since you won't have the fear of getting down to the bare metal to figure out a problem. And assembly language is important there... but also things like debuggers, protocol sniffers, etc. Anything that lets you get to the bare metal to figure out a problem will get you to a solution quicker.
Process and modern design concepts are important for large projects and at the architectural level.
Re:Probably a bad idea (Score:5, Insightful)
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
Re:Not So New Concept (Score:3, Insightful)
Otherwise, true x86 assembly is not THAT difficult to understand. People bitch and complain, but it really isn't that hard. Once you understand the concept of registers and interrupts, there really isnt that much more to it besides learning the commands. It really isnt bad at all.
X86??? OMG that sucks... (Score:5, Insightful)
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.
emulator (Score:4, Insightful)
Assembler-first might work with beginners if it was on an emulator where they could see exactly what was happening, and there was no way to crash it. Otherwise, I just don't see the point of making things harder.
Of course if you really want to make it hard, you hand every twelve-year-old kid a copy of Knuth and a hardware implementation of Knuth's hypothetical processor. Then our generation could be completely assured of job security.
Re:Somewhere in the middle... (Score:5, Insightful)
I'm with you there. I learned C, C++ and assembler while at university, and came out with the ability to jump into anything. Give me any language and I can guarantee I'll be churning out useful code in a VERY short amount of time.
Compare this to my brother, 12 years younger than me who has just completed the same comp.sci course at the same uni, and knows only one language; Java. Things change, not always for the better. I know many courses haven't gone to the dogs as much as that, but many have. I'm not surprised the idea of teaching coders how the computer works is considered 'novel'.
I can see a great benefit for humanity the closer computers move to 'thinking' like people, for people. But that's just not done at the hardware level, it's done higher. The people who can bring that to the world are coders, and as far as I'm concerned thinking in the same way as the hardware works is absolutely essential for comp.sci. Less so for IT.
Re:Good idea, Bad Idea (Score:5, Insightful)
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.
It depends where you want to go in CS (Score:5, Insightful)
Re:Programming or CompSci (Score:1, Insightful)
But yeah... I'm not writing support vector machine code in assembly. It's so not happening. (But learning assembly as an undergrad was worthwhile and I'm glad I did. But I'll probably never program in it again because it's not terribly valuable for an AI grad student. If a high level lang is too slow for an inner loop, I'll ask my advisor for a faster machine. If a faster machine won't cut it it's probably because the complexity makes the problem intractable for large datasets)
Re:Programming or CompSci (Score:4, Insightful)
I did learn assembly language first. I wouldn't claim to be a wizard (although i'm certainly an old-timer); but i concur with the premise that learning assembly language makes you a better programmer *and* computer scientist. Assembly language exposes you to the basic architecture of the computers that most of work with, and i believe that helps one to understand everything from why certain data structures are preferable in certain situations to basic computational complexity.
Re:Not necessarily the mark of a great programmer (Score:3, Insightful)
Ugh... x86 (Score:3, Insightful)
Learning x86 isn't a bad idea, and for most nerds programming assembly that's probably where it will be most useful, but I just think it's a better idea to start off programming ASM on something a little more enjoyable so that you can really learn to appreciate it before diving in with x86.
Re:Linux x86 assembly? (Score:5, Insightful)
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.
Learn assembly first, by all means (Score:4, Insightful)
Re:Good idea, Bad Idea (Score:4, Insightful)
I disagree. Personally, I learned Basic, then x86 asm, then C (then quite a few more, but irrelevant to my point). Although I considered assembly radically different from the Basic I started with, it made the entire concept of "how the hell does that Hello World program actually work?" make a whole lot more sense.
From the complexity aspect, yeah, optimizing your code for a modern CPU takes a hell of a lot of time, effort and research into the behavior of the CPU itself. But to learn the fundamental skill of coding in assembler, I would consider it far less complex than any high-level language. You have a few hundred instructions (of which under a dozen make up 99% of your code). Compare that to C, where you have literally thousands of standard library functions, a good portion of which you need to understand to write any non-trivial program.
There are already problems with people interested in CS getting turned off by intro/intermediate programming classes.
You write that as though you consider it a bad idea...
We have quite enough mediocre high-level hacks (which I don't mean in the good sense, here) flooding the market. If they decide to switch to English or Art History in their first semester, all the better for those of us who can deal with the physical reality of a modern computer. I don't say that as an "elitist" - I fully support those with the mindset to become "good" programmers (hint: If you consider "CS" to have an "S" in it, you've already missed the boat) in their efforts to learn. But it has grown increasingly common for IT-centric companies to have a handful of gods, with dozens or even hundreds of complete wastes-of-budget who those gods need to spend most of their time cleaning up after. We would do better to get rid of the driftwood. Unfortunately, most HR departments consider the highly-paid gods as the driftwood, then wonder why they can't produce anything decent.
Hmm, okay, rant over.
Not the point! (Score:5, Insightful)
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?
Re:Somewhere in the middle... (Score:2, Insightful)
LOGO is primarily marketed towards educational institutions. It is hardly ever the language of choice in the world of business.
Re:Forget Computer Science! (Score:4, Insightful)
By definition. Science is the application of a rigorous discipline in an attempt to understand nature. Computing has nothing to do with understanding nature and everything to do with implementing logic in physical systems.
This is not to degrade computing. In fact, computing is provably correct as it is based on logic. Science is a statistical endeavour in which nothing is proven, but theories are constructed which demonstrate usefullness and have not yet been disproven. Computing is, however, built on the results of science.
Maths is a branch of logic. Science is a branch of logic. They are of course cross-fertilising. Computing is so close to father logic as to be almost indistinguishable - it's just a way of logic happening in acceptable time scales.
Of course, you might disagree.
Cheers!
Re:Disclosure: The submitter is the Author. (Score:4, Insightful)
Teaching assembly good, but perhaps not x86... (Score:2, Insightful)
I think learning assembler is a great insight into an understanding of computers, but the old 8-bit CPUs were a lot easier to get a grip on, no pipelines, caches or parallel execution units to worry about. The C-64 was what I cut my assembly teeth on, and I still think that sort of machine is ideal.
To this end, I feel a great learning aid is a programmable emulator which can be run on a modern machine with all the nice bells and whistles, but the "chip" at its heart is something like a 6502 or 6800. The emulator environment can make the machine operation clearly visible, such as providing a graphical display, showing step by step what the "CPU" is doing. In fact the CPU doesn't even need to be real, it can be a made up device that exhibits some idealised characteristics. The system can support other devices too, such as a virtual text or graphics display that the emulated CPU can work with, memory chips, and virtual I/O devices (e.g. port adapters that show the port and DDR state as graphical LEDs etc).
About 10 years ago I developed such an emulator as a university project, and took it to a working demonstration level. Unfortunately I never did any more with it, but it was a good proof-of-concept and many of the CS profs saw it and felt it would make a great learning tool. Maybe it's time I resurrected it and finished it off/rewrote it. I'd be interested to hear from anyone with ideas about what sort of features this sort of aid should have.
My original design featured a drawing area where the system could be built from a set of predefined parts - CPU's, memories, I/O, then connected together (using dragged bus links) to create a memory map of the system. The instruction set of the CPU could be defined, which in turn was intended to generate an assembler for that CPU (this part I never got finished - I think if I started over I'd just stick to a fixed instruction set and hence a fixed assembler). In the running phase, the CPU was shown as a diagram of a generic CPU, showing all the registers, data paths, etc. This was updated and animated in real time as the user's program ran, and could be single stepped. It also had interrupts,which was pretty cool - watching exactly what happened when an interrupt occurred (the I/O adapter unit featured a timer/counter register which would cause an interrupt, or you could just click an "interrupt" button on the screen) was truly enlightening, especially as you could watch the stack being graphically pushed and popped as it happened! Naturally with all this graphical activity going on to show the working, it was pretty slow, but as a learning aid definitely good enough. I implemented a variety of animation levels to help speed things up. User's machine code programs could write characters to a 40x25 emulated text display at around 10cps, to give you an idea. This ran on a Mac with System 7, at the time typically having a 25MHz 68020. A modern machine would probably be able to do all this and turn in a half-decent emulation performance to boot.
I disagree (Score:3, Insightful)
Having used assembly a long time, and having met both programmers who did and did not learn it, I found that the former benefit from the better understanding of the underlying mechanisms, regardless of whether they actually used assembly at work or not.
Computer Science != Programming (Score:2, Insightful)
"Computer science is as much about computers as astronomy is about telescopes" --Edsgar Dijkstra
assembly and hardware (Score:3, Insightful)
Assembly allows you to get a little closer to the mechanism. And its really nice if your want to know how hardware works. Its especially good if you want to develop robots or gadgets that interface to computers. It's nice to learn about interrupts and flags and such.
That said - if I can use C, Java, Pascal, Basic or anything higher - I will. Because it'll take 1/10th the time. Plus all those wonderful libraries are a lot easier to interface to. Even for programming the little micro controller's, its really nice to be able to do it in C.
I started out as a computer programmer and have found myself branching in both the mechanical and electrical realms. Learning assembly:
"Peter Norton's assembly language guide for the IBM PC" I wrote a disk editor. It took forever - actually - I didn't quite finish. Got about 85% of the way done. Nowadays - I think a microcontroller would be a lot more gratifying.
Excellent Programmers (Score:3, Insightful)
You've got it backwards I think. The excellent programmers actually care about what they're doing, and as such have all learned assembly.
Teaching assembly to someone who doesn't care won't turn them into an excellent programmer.
Why don't you ask him? (Score:1, Insightful)
Why would you make a claim like this without checking it?
Difference in ideas about CSCI (Score:3, Insightful)
Some other programs may approach the degree as a professional/vocational type of program preparing the student for eventual work in the field of programming.
Learning assembly may be more beneficial to the student learning as an eventual programmer in that understanding some of the low level work that the computer is doing could be important in programming.
I'm not sure that the mathematics and concept work would help as much considering a lot of the ideas in this is more general and not tied to any specific architecture, so learning the low level process may not help as much.
An (informed) dissenting opinion... (Score:2, Insightful)
That being said, I disagree.
You can learn CS concepts in many ways. It's cute to learn from the bottom up, but it's impractical. I oppose it for the same reason I oppose CS curricula based on underdog languages (like Eiffel, to name one I was taught). I don't care how 'clean' they are, teach something useful.
If runtime efficiency matters, you'll know about it and eventually get down to the assembly level. If it doesn't matter, for the love of god please "optimize" for something that does: like readability, maintainability, extensiblity, portability, modularity, test-ability, etc.
Crappy fast software is still crappy software.
What we're really dealing with here is complexity, and how to manage it. Software engineers design complex programs for complex hardware. You can't possibly know every detail. Thanks to the magic of abstraction, you don't have to.
"Tight" code not always necessary (Score:3, Insightful)
The fact is, MOST of today's programming requirements do not need tight code. Computers have become so fast that even a few million extra operations isn't going to make a percievable difference. That's not to say that there isn't a need for programmers who can program tight code, but the point is that it depends on the application and the platform it will be running on. Programming a huge text editor program like Microsoft Word is going to need good OO code that is easy to follow. You don't want a C hacker trying to squeeze .00000001 seconds out of the spell checker, making the code unfollowable to normal coders in the process, just because he thought it was cool. The fact is, he probably gets a kick out of writing code few others can follow. Maybe that's worth it for applications that need to be very efficient, but for other types of applications it isn't and it is just selfish of a coder to do that to the rest of his team so he can feel superior.
In the end, how "good" a programmer is depends on how useful their code is and how quickly they can produce it. Usefulness isn't determined by efficiency alone, but by its maintainability and reusabiltiy as well. For some applications, assembly will help you, for others, it won't. Knowing assembly certainly gives you more flexibility, but not knowing it doesn't turn you into a "mediocre programmer". Hopefully, knowing it won't turn you into an elitist bastard like the author. It didn't me :)
Re:Not So New Concept (Score:1, Insightful)
You would think they would be protective against this sort of thing.
Why stop at Assembly language? (Score:2, Insightful)
But the one thing that annoyed me in Computer Science was whenever we did the really low-level stuff, the lecturers would say, "We can leave the extra detail to the sparkies (Electronic Engineers)"
So in my final year of CompSci I did Electronic Engineering 100! I highly recommend it to anyone who wants to look below the "high level" of assembly language and see what's actually happening at the chip level. And if you want to get even more detail, there's alway quantam physics...
Re:nah (Score:3, Insightful)
It's not necessary, and learning OO concepts will serve you very well, but given two equally competent OO programmers, but only one who knows assembly, I know which one I would pick.
In my line of work (games) - or any real time programming - understanding what's going on under the hood is vital. It also vastly aids in debugging, because sometimes dropping to the assembly level is the only way to figure out what's going on (particularly if you're getting a crash in a library you don't have the source to).
We also still do a small but significant amount of work in assembly (paralell vector calculations and the like). It's the superstars who know assembly and can actually do everything their job requires.
Re:Not So New Concept (Score:5, Insightful)
"A new book was just released which is based on a new concept
Re:Somewhere in the middle... (Score:3, Insightful)
I'm in a similar position. Started with C++ and have since picked up Delphi, Java, PHP and other scripting languages without a problem. But don't get too cocky. We have both found picking up similar languages no problem but I will guarentee that you WON'T be churning out useful code in LISP in a short time.
Re:Linux x86 assembly? (Score:5, Insightful)
About
Re:Linux x86 assembly? (Score:1, Insightful)
Embedded Systems?
I guess there goes the vast majority.
Huh? (Score:2, Insightful)
I didn't know The Art of Computer Programming was a new book.
Re:Programming or CompSci (Score:2, Insightful)
Why stop at assembly? (Score:2, Insightful)
First year Electrical Engineering [utexas.edu]students at the University of Texas at Austin take an Introduction to Computing [utexas.edu] class that starts with the transistor and uses a book [mcgraw-hill.com] written by Yale Patt [utexas.edu], a prof at UT that often teaches the class. The class then teaches how transistors can be combined to make memory circuits, how you store data when represented by bits (2's complement, floating point, ASCII text). You then learn to write basic programs for a simplified computer in actual binary machine code and actually run the code on a simulator developed by students in the advanced computer architecture class. By the time you get to programming in assembly you think it's a relatively high level language and are glad to have it.
The successor to this class picks up where this one leaves off and teaches C from assembly up with an emphasis on what actually happens when you compile, allocate memory, and other things that a lot of students overlook. C++ is introduced in a later class, as well as algorithms, etc.
I personally think that I am a much better programmer for having learned in this manner. I took a senior level class in the UT Computer Science Department (which teaches assembly much later in the game) and found that far too many students, including some that were about to graduate, still didn't understand the fundamental differences between handling text data and binary, non-text data in higher level languages. Most still seem to think code executes in a white fluffy cloud and wonder why on earth 119 + 133 = -4 in their program and think '133' == 133.
Re:Somewhere in the middle... (Score:3, Insightful)
LOGO is not for building applications, it's for teaching kids how to give a computer instructions. I've been tutoring some kids in HTML and CSS, ages 12 and 8. I forgot how much harder it is at that age to think in abstractions. When I try to explain broad concepts rather than concrete specifics, they have trouble following. That is why LOGO is excellent for what it was designed for.
There might be a couple kids that age that could learn assembly, but odds are most simply aren't developed enough to get it. Your mind simply isn't normally designed to operate at that level at that age. LOGO works there because the tasks are very specific with results a kid can see and understand.
I cannot believe you got modded "insightful" for making a statement like, "LOGO is primarily marketed towards educational institutions. It is hardly ever the language of choice in the world of business."
Well no kidding. Incidently, carrots are vegetables and not fruits.
Best assembler (Score:3, Insightful)
But, I still contend the best all time machine language was the PDP-11 instruction set. If anybody knws what they think was a better one I'd love to see it.
Re:Not So New Concept (Score:4, Insightful)
Now for my own rant on the topic:
My first programming classes at the University of Virginia had me programming in VHDL and m68k assembler. This wasn't the intent of the curriculum or the CS faculty at all, but rather a result of some schedule conflicts and a first year advisor who wasn't in the CS department and didn't know any better. It was a disaster. Normally students here get their first taste of assembly in a course that works its way down to it from the high-level languages they'd been introduced to first. My pain with assembly distracted from the course material on architecture. I learned more about efficient programming during two lectures on C# than I did while banging my head against the desk writing m68k assembler.
Anyone who has benchmarked the C++ standard template library extensively will tell you that using the fairly complicated, safely implemented data structures are incredibly fast. Using an STL deque as an array, without any deque operations, is actually faster than using an array, which is the same in basically any machine-code language, be it C++ or assembly. The STL vector is even faster.
Moral of the story? Compilers are amazing. This has not always been the case, but it is now. Writing code in assembly results in a product that takes forever to create, is less likely to correctly handle special cases, is impossible to debug, is unreadable to those who did not write it, and often is slower than compiled high-level code. In fact, JIT compilers are getting good enough that bytecode languages are nearly as fast as well.
It's true that assembly can often be used to get a bit of a speedup. This is why game developers will often write everything in C or C++ except for 3 or 4 functions that they'll implement in assembly. The advantages that high-level languages give for correctness vastly outweigh any miniscule performance gains in almost all circumstances. Assembly's advantages in compactness are becoming moot too, as embedded devices are now capable enough to run full-fledged operating systems.
Aside from teaching architecture though, assembly does teach an important skill to CS majors though, and that is staying up all night to find a one-line bug that is making everything go wrong.
Re:Linux x86 assembly? (Score:3, Insightful)
Yup. There'd be no software.
Re:Linux x86 assembly? (Score:3, Insightful)
Re:Linux x86 assembly? (Score:5, Insightful)
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.
Re:Linux x86 assembly? (Score:3, Insightful)
If applications were built like this in the 70's, we wouldn't have a computer industry.
I do not believe that needs to be true, and should become less true as the software industry matures. For some reason it doesn't seem to be maturing.
Re:Linux x86 assembly? (Score:2, Insightful)
Re:Disclosure: The submitter is the Author. (Score:1, Insightful)
lol, whatever. No, I'm not "him." I'm another "him" and I don't have a book to sell. But I am forced to figure out a way to make a living on my own because the "job market" has made it clear that my 10 years of experience and college degree don't amount to FUCK. I wish this had been explained to me before I spent the 20 years and $20,000
Don't whine to me about trying to make a living or trying to pay the bills. I've been unemployed for over 12 months within the past 2 years.
Oh, please. I've been unemployed for three years straight. I couldn't get a job painting shit buckets after watching my "skills" and "experience" lightly dipped in piss batter and skillfully tossed into a shit swamp.
The job market has found a perfect way to destroy human potential with nothing more than a resume. So that leaves us with somewhat fewer choices. And I'm FUCKING tired of seeing people who work their ASS OFF being called "scam artists" because they set up a cash register somewhere.
Just because you've got it tough doens't mean you can break the rules.
"Break the rules." What rules? Who made up the rules? Where can someone refer to them? I think it's "oh, it's got a price tag on it, therefore it's a scam."
If this person wants to resort to those means, go right ahead.
WHAT means? He says "here's a book about Assembly programming" and everyone screams "scam artist." It's a crock.
Who cares about learning about computers? (Score:2, Insightful)
Who cares? Knowing about computers per se isn't important; knowing how to use computers to solve your problems is. For this, high-level languages are best.
Re:Actually, they DON'T. (Score:4, Insightful)
Okay, you had me up to that sentence. It's my understanding from people I know who actually used VAX assembly, that it was a bear. Especially if you had to decode the assembly by hand. It had variable length opcodes, which if I remember right, a single instruction could extend to be upwards of 60 bytes. Oh, and that's not to mention, the 11 different addressing modes, which could be mixed and matched on all three operands (dest, left data, right data). Because all instructions could store directly back to memory, it was a bestie to create.
Call me crazy, but somehow that much mixing and matching just doesn't sound like [fun].
I didn't actually use the VAX instruction set - though I did use the PDP11's - both writing and reverse-engineering. They were both designed by the same guy (Gordon Bell) or teams he lead. I'm prepared to defer to people who actually dealt with it that the VAX instruction set was difficult.
But in the case of the PDP11 (where the few-instructions, lots-of-address-modes style came into its own), the plethora of modes actually simplified the job of the assembly programmer (and the reverse engineer). I can tell you this from experience.
Multiple address modes shrank the job of understanding the instruction set by splitting it into two parts - the much smaller set of base instructions than you'd need without the symmetry, and the small set of addressing modes. Rather than having an explosion of special purpose instructions with their own addressing modes, you have an explosion of combinations of the members of two small sets. Once you learned the two sets, the proper combination to achieve the result you wanted was obvious.
The tricks were few - and brilliant.
- The indirect-increment and indirect-decrement modes let you use any register as a stack pointer or index register, for instance. The "official" stack pointer was just the one that was implied by certain other features: interrupt and subroutine calls, primarily.
- With the program counter as one of the general registers, applying indirect-auto-increment to it gave you inline constants.
- The indirect and indirect increment/decrement addressing modes made any register a pointer. (They also led directly to the ++, --, +=, and -= operators of the C language.)
- The register+offset mode and base/offset duality gets you to particular elements of an argument array, or index into a fixed-location array.
and so on.
If you understand a few things about C (Array/pointer duality, walking arrays with auto-increment, etc.), you have exactly the understanding you need to grok the modes of the PDP11 instruction set. (Which is hardly surprising: I understand that much of C was inspired by that instruction set.)
Your analogy is incorrect, amoung other things (Score:4, Insightful)
Being able to tell your crew that you think your car is leaning out under hard accelleration or that your suspension is too stiff or unbalanced is made easier if you understand the physics and engineering involved. Most professional race car drivers know a very great deal about these things indeed. Unless you are born rich, most dedicated racers build and repair their own cars and know a great deal indeed about the tools of their trade.
I have an EE degreee; I was taught how to build registers from logic gates; how to build counters and adders from those; how to form the basics of a primitive cpu and implement one in vhdl; how to program x86 assembly; I was also taught how the electrical signals interact to make those things possible; the physics of semiconductors and the things that make those logic gates possible. All of those things have made me able to more effectively program computers on a high level. Why would we expect less from a CS program? Computational engines, computers, are the things that drive the CS profession. I would expect anyone in the field to be intimately aware of their theoretical underpinnings.
Ironically, they have also made me a much better driver as I am intimately aware of the workings and how to tune my car's EFI system than most may be.
Would you go to a doctor who has never taken chemistry? Didn't think so.
Compilers do this (Score:2, Insightful)
Computer Scientists aren't programmers (Score:5, Insightful)
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.
Re: Don't program at all (Score:3, Insightful)
lesson 2 (for the grandparent): It could just be that doing basic for 3 years prepared you to do asm, which obviously has a steeper learning curve. Also, you just did the same thing to the great grandparent that the stupid HS teacher did to you, conratulations on being a complete hypocrite.
Re:Linux x86 assembly? (Score:5, Insightful)
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.
CS != uber-coder degree (Score:5, Insightful)
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.
Re:Linux x86 assembly? (Score:4, Insightful)
Also, you do know that compilers are written by programmers don't you?
Re:Computer Science Curriculums (Score:3, Insightful)
and 68HC11 chips may not be the latest and greatest, but I'd bet they still get spec'd in lots of embedded products (where you would be using assembly)
Re:Good idea, Bad Idea (Score:3, Insightful)
One problem that I've found with many CS programs is that they put the knowledge ahead of the motivation for the knowledge. Teaching assembly first would be a prime example. The teachers may believe that this will provide a simpler and more understandable foundation in which their students can learn to program. However, none of the students can actually do anything remotely useful in assembler. Therefore they will exhibit remarkable indifference to the subject matter.
If they were being taught in a language like Java, C#, or even Perl, then they would be working in languages which they could use to produce useful programs. The utility of the knowledge gained would motivate them more than the fear of getting a bad mark. At least that's just the way my own brain works....
Re:Linux x86 assembly? (Score:5, Insightful)
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
Re:Linux x86 assembly? (Score:5, Insightful)
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.
You're a little bit confused. (Score:5, Insightful)
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.
Assembly for speed? (Score:5, Insightful)
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.
Then make it binary! (Score:1, Insightful)
Re:Forget Computer Science! (Score:3, Insightful)
You sir, have confused Computer Science with Computer Engineering. In actuality, Computer Science research ends up a massive agglomeration of Mathematics, Statistics, and Physics. Computer Science attempts to understand nature in many ways, both with and without the assistance of a computing tool: by understanding the nature of different questions and how difficult they are to answer (language theory, complexity theory, etc.), by attempting to find algorithms that mimic the natural phenomenon of a mind (vision, agents, etc.), by motivating numerical simulation of natural phenomenon (photorealistic rendering, inverse kinematics, etc.)
Of course, you might disagree.
Of course.
Re:I think Jon von Neumann would agree, learn ASM! (Score:3, Insightful)
But learning assembly != learning architecture, and with the x86 it is probably counter-productive since you have to explain afterwards what the processor really does behind your back when you use memory operands, string instructions, etc... Understanding the architecture is important, but assembly language in and of itself is not that important, and x86 is an especially bad choice.
Re:Linux x86 assembly? (Score:4, Insightful)
I learned Asm before I learned C, and I must say that was a good way of going about it. I'm glad I don't view C as some sort of "hocus pocus", and I never did. Everything just made sense. Now-a-days you've got Joe Blow with dollar signs in his eyes and his shiny new degree in using Java, who doesn't understand the little black box he's entering commands into.
It sort of pisses me off, because I don't want to put gay little buzzwords in my resume like C#, or Java, or
Assembly = excellent programmer ? (Score:2, Insightful)
Does it also means that you can't be an excellent programmer without knowing assembly ? Well that certainly depends on how you define an "excellent programmer" but i think it's quite quick of a conclusion.
That said, if assembly can certainly be harsh for newbies, the lack of abstraction can certainly be helpful in some cases. But appart from that, i'm not sure that it will change much from the current situation (as good or as bad as you want to see it).
Really Simple Machines instead.... (Score:2, Insightful)
As a kid, I did a lot of stuff on them, mostly just tinkering. Some of the things I did were to do with like building a multi line input system like I'd seen on a mainframe at college (so you could tab to fields). It was all built in BASIC, but from it, I understood the concepts behind things.
Re:Linux x86 assembly? (Score:2, Insightful)
In general, working Engineers (non-PhD's, software or otherwise) don't contribute to to advancement, i.e. research papers. They work with the tools they're given to solve problems.
Re:Assembler and the dragon book ... (Score:3, Insightful)
Take a proficient programmer who knows an HLL and assembler, feed him the Dragon Book and you _will_ have a better programmer in the end, though. So your point is certainly valid, but the timing of that book's intro should be carefully planned in a curriculum. If you're not proficient with an HLL, and at least halfway competent in some form of assembler, it will totally fuck you up.
Re:Linux x86 assembly? (Score:2, Insightful)
Re:Not So New Concept (Score:2, Insightful)
They teach Scheme, which doesn't have OOP, but allows you quite easily to implement your own in a good page of code. As for LISP in general, maybe you should read up a little on it before you talk about it....
See Common Lisp [wikipedia.org] and CLOS [wikipedia.org].
This doesn't turn people off of computer science, IMO-- quite the opposite, it allows them to focus on the problem solving aspect of CS before getting down to the nitty gritty of having to deal with complex syntaxes in other languages and low-level optimization.
This brings in another point.... Programming is all about problem solving, so why should a beginner have to worry about doing it step by step according to some arbitrary machine's low-level instruction set? It's like telling someone to learn to build houses by building his first house using only his hands and a forest-full of trees. It's educational in a masochistic way at best. It's wrong to omit it completely, but still better to teach later in education, I think....