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."
Is "Linux x86 assembly" any different to any other kind of "x86 assembly"?
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."
Isn't that what Knuth did with his ASM language? I believe it was a synthetic assembler for a hypothetical stack machine -- hence the name ASM - Abstract Stack Machine.
The only reason we have the rights we have is that people just like us died to gain those rights. -- Cheerio Boy
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!
This is akin to learning medical science by practicing on yourself :)
The best programmer I know knows C, C++, and Java. He got Class 2 Dvision 1 honours (UOW, Australia) in his degree for programming a digital watermarking system in C++ ...
Pretty much a genius, but I don't think he knows assembly.
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
Knuth's The Art of Computer Programming was illustrating the algorithm in an imaginary assembly language.
Good Idea: First teaching simple programming fundamentals through a simple to understand language. Then, confuse the hell out of a student with assembly Bad Idea: Teaching CS by starting with one of the most cryptic languages around, and then trying to teach basic CS fundamentals. There are already problems with people interested in CS getting turned off by intro/intermediate programming classes. Imagine the retention rates once my CS100 class is taught in assembly.
AoA, a worthwhile read
What we need are programmers that are taught software process.
How we know is more important than what we know.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
for one thing, it would certainly knock a lot of people out of the profession if the first language that they tried to learn was assembly ... though this might mean that eventually the only people writing code at least know what they're doing, therefore producing better products for the users
"but money is the God of Algiers & Mahomet their prophet." - Rich. O'Bryen June 8th 1786
I thought schools, at the very least, would teach assembly as introductory!
Real programmers learn machine code.
What you meant to say was that your new book has just been released. If you're going to pimp your wares on Slashdot, at least put an appropriate disclaimer on. That said, I completely agree with the premise of the book. I've met a lot of mediocre programmers, and a few good ones. But I've never yet met a real star that didn't have some background in assembly language programming. Personally, I haven't written anything in assembly in well over a decade. But that fact that I can do so if needed makes me a better programmer, and I'd recommend it to any aspiring coder as a key skill to learn. I wouldn't say IA32 is a particularly nice introduction (I'd start with a cleaner, simpler architecture, such as 6502), but it is at least widely available to anyone that wants to study it...
"The invisible and the non-existent look very much alike." -- Delos B. McKown
I don't think that's necessary. Unless you need assembly, why spend the time? I think your time would be better spent working on object oriented concepts and the guts of programming in general, ie: variables, conditionals, types, etc. etc.
just my 2 cents
we are all one consciousness experiencing itself subjectively - bill hicks
The think concepts of registers and memory locations and stack pointers and branching is easier to understand in assembly. You can teach a simple subset of instructions. It was the way I started back in the day. I scratched my head more later learning C, etc. I guess its just the opposite to kids these days.
If i start getting a program together i want it to do what i want, and i don't want to spend to much time on hacking it together. Sure using assembly to create a program will make it faster (when used correctly) but it will take ages to develop. A language which takes this out of my hand and makes my development cycle shorter so i have more time for design and testing is more preferable over the time consuming task of programming it in assembly. Especially since most time spent on software is in design and testing, implementation needs to be as fast as possible. And with the new computers having processing power beyond anything even imaginable 10 years ago the use for assembly is quickly deminishing.
I go to the Milwaukee School of Engineering as Computer Science... One of the first things we had to learn was Assembly and we have to build an OS using it for a small car project before the end of our junior year. In addition, we have several courses dealing with the MC68HC11 processor that are helpful.
Assembly should be known by anyone programming a computer, otherwise you can never really know what your code is actually doing.
This assembly language, it speaks Hindi?
should look at this book. At the highschool level, atleast around here, Algonquin (one of the better public high schools in Mass), does barely any Computer Science beyond the basics. They teach enough C++ to print messages on the screen and write files. I doubt they get to the API although they may. The also have your basic Java and VB courses. I think, not only should they teach low level programming, but our public schools need better and more programming courses. For example, you shouldn't be required to take C++ 1 Printing the screen to take C++ 2, etc. You should be able to start at your own level. Sorry if I'm ranting, I'm just annoyed at the schools CS courses and think that they should have more in the way of that. Especially assembly. I think this book would be great for it.
http://www.beyourowneviloverlord.tk
http://www.frozenchickenthrowing.tk
http://www.killercamel.tk
lol. only a low slashdot id can get away with posting that as a non-AC.
got modded up to boot.
ahhh. today's been a good day. didn't even have to use my A-K.
Please learn Assembly, we need it.
Thanks,
America
"This isn't a study in computer science, its a study in human behavior"
Bloody time students learn the basics before building horrid Java 2 Swing GUIs. Not that the easy interface builders and very high level languages aren't nice or useful (Perl lets you get many complex things done in a hurry).
This is a book for the home library as well as University book stores!
I think this is a bad idea, for a couple reasons.
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
Hey, this is what I've been saying: Learn ASM structure (x86, but MIPS would be easier) Learn High-Level structure (C/BASIC/Pascal/etc) Learn OOP structure (C++/Java/Python) Instead of this stupid data structures core all the colleges are going with. Then set up a bunch of in-depth language classes, ex. on Perl, or Lisp, or whatever to actually learn the languages. They were teaching Pascal a little while ago in CS, but who ever uses it now? Why teach a language that is going to be obsolete when you could teach the structure, making learning the languages easier later on. Every job I've had has required me to learn a new language: I had to learn VRML (remember that?) a couple years ago, and I haven't used it since. Hmm.. Should probably read the article now, huh?
I [may] disapprove of what you say, but I will defend to the death your right to say it.
If it isn't worth doing in Brainfuck*, then it isn't worth doing.
*Author's note: Brainfuck can be replaced with Perl.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
http://savannah.nongnu.org/projects/pgubook/
It's also being used at Princeton
I agree with the sentiment that knowing assembly language maketh a programmer, in some circumstances. It allows a deeper understanding of how certain languages work "under the hood", and how to debug errors that may not be so easily detected by than just staring at code. Knowing C and assembler, for instance, is a good match in my eyes.
It may not be so important though, if you're a database programmer, or if you're dealing with high-level languages such as Java or something.
assembly is the great monster that requires fresh blood every year, or the great darkness will fall upon the land. i myself have never dabbled in assembly because i don't like living in an hp lovecraft nightmare.
For those of you insane enough to take the plunge, check out this FREE online introduction course (no reg, don't ya love it). The guy who wrote it is pretty wacky. I took his java introductory course and it was hip as well as very educational.
...Must strangle self...before too late...
A feeling of having made the same mistake before: Deja Foobar
That's a low ID? Youngins'
====
Crudely Drawn Games
Get it to your Valentine on time! Choose UPS 2 DAY and pay the price of Ground.
Yeah. Give my GF a book on Linux Assembly programming. That should get those panties off in a hurry.
"Quotation is a serviceable substitute for wit." --Oscar Wilde
What about all the engineers who may need a basic understanding of CS for whatever applications they may have to modify, use, etc.? Engineers need very little knowledge of machine code as they often just need to create some Excel Macros, small scripts, etc.? Assembly would provide no benefit in this case, only prolong the learning process. Just because I use a car doesn't mean to drive it I have to be a mechanic ....
wtf?!?! There is no review here of an unread unreviewed book. This whole article is a sham. Do not buy this book. This book is the submitter's self published ego project!! Warning!!
For some reason this tired joke always makes me laugh.
Perhaps it's time that computer science curriculums start teaching assembly language first.
Here at University of New-Brunswick (Canada), they may not teach assembly language "first", but we do have a second year course dedicated to assembly and the inner workings of computers. My only problem though at the school is that we learn the Motorola M68HC11 cpu and not current ones. Sure it's easier to learn and understand, but most computers we work on today are x86 based.
My 2 cents.
There's nothing wrong with AppleScript!
Drill baby drill - on Mars
I agree that assembly language should be taught, but not necessarily as the first language. BASIC is a good tool for teaching higher level programming ideas like conditional statements, loops, etc... Once those concepts are understood, C should be taught. I was a fairly proficient C programmer before I learned assembly (68k), but even then assembly helped me understand much more about the inner workings of C and what lines of code do. Instead of just knowing that code I write works, I now know why it works and I am able to do much more advanced things with a low-level knowledge of programming.
It's good to know assembly to understand the operations of a computer, but assembly isn't practical for production use. You could design your system with a specific microcontroller and write your microcode with assembly. But if for some reason you have to change chips, you may have to re-write your code. On the flip side, if you used C or some other portable language, you could compile it to other chips...perhaps with just a few chip-specific changes.
$cat
if you really want to teach them, start even simpler -- RPN arithmatic is pretty much all you need to know about pushing and popping :)
Old age and treachery almost always overcome youth and skill.
at the University of Michgan that started off with a description of logic gates, moved up to the ISA, and then started us programming in actual binary (yes, we manually programmed the memory with 1's and 0's).
We then (quickly, thank god) moved up to assembly, and finally a bit of C. Our last program involved writing it first in C, and then acting as the compiler and translating the code into assembly.
It wasn't on x86, but a much simpler ISA that ran in simulation on a PC. It was pretty cool, figuring out hacks to re-use registers and cut down code.
Alas, the year I took the class was the last year they offered it. Now all CS majors and engineers start off with C++ and Matlab, taught in a hackneyed fashion.
I think it's a little weird to call this "Learning Computer Science via Assembly Language." It's programming, not computer science. Computer science is really only marginally about computers. It has to do more with algorithms, logic, and mathematics.
You can study computer science, and produce new knowledge in the field, without ever touching a computer.
This misunderstanding is, I think, part of the reason so many students drop out of CompSci. They head into it thinking it's about programming, and are startled to find that computation and programming are not equivalent.
That's why the Compilers course at PSU is considered the "filter" which kills all the students who aren't really interested in computer science. They really need to spin off a seperate "Software engineering" school for these students, since what they really want to study is programming.
real programmers do:
copy con myprogram.exe
can I pass my MCSE?
...it's a way to make better programmers out of the ones that aren't prodigies.
If you understand how the CPU does things and understand something about how that compiler for your preferred higher-level language does things to the CPU, you're likely to produce vastly better code than someone that doesn't understand WHY it's not as good an idea to increment a number in C/C++ with something like:
i = i + 1;
as opposed to:
i++;
assuming that 'i' is an 'int' sized integer...
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
It's pointless to teach assembly as a method of creating "star programmers" -- all you'd do is teach people how to write a for-loop but in ten lines instead of three (in a higher level language). The real benefit that people get from being good assembly programmers is understanding the inherent problems/benefits of a certain processor architecture and that's what lets them generate good, optimized code for the platform they are engineering for. Teaching assembly may provide some insight into that but all it really does is teach a new language. Teaching the architecture would give the student real appreciation of what's going on and how to build efficient code. Because think about it: assembly only describes what the architecture is capable of doing.
Well, for starters the syntax for assemblers is different. There are two standards, the AT&T standard (which is used by the GNU assembler) and the other one that is more familiar to DOS/Windows x86 assembly programmers (which is used by the NASM assmebler).
Second, OS interfaces for making system calls (e.g., to read files, open network connections, etc) are different in Linux versus DOS or Windows).
My other first post is car post.
I think the article should have disclosed that the submitter (johnnyb) is also the author of the book, Jonathan Bartlett. So rather than saying "A new book was just released", I would rather see something like "I wrote this new book." Here is johnnyb's website. http://www.eskimo.com/~johnnyb/
I've always wanted to know how a buffer actually works in terms of memory, etc. I just bought a copy. Perhaps I'll graduate to being a real hacker after all...
Most accredited institutions do require atleast two or more semesters being exposed to assembly. I personally learned it at my univeristy (Univ. of Nebraska-Lincoln) during my second semester of college. First semester was basic Java, drawing pretty colored circles, string manipulation, console args, etc. Then moving to basic computer hardware/software interaction with a emphasis on MIPS assembly.
I couldn't see how one could earn a degree at all without knowing assembly. How do you expect to grasp fully the ins and outs of computer programming in a high-level language without first knowing how all those ints, char and arrays are stored in memory and arithmetic moves around those values stored from processor to coprocessor, ALU, etc.
Real men type in opcodes on a hex keypad. These assemblers kids use these days - pfah!
Low as in lower than 50% of the 'unwashed masses.'
It's like a 102 year old calling a 97 year old a spring chicken.
An interesting thing for programming newbies to do is to write a small piece of code in C or C++, then study the assembly output.
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.
A computer scientist doesn't necessarily know anything about computers. Computer science is about the theories of computation, not about the details of programming.
Now, there is a certain benefit to knowing how the computer works at a low level, but its becoming less and less important. Especially considering that x86 assembly is completely different from how the CPU actually works at the lowest levels! I'd be much happier with a programmer who had a good grasp of the abstract theories of computation and didn't understand hardware at a low level, than one whose knowledge was the other way around.
A deep unwavering belief is a sure sign you're missing something...
After owning my own computer company several years creating ZDOS (an OS) for Micronics Systems. I went to work for someone else and I was shocked to learn how little the programmers know about the systems they wrote for.
I think besides learning assembler real programmers should design, or at least interface, a little hardware.
There are 10 type of people in the world, those who understand binary and those who don't.
I am taking an intro course on asm and I am confused as hell...I started out w/ c++, then cobol(shudder) and now assembley...the book we r using is horrible plus we are using assembley on windowz...
What's so amazing and revolutionary about this? Of course those cheap "get a degree in computer science" curriculums teach only specific languages at the expense of putting out truly capable programmers. But many regular colleges and universities have had more complete studies including assembly language all along.
The only real positive I can see in this - a lessened dependence on the OS and pre-developed libraries to do all the work for them.
I was taking one day at a time, but then several days got together and ambushed me. (from a Rhymes with Orange comic)
I learned 6809 assembly language on a TRS-80 Color Computer as a kid back around 1978 and I feel that an early start in understanding CPUs from the ground up has given me a leg up on many of my peers over the years. 25 years later I can still tell the difference between programmers who have a basic understanding of how assembly language relates to CPUs and higher level languages and those who don't. It may not make much of a difference when writing Perl scripts or Java apps, but it makes a world of difference in being able to write robust and efficient C code.
There is no review here of an unread unreviewed book. This whole article is a sham. Do not buy this book. This book is the submitter's self published ego project!! Warning!!
Assembly programming is almost hardware programming. If you want to learn about programming real computer programs, you'll have to learn about algorithms. And algorithms are best implemented in higher level languages. Assembly is only used when all other options fail.
This is your sig. There are thousands more, but this one is yours.
I can hear my dad now: "We didn't have these fancy-schmancy high-level programming languages... sure, there was FORTRAN, but that was just for the wimps who couldn't handle real programming. When I was your age I wrote assembly programs on punched cards, and it took three days just to feed "Hello, World" into the card reader. I had to push an IBM 360 uphill to and from work everyday in a snowstorm. Kids these days with their VisualBASIC and their HTML, they don't know what real programming was."
I'm glad to see this. Today's web-server script kiddies won't have anything to be curmudgeonly about unless they learn to go under the hood.
I am Sartre of the Borg. Existence is futile.
It's about optimal instruction usage, language design, automata, and a lot more. It's about optimal computing all the way around.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Whether or not you need to know assembly depends largely on your needs. May folks, such as web developers, never get really low level, so its not a needed skill. For us we rarely get closer to the hardware (or OS for that matter) than a high level language.
Java/Perl/C++/etc. are more or less cross platform... we're not tied to a specific architecture.
"Faith: Belief without evidence in what is told by one who speaks without knowledge, of things without parallel." - A.B.
In the BYU CS department they've recently gone a little farther than starting with assembly language. The introductory programming class actually begins with digital logic gates. The next section deals with assembly programming using the contrived LC (Little Computer) opcode set. It's a much smaller set of opcodes than x86, so it's simple enough for beginners, but still contains the important elements learned from doing assembly programming. The course ends with an introduction to C++ and OOP. I think the change in curriculum is a very wise idea. I took a class in digital circuitry and it has helped me so much in my programming. I'd like to see more programs move in this direction.
Any of you old C64 wonks remember what the following code would translate to? $20 $D2 $FF
What would that do on a C64?
So I say, forget assembler; it's too high level. Make those kids flip bits, for g'd's sake!
The CB App. What's your 20?
More chance of employment that way
kthx.
This is why the old-timers are often viewed as 'wizards': they had to know assembly language programming.
All the "old-timers" I've ever worked with held complete contempt for us wacky kids and our crazy, new "fads" like OOP that would surely fade away and everyone would go back to COBOL and fortran like they did it in the "old days".
I'd imagine it's like learning Latin, and armed with that knowledge you then find it easier to learn modern European languages since that's what most of them evolved from.
I'm a great believer in the idea that no knowledge is wasted and that learning specific skills is no guarentee that you'll be any good at a particular task. I found it easy to pick up programming at school thanks to me programming BASIC on a Sinclair ZX80 at home years before. I found it easy to pick up Spanish and French because compared to learning Irish, Spanish and French are dead ringers for English!
I have zero experience with assembly language, but it's something I'd love to be able to do.
Drill baby drill - on Mars
Have things changed that much since I graduated in 1999? Can you really get a degree in computer science without at least one course dealing with assembly?
I know we had one course on computer hardware and assembly. There were at least one or two others that touched on the subject. It wasn't much but it was something.
Knowing assembler doesn't help me too much at work where I am forced to write in VB6. It does help a lot with my projects at home that use microcontrollers. In that invironment, even if you can use C, you still need to know a lot about the hardware you are working with.
Here in Loughborough, on my course, it is one of the first things that you learn, after that you are introduced to C and Java, ofcourse I had knowledge of those before but some had their first taste of programming with assembler.
:(
Only straight computer science learnt assembler, however. Computer science with Business were learning VB, and didn't even look at c or java and I think that is wrong! Do u?
Jimbob
Everyone here is talking about CS fundamentals this and that...I don't know what assembly is.
College students should be taught CS basics like MP5 usage, burst firing, and not to camp.
http://www.cse.msu.edu/~miscisi2/security/pages/ex ploits/overflows.htm
I feel (fairly strongly) that if a person hasn't programmed before they should first be taught an interpreted "write it, run it, no hassles" language like Scheme, say.
Get the basics of structures and design down first in a language that's trivial to understand and highly interactive, whatever it is.
While I guess I'm an oldbie (*sigh*), I don't think too many people need to know assembly any more, how the MMU works, etc.
Can it help? Of course--as with anything, the more you know, the better off you are. But I'll take a well-trained Java programmer that doesn't even know assembly exists before I take a crappy coder that has memorized the x86 instruction set.
They need to know how to _code_ and the web/MS jockies I see coming out of school now, in large part, can't.
Dave
But in EE, our first programing assignments were in binary. That's right. Ones and zeros. Then, as favor to us, they started letting us use an assembler. Wow, how thoughtful :)
Seriously, though, I know of a lot of CS departments that don't teach memory management at all until third year. Up to that point, they use languages with garbage collection and say 'and then, when you are done, your memory just disappears. Magic.' That's not even the least helpful part. Most of the those languages have classes for just about any ADT you can think of, so no one has to write one themselves (which leads to questions in embedded programming/operating systems classes like "How do you create a hash table object in C?")...
====
Crudely Drawn Games
When I took computer science, we learend Pascal, and a little bit of the art of structured, procedure-driven programming. Unfortunely, in high school 'ADT' only meant an alarm company. Then in college, we learned C. Again more procedure driven stuff. Sometime before I graduated, a teacher taught us C++. Needless to say, our programs weren't very object oriented, nor were they required to be so. The algorithms class we took (also in C), was also extremely lacking, and 'ADT' only became a fuzzy word for doing a lot of extra typing that didn't make sense. Unlike most of my classmates, I knew assembly language for several platforms already. This being said, if you start out, introducing people to programming with assembly language, most people will quit and become liberal arts majors. The few that do continue, may be able to make the jump to a procedure oriented language AND be able to trust what the compiler does behind their back. Those that don't even think about the compiler's affairs are highly suspect... They are really going to be baffled by object-oriented programming. Transistioning from the world of goto's, subroutines, and jump tables to virtual methods and multiple inheritance. This being said, what should be done is to teach assembly language in parallel with something like C. That way, people get a feel for the timing of things -- why floating point arithmetic is slower than integer arithemetic, why sequentially reading arrays is faster than linked-lists, etc. More emphasis also needs to be put on the operation of the memory and disk caches (for data structures), operating system scheduling (multi-threaded apps), and overhead of system calls. Imagine the horrors that someone would produce if they transistioned directly from assembly language to an object-oriented language! -- one class, one method, one program!
Could anyone comment on the use of assembly in major open source projects? Is there any now? Will its use increase to take advantage of vector units and the like? What about cross-platform assembler? Could we one day see an assembly dialect with the traditional 'raw' access to the machine which hard core developers love, coupled with a Java-like virtual machine for cross platform compatibility? I look forward to the community's response!
I refuse to be an old-timer just because I know several flavors of ASM (Z80,masm,29K,PPC).
What will the next be? That we can recognize a computer 8 out of 10 times....Geez
Nobody expects the Spanish Inquisition (except the spelling control)
MIXAL, MIX assembly language. MIX was the virtual machine I learned assembly on in 1975. Googling reveals that MIX was, in fact, the Knuth virtual computer. The book came with a little cue card with a picture of Tom Mix on it. MIX has 1 K of memory. Amazing what can be done in 1 K.
Fundamental Algorithms, volume 1 of Knuth's well-known series, handled nearly all of the programming exercises in MIX, his "virtual" assembly language that modeled capabilities on a variety of real processors. There were and are a variety of simulators for it.
Another one is this relic I have on my bookshelf: cardiac, "A cardboard illustrative aid to computation", by David Hagelbarger and Saul Fingerman of Bell Telephone Laboratories. It's literally a cardboard "computer" on which you write decimal instructions, move sliders around for addressing and opcodes, and use a cardboard "bug" (a ladybug) as the PC.
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.
is that a new object oriented language?
I agree. Teach these kids the differnce between a shift and rotate, make them understand what the CPU is actually doing.
To those saying that time would be better spent learning higher level languages better or that development is faster/easier with C*, Java, etc, you're missing the point ot the article. He's not suggesting that more people program in assembly instead of higher level stuff, but that knowing assembly will allow people to program better in the higher level languages.
Yes the compiler and assembler will make a lot of optimizations for you, but you likely could enhance the application's performance by making small changes to your code that aren't apparent unless you really understand how your processor does what it does.
Most modern languages allow you to embed or link to assembly code, so you could have the best of both worlds, ease and speed ot high-level development with the speed and efficiency of assembly.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
There's nothing, absolutely nothing, that can be taught in assembler that can't be tought in e.g. C. And C is at least useful in your future life as a burger flip...I mean computer programmer.
They should start with C, which is good at teaching basic procedural programming, move to Java, then go back to assembler to teach the student all the details that were glossed over in those other languages (e.g. what is a pointer really? What is the "stack"?).
I loved assembler back when I was like 18-19 and you used to have to write MSDOS viruses in assembler with int 21 hooks etc... But otherwise it's a small subset of people that really need to know it, and it's easy enough to learn.
I was a teaching assistant for an undergraduate course in assembly language. (We happened to use the MC68000 as the processor, with those nifty little test boards hooked to dumb terminals for entering and running your code.) This was in the mid 90's. I still vividly remember trying to teach the multitude of indirect addressing modes that the MC68000 offers, like indirect, indirect indexed, etc., etc. By and large, the students, mostly second and third year computer science and EE majors, had a real rough time getting the hang of all of it. I tried to draw analogies with the way C pointer arithmetic works, but they were never taught pointers in their C++ course. I was pretty horrified at that. Like you can do anything in C++ beyond the basics without understanding machine addressing.
Of course, the ones who had some experience with lower-level languages knew what I was talking about and had no problem with the concepts. They also tended to be the best performers and, in my opinion, seemed best cut out for the career they were aspiring to. I guess my point is that hardcode assembly may not be important in the very beginning, but I agree that being exposed to it can really help you understand how processors work, and I think can make you a better overall coder. The things you learn down low can't help but pay off when you get to the higher levels, because you can see why things up there are how they are.
In college the Comp Sci's had to take assembly. (I took it for fun. Yeah. Fuh.) They spent a bit oh assembly, but much more time on computer and processor structure.
I do security
real EE's learn not only that but machine language, instruction decoding and control of sequential logic machines at the register transfer level, memory elements and logic gates, how transistors and CMOS works, the quantum physics and electrical properties of semiconductors as well as pulse signal propagation, transmission lines and impedances, etc.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Though this sounds really interesting to me personally...
I understand assembly language. I understand how the computer works on it's lowest levels, more so than most programmers I've met.
Does that make me a good programmer? Hell no..at least not in anything other than assembly.
Now.. learning some assembly and some low level stuff is GOOD for a programmer to know, to really understand what's up and take away the magic black box.... but it won't make you a good programmer.
It doens't help me understand, say, java.
Or C++.
IT does make C and pointers a bit easier to understand.. as well as things like memory allocation.. but other than that, nope.
I think one would be much better off writing in C without optimization, then stepping through the execution in a disassembler to see how the resulting machine code operates. Yes, it helps to write more efficient high level code if you know how it is converted to machine code. For example, I had a coworker who made a habit of declaring initialized arrays local to his functions. I had to point out to him: "You do know that this causes the array to be copied onto the stack every time you enter the function, thus really slowing down program execution, don't you?" Apparently this had never occured to him, because he had never actually watched the code execute.
"Freedom means freedom for everybody" -- Dick Cheney
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.
Find free books.
Back in the day (mid-80s), our computer curriculum went like this:
1. Machine language (hex coding)
2. Assembly
3. Pascal
4. There was no 4
If you ask me, even though I didn't go into programming, by taking these courses (and understanding them) I am a better systems engineer, because I do know the low level stuff, and how that affects the systems I'm working on, be it infrastructure, network OS, or client side.
(bad metaphor) It's like cars. There are end users who get stuck on the side of the road. High level programmers who can work on their cars and even put one together. Then there are the low level programmers, who can make a sweet car, know the mechanical tolerances and even do some under the hood innovations. A good mechanic can put an engine together, a great mechanic can pick the materials and the molds and work on indy cars.(/bad metaphor)
--
My sig sees you
Most great programmers today have learned assembly - but that's just because they're older and assembly made more sense in the past. But that's no reason to look down on programmers who don't know it.
I know assembly and it has zero influence on my programming style. It's even quite impossible to use modern languages like PHP and java in an assembly (un)friendly way. Algorithms are what counts.
Of course there is a very small very high performance niche for assembly, but that's not what this book it promoted for.
I agree with the premise that machine language knowledge makes a fundamentally better programmer.
But it's only one of many factors to consider. As a predictor of success, there might be a stronger correlation with having a background in math.
Try googling for "programmer" and "predictor of success". Quite a few papers turn up.
...from training *Real* (read Mechanical) engineers.
You begin with the basics; (drawing, CAD modelling, math, physics, fluid and thermodynamics) and then you move up to applying these techniques to more and more complex systems until you peak with project management, limit state design etc. Essentially you learn the fundementals, then learn how the tools are designed and built, then how the tools work then how to use the tools; now you know how to create solutions to problems no-one else has ever encountered because you understand the cause, not just the effect.
I firmly agree that the only way to teach something is to start with the foundations and move up; although to critique all the programmers I know, they could benefit from a LOT more mathematics, particularly in the areas of numerical methods and non-linear differential equations.
Teach people how to solve abstracted problems (ie: simply make on-paper mathematical soultions to problems); teach them how computers *actually* work and then teach them about how the tools (HLLs) are built and work; let them make their own choices from there. Why should a class teach "C++", shouldn't it teach object oriented programming and let students select which tool they feel is most appropriate??
Hell, somethings are better done in Perl than C++, C++ than Fortran, Fortran than assembler, machine code; if you aren't trained to understand *HOW* tools work, you will never be able select the correct tool for a job or even design better tools. More importantly, if your training focusses on a specific tool or brand of tools, you wont know how they all work.
Case in point, I, a mechatronic engineer, know far more languages than any one of my comp-sci/programming mates but still use them equally well, because I was taught not how to use a specific language but how to solve problems, the languages I taught myself since I already understood *how* they worked; I knew the grammar, I just needed the dictionary as such.
Anyway, enough rambling...
err!
jak
Forget Computer Science, Computer Engineering is the way to go.
First year starting with Digital circuitry, electrical stuff, engineering maths, heck, even physics. And concurrently? Teaching us how to program (not a programming language) with Pascal.
--- Follow on to Object Orientated programming, a dash of graphics programming - all concurrent with more digital stuff (onto microcontrollers etc) and micro-controller assembly language. More horrific calculus. --- Onto Operating System architecture, file systems, software engineering (UML and all that horror), Hardware Description Languages. Oh yes, telecomms, networks, etc. --- Language Processors (compilers, parsing, etc.), Artificial Intelligence. More networking. Computer Architecture.
That's some stuff - I've left out a lot. Not bad for 4 years. Basically everything from how semiconductors work and electrical circuitry, and most steps through to high level software design and object orientated programming. Plenty of side routes too like Digital circuit design, microcontrollers and using HDLs.
It's all been good bar the calculus. Oh, and the UML stuff - i.e. waffle for waffle's sake.
-- *~()____) This message will self-destruct in 5 seconds...
Why don't they teach Brainfuck at first ? Not so far from asm, not so far from a "real" language. Oh, well...
Do you wanna say "Hello World" ?
...when you can contribute to a project like Verified-L4. Where they're applying formal verification to a 2nd generation microkernel. I'd say that pretty much covers the territory from bare-metal up throught theoretical math.
Knowing some assembler is great if you're programming embedded microcontroller applications where every cycle counts (for example, programming PICs). But when it comes to large scale processors it's almost entirely irrelevent, mainly because of their incredible comparative speed and complexity. While it's easy to optimise assembler for a simple PIC, optimising assembler for an Athlon XP would be mind-blowingly complicated, and hence best left to compilers. C translates fairly easily into assembler - most embedded software engineers can visualise how to implement for, while, if etc. constructs in assember. C just saves a lot of time and effort. "Computer Science" is all about layers of abstraction - there really is no need to understand every little detail in order to implement a modern application. Only us nerds take pleasure in knowing-it-all (tm).
biopowered.co.uk - catalytically cracking triglycerides for home automotive use since 2008. Just say no to big oil!
Some days it's seemed to me that there's so much unnecessarily machine-specific code about (i.e. that so many programmers have succumbed to the temptation) that learning assembler should be discouraged. Other days it seems that you're doomed to writing cripplingly inefficient bloatware if all you know is a handholding HLL. Striking the right balance -- knowing the innards, but using that knowledge only for good, not evil -- is tough.
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.
I submit that the latter is the case. In this day and age, "programming" is rapidly giving way to "software engineering". Software engineering is about your development process, which includes requirements gathering, prototyping, technical design, implementation, peer review, and finalization. What you want out of a good programmer is the ability to write standards-compliant code that meets the specified requirements. The good programmer needs to know his libraries and be able to apply the correct algorithm for each particular situation (i.e. use the STL instead of re-inventing the wheel constantly).
I also say that cross-platform software engineering is becoming more important. Assembly is not nearly so cross-platform as practically any high level language you care to mention. Assembly is also not object-oriented.
A good programmer picks up new languages easily, because programming is all about breaking a task down into steps and implementing each step. The process -- the required understanding of logic and math, the ability to translate a requirement into the steps software must execute in order to meet that requirement -- is what the programmer needs. By all means, include assembly language in the curriculum. But educate them top-down, not bottom-up.
Fun with Anagarams! LADS HOST, SHALT DOS. HAS DOLTS. AD SLOTHS, HATS SOLD. ASS HO, LTD.
A real computer science program will teach generic principles of programming and systems development, with projects that delve into a variety of actual implementations of systems.
For example, a b-tree data structure is fundamentally the same thing whether you implement it in 32-bit ARM assembly language or 16-bit x86 assembly language or C or Java.
To understand how assembly language works, you need to understand how a processor works, how instruction decoding works, how register transfer language works, how clocking a processor makes it accomplish things. To understnad how registers hold values electrically and transfer values between registers you need to understand some physics and electronics.
To understand how a compiler takes a source language and translates it into a target language, you need to understand a little about the kinds of languages computers can understand (Context-Free Languages) and how they can parse them (Context-Free Grammars). Delving into that field will lead to the core theory of computer science, what is possible with machines in general and what is impossible.
A real computer science program at a university will take you through all of these subjects over several years, allowing for some excursions into other things like databases and cryptography. A real computer science program is always theory with projects that are applied to actual implementations.
My other first post is car post.
I took a few years of Latin (forced by my school) and I can say that it was one of the most useless classes I ever had to sit through. While it might be interesting to someone studying languages, I am convinced that it is used to make parents feel like their children are getting a better education from their expensive private school. Teach spanish - people actually know what the language sounds like and it is useful.
I pretty much think the same way about assembly. For someone who really wants to understand how a computer works - great. For most of the developers out there who are going to be writing desktop or web applications it is overkill. Learn data structures.
I agree with what the author has to say about assembly. I never felt like I new enough until I learned assembly, even though I started with LOGO in 1st grade, and have had programming every year since. Then I came to understand a lot of how to prevent security holes in higher-level languages, and how to write tighter code. It also helped with better understanding program security from hackers, i.e. how they can hack my programs, product keys (or other such copy protection measures) and find the exploits. Mostly since they disassemble anything they can't decompile...and of course disassembling something puts it into assembly language of one sort or another. It is a class that I didn't get in college, and went back for after I got my degree. The most useful one IMO.
:p
An off the shelf book I liked and found useful was "The Art of Assembly Language" by Randall Hyde. I liked it better then my text books, anyway
That's not a low ID. This (19027) is a low ID.
(I know, there's still lots lower than that. That's what I get for lurking so long before registering.)
-- Alastair
From the website
...
>>To be a programmer without ever learning assembly language is like being a professional race car driver without understanding how your carburetor works.
A race car driver is a high-level user of the car (more akin to a financial analyst using Excel). Why would a high-level user care about HOW the carburetor works? All he has to tell the pit crew is how the car is behaving. A professional race car driver's job is to drive the car faster than the guy or gal next to him. End of story.
Now the mechanic or race car engineer is a different story
I forget...are we at war with Eurasia or East Asia?
Lets see 20 years ago this is what I remember being taught in undergrad CS (Though I'd been an assembly programmer for 7 years already then):
1st Year: Pascal, PDP-11 assembly
2nd Year: 68000 Assembly,
3rd Year: Ada, Eiffel, Modulo-2, Smalltalk, VHDL, EDIF
Interestingly despite using mostly UNIX hardware C was left to be self taught, though it could be used in place of Pascal.
The point really was use appropriate tools for appropriate jobs: Thus we learnt OS/Kernel basics in assembler, likewise IRQ concepts and HAL stuff. For algorithmic stuff we worked in a mainstream strongly typed high level language. For trends yet to propagate to the commerical world (some doomed ones!) we learned in exotic academic languages.
Assembly is as valid today as it was in the 1950's, its just that its most appropriate for only some tasks that a minority of programmers do: Deeply embeded microcontroller SW, OS kernel work (take a look in our beloved linux kernel code), hardware bootstrap, hard real time etc etc etc
Just learn C instead. It combines the readability of assembly with the ease of use of assembly.
For anybody on here thinking about broadening their CS horizons, I would recommend not learning x86, at least not first. A simpler, RISC(-ish) instruction set is really the way to go. It's a lot more enjoyable to program in. Some good choices are maybe z80 or 68k (program your TI calculator maybe?) or Microchip's PICMicro microcontrollers (most models have under 35 instructions to learn).
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.
(Compilers by Aho, Sethi and Ullman) is what thought me how to program. I really think you need to understand how a processor works and how a compiler works if you want to be a good programmer.
Yeah. See...
Are you on crack? Sure, "real" programmers know assembly and lowlevel languages. Isn't it funny how these people are few and far between? This isn't because the other programmers weren't exposed to assembly. It's because assembly is so damned HARD to work with that programmers would simply rather NOT learn it.
The only possible result of forcing students to learn assembly first is lower enrollment. God...trying to become a programmer by starting with assembly is like trying to learn linux by typing "man bash".
------- "From bored to fanboy in 3.8 asian girls" ----------
I've found I get blank stares sometimes when discussing memory usage, I/O bottle neck or code optimization in front of PHB's. All they want is crap to run and if they've got the money they'll throw it at buying more power. Sadly I've seen BSCS people who care less about getting a project done rather than done well, often with hideous looking code which can choke the fastest quad processor servers. A little time spent, considering how code may be written to minimize impact or organize I/O more efficiently isn't even encouraged anymore, where it once was a hard rule.
Look at VB.NET, it's the very embodiment of just code and don't worry about it. So much of the work is buried in libraries/namespace, you really have no idea what impact calling routines will do.
Today's lesson: Screw finesse, just throw more CPU and memory at it.
A feeling of having made the same mistake before: Deja Foobar
I understand C much better than I would have had I not learned assembly language first. I think of C as a somewhat-more-abstract version of assembly. It has that "down to the bare metal" aspect in much of what you can do with it, particularly pointers.
(mythical) 5 points to the first person who can identify both the processor (by make/model) and the machine that the processor resided in for the following snippet of code. Bonus if you can identify WHAT this code does...
ld hl,3c00
ld de,3c01
ld bc,03ff
ld (hl),20
ldir
Ok, so it's been a few (tens) of years since I have had to do this, so I may have the declaration of the memory address wrong. Just for clarification, the values are all in hex.
Ron Gage - Westland, MI
I'd agree with this - in principal.
If you look at some of the nifty and speedy C work - like Duff's device - implicit is the knowledge that you're working on an actual machine. Look at K&R's string copy code - the while (*s++ = *t++) also generates much more efficient assembly code than keeping a separate counter for your position in the string. I know (because I've programmed some 8086 assembly myself and used this instruction) that there's a specific instruction that makes such a piece of code execute in about two instructions!
If you'd programmed that without knowing what architecture you were working on, you probably wouldn't use such a construction because you wouldn't be sure that the compiler could optimise it. The flipside of this is that knowing what architecture you're programming on can, and should, affect your code.
The compiler might have a good idea of what registers it's used, and the chip itself might have branch prediction and clever pipeline filling logic, but you as a programmer (should) have a much better idea of how your code works than either.
However, this shouldn't stop people programming in high-level languages - the rich feature set and the portability more than makes up for the machine-code-ambivalence. And since a lot of OS projects end up executing on different architectures anyway, sacrificing portability for speed is not necessarily a good idea. But, fundamentally, I think knowing what architecture you're running on is highly important to writing good, slick code.
The same applies for file systems and other hardware. Try to write a program that can insert arbitrary quantities of data in the middle of the file without overwriting the surroundings using standard C operations - it just isn't possible. But if you know how the file system works and have the API handles, you can do it (somehow).
join('',map programmer{$_}, @world).
Paul
--Reason is a tool. Try to remember where you left it.--
I laughed my ass off when I read that. I can summarize the Slashdot argument right now. Here's an example of a common reply to any post or story on Slashdot. It doesn't matter what the post or story is about, they all say the same thing really:
Story: Learning Computer Science via Assembly Language.
Slashdot Poster: WMD, Haliburton, tax cuts for the rich, selected not elected, racist, sexist homophobe, jobless recovery.
Story: Remotely Crash OpenBSD
Slashdot Poster: Haliburton, WMD, Haliburton, WMD, Haliburton, Haliburton, Usama, jobless recovery, Haliburton, tax cuts for the rich, sexist, racist, seperation of church and state.
Story: MySQL: Building User Interfaces
Slashdot Poster: Ashcroft is evil, bad patroit act, Haliburton, tax cuts for the rich, WMD, WMD, Haliburton, racist, no blood for oil, Haliburton, sexist, racist, war monger, Usama, WMD, Haliburton, jobless recovery.
Even with today's higher level languages it is still sometimes necessary to know assembly or, at least, how high level code gets compiled into smaller instructions.
The best example of this is the famous "Double-Checked Locking is Broken" situation with Java. If you don't understand how the language is compiled you can run into trouble.
First point: if you're going to teach assembly, RISC assembly is downright elegant compared to the horrid kludge that is x86. x86 is more popular, but if the goal is to get the student into a computer's head, I think RISC is much more straightforward, and there's no shortage of VMs for it.
Second point: There's no faster way to stimulate a person's curiosity about a subject than to let them accomplish something substantial from the get-go. In the same way, there's no faster way to kill curiosity than to keep people from doing anything meaningful until they have a complete grasp of the theory behind it. It is difficult to write even a marginally sophisticated program entirely in assembly, and a lot of people will lose interest long before they've gotten a glimpse of what computers are capable of.
And what is up with the submitter also being the author? Can you say, "shameless self-promotion?"
I'm willing to be convinced that the author might be onto something, but my first impression is that this is a step backward.
You want the truthiness? You can't handle the truthiness!
Back in the day, the CS major course sequence went like Pascal I, Pascal II, IBM 360/370 Assembly, Write your own OS, THEN higher level languages like C, Snobol, Cobol, PL1, ADA, etc.
Yeah, I'm all for this. I think programming has become so abstracted that the abstractions don't correspond with anything but other abstractions anymore. I also think network engineers and administrators should be required to take programming, too, just because it'd be good for them.
Sincerely,
Kickin' it old skool
"Lawyers are for sucks."
- Doug McKenzie
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!
I don't think knowing assembly language is required to become a good programmer, but a good programmer should learn how the computer works at that level at some point in their life. And that's the key. Assembly language isn't a bad way to learn that, but it isn't the only way. And, in many respects, it isn't really the best way, either.
See, I'm sort of tore. I like this idea since I feel most programmers these days are sorely lacking in the fundamentals. However there are advantages to starting higher. One major advantage I can think of is that when you start so low level, there are certain ideas that may never occur to you. Certain ways of solving problems won't come up because you "know" how the computer works and therefore adapt your thinking to it and seeing things very narrowly. I believe that we should be working towards adapting the computer to us instead. And when students start out learning at higher and higher levels, they start thinking higher and higher level and see connections from their "low level" beginnings to a higher level ideal without being bogged down in the little details. I think that would help drive innovation.
Hexy - a strategy game for iPhone/iPod Touch
Assembly language of some sort should be part of any programmer's experience. Granted, you're not going to accomplish anything wonderful -- you'll be doing well just to implement a sort or even multiplication (assuming your CPU doesn't have such instructions -- mine didn't (6502)).
But once you get the grasp of how things "really" operate in the machine, and see the limitations of dealing directly with the CPU, you'll appreciate more (and, with luck, grok) how things work in general, even in very high-level languages: even if you don't know exactly what machine code gets generated by a given statement when compiled, you'll be able to guess a bit better where something may be going wrong (or slow), what takes a computer longer or shorter to do, what conceptual misunderstandings may arise on your part, etc.
Go, assembly language!
"A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
Real men type the 1's and 0's in directly. Who needs a sissy assembler to do the translation? I wouldn't hire a programmer who did not know what "011001001100" meant to today's x86 procs.
Ok, let's get real. This is equivelent to saying that unless a farmer gets on his hands and knees to plant 1 seed at a time, he's not a real farmer. Sure, he knows how to operate a $100,000 tractor that can plant several million seeds each day, but his hands-on knowledge of planting seeds isn't near what his great-grandad's was so, he must be less of a farmer... even though his output is thousands of times greater.
HELLO! It's called technology. It's all about advancement. We no longer have to type in the 1's and 0's ourselves. Hell, very few of us need to use assembly. Why was C written? Because all the fucked-up assembly languages in the world do not work together. A program written in XYZ assembly will only run on a XYZ computer, etc.
Today, programming is high-level. Write once... run everywhere (Java, Python, C#). Let's leave this assembly crap, and it is crap, where it belongs... back in the dark ages!
I really learned a lot about computers by learning assembly language. Of course, I really learned a lot by building a Z80 mainboard, too...learn all you can! The more you learn, the better you'll be.
I think there are bigger problems with most CS curricula than whether or not to teach assembly first. When I was in school, the only thing I learned before learning assembly was Pascal (which is equivalent to nothing). In fact, assembly was really the only language I was taught in school - I taught myself C, C++, perl, etc. It's not clear to me that learning assembly first is necessarily a better path, but I do believe that following to be true: - Any CS'er should know at least SOME assembly - Any CS'er should be familiar with how the machine works (which, sadly, many do not) - Any CS'er should be familiar with the low-level interaction between SW & HW (which, sadly, many do not) I see this as more a fundamental problem of the super-specialization of science majors. I double majored in both CS and EE, so I got the best of both worlds; however with just a CS degree I would have had very little experience with anything related to hardware. Seems to me that these days CS programs are just programmer factories, churning out loads of mediocre programmers who know a lot about Java but little about much else. For the most part, programmers are one-trick ponies, and I suppose that's OK since the need for them will not diminish anytime soon. The sad part about that is until we as an industry begin to aggressively pursue alternative methods for software development, we're going nowhere fast. The traditional, high-cost, time-consuming development processes really are our glass ceiling.
Start out on the bare metal - no operating system, BIOS, or anything else between you and the hardware. We did a little bit of this in some CS classes when I was in school, but not much. I do a lot more of it now as a hobby.
Most of my work is with Motorola HC08 series microcontrollers. There's nothing like being limited to 192 bytes of RAM to make you really stop and think about what you're doing.
Yes, that's BYTES, not kilobytes or megabytes for you PC programmers. And your stack comes out of that same 192 bytes, so you've got to keep that in mind every time you jump to a subroutine. That return address isn't stored by magic!
Now get off my damn lawn.
One name, Donald Knuth, and the original classic, The Art of Programming, Volume 1.
Score:-1, Offtopic.
So you learn Linux x86 Assembly.
Then what ?
Are there jobs in Linux x86 Assembly ? If yes, where ? Out here in the US, or someplace in India ?
Or are you suggesting people learn x86 Assembly for kicks ? That's cool too, but you know, its a bad economy...have you looked at the recent unemployment numbers...people live with rising debt, record number of bankruptcies, the country struggles with 500 billion deficit....not exactly a bright time for polishing my x86 skills...what do you think ?
This is a high ID.
Its like gym class over again, except this time I'm gettin the wedgie.
Damn geek bullies.
I forget...are we at war with Eurasia or East Asia?
But before we get to all that, we need to train people how to use light switches. We've got people wandering around all over who don't know a thing about high-energy particle pysics, and yet they see themselves as fully qualified to use light switches. "Well you just flip it on and off" they say, but HA!!! How little they KNOW!!! ... Can they detirmine the fitness of a test of the speed of transmission? The magnetic flux produced by different types of wiring? The optimum UV conversion of phosphor bulb coatings? Edison was called a "Wizard" because he had to know how to do all those things. Perhaps it's time that learning about light switches gets back to starting with the basics....
i=i+1; generates:
add %g1, 1, %g1
st %g1, [%fp-20]
while i++; generates:
add %g1, 1, %g1
st %g1, [%fp-20]
The latter method might feel better, but there's no difference in the resultant compiled binary. The compiler isn't stupid.
You can't judge a book by the way it wears its hair.
"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."
My first two computer books were the "Green Apple" book, a very detailed accounting of the Apple II, and an Osborne book on CPU and computer functioning.
I learned them in parallel, making sure I understood what was really going on at all levels, from my BASIC programs, down through interpretation, into the machine code, and the actions taken by the machine all the way back out to the output device. Every level took part and needed to be accounted for. The Apple book told what the Apple did and how it did it to some extent. The other book wasn't even about the 6502, so I had to learn to understand what was happening, and how that differeed from how it was being accomplished.
From that I gain a very deep understanding of the similarities under all machines, and ended up with essentially zero learning curve when having to switch between apps, OSs or even fellow geeks (when they tended twoards a certain focal technology).
A person who knows how it works is far better equipment to handle any eventuality than a person who just knows how to make it go.
"I may be synthetic, but I'm not stupid." -- Bishop 341-B
...or any modern high-powered CPU, it's just too complicated to write good, clear, effective code. That's why we have compilers.
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.
Assembly is an impediment to understanding high-level issues. While I agree 100% that any good CS program should include some discussion of assembly and systems programming (at least a few semesters), there is so much more to CS than systems hacking. There is no way that a whole modern CS curriculum should be taught in assembly language.
As a starting language it's really a matter of preference: the bottom-up method gets you really understanding the machine (and really yearning for more convenient tools), but it is a slow, painful start. The things you learn are less general and will be less applicable years down the line. On the other hand, learning a high level language can leave you in the dark about what's going on under the hood, which means that some aspects of what you're doing will seem like "magic". For you efficiency addicts, this can mean less efficient code. On the other hand, the world will have fewer efficiency addicts!
However, I think that assembly will turn a lot of people off of programming that could otherwise be interested in the subject and perhaps productive programmers, if not cowboy kernel hackers.
You are an idiot
You should drink a bullet
Don't you have something better to do? I bet your boyfriend would appreciate a blowjob.
I hear there is updates available for Safari and Java, have you gotten them yet?
Have you called your mom lately? She probably would like to hear from you.
Universities are not supposed to be trade schools- they should focus on teaching their students the basic concepts, not technologies-du-jour. The purpose of teaching assembly is not to produce programmers who know x86 assembler, it's to teach the students the basics of how modern computers work.
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.
Tsunami -- You can't bring a good wave down!
http://www.eskimo.com/~johnnyb/ProgrammingGroundUp .pdf
A driving school that teaches students to move the car by manually injecting fuel into the engine and shifting gears by pulling on things under the open hood.
Admitedly, one can not seriously use C++ without knowning assembler for debugging purposes. A corrupted virtual table pointer, for example, produces behaviour that can hardly be explained by language semantics.
Also, "production use" VM languages like Java or C# do not break down in the same way, but even the shortest possible program requires way too many things that will distract beginners - like a class, method calls like System.out.prinln, or even requirenment to declare the main function.
But these are not the only choices. BASIC is still pretty good. "input a,b,c : ? (-b+sqrt(b*b-4*a*c))/(2*a)" gives an introduction to sequential execution of program steps without too much unneccesary red tape. Algebraic notation could be better though. AWK, Python or Javascript would all be candidates for the first language that shows people how to use if statements and loops.
Then, once students know how to parallel-park an automatic car, they can go and learn stick shift and hand-tuning the engine if whatever they are trying to do requires such efficient driving. Or if they have to drive a car that keeps crashing because of slight driver errors and requires extensive poking under the hood to discover what went wrong.
Although I think this may be an interesting book, I think many people confuse computer science and programming.
"Computer science is as much about computers as astronomy is about telescopes" --Edsgar Dijkstra
funny, my school has MIPS assembly and MIT scheme in the intro level courses. I don't see any other way of doing it.
The war with islam is a war on the beast
The war on terror is a war for peace
Or, perhaps not.
Computer science and programming aren't the same thing. Computer science is knowledge. Programming is a skill. They reinforce each other, but it is a mistake to confuse them as being the same thing.
Higher level languages hide irrelevant details from us. They are a good thing: they allow us to concentrate on the task that we are trying to achieve. What parts of a machine are irrelevant? Most of them.
Don't believe me? Consider how many lines of code are in the Linux kernel, and compare the differences between say a PPC port of Linux and the X86 differences. Not very many differences compared to the raw number of lines, is it? That's because most of the machine differences are irrelevant.
Sure, you could clutter your mind with instruction timings, rules for cache invalidation or pipeline stalls. But it's almost certainly a waste of time, and it will get you no closer to understanding Computer Science.
There is much pleasure to be gained in useless knowledge.
With the comming advent of 64 bit processors the potential size of the instruction set will be able to vastly excede any reasonable limit. the hardware could implement RAM as a database w/ SQL to get info and have C or C++ or java VM or python interpreter or even all four implemented in silicon. I realize you'ld want the base instruction set to be pretty damn mature but imagine the advantages of writing a fourth gen language that was machine code.
Yes, please throw all those who know nothing about programming directly into assembly language programming! That way less people will be interested in programming, thus less Comp Sci graduates, thus solving the problem with exporting programming jobs!
I'm glad SOME of us are thinking ahead. I for one welcome this initiative for keeping our jobs.
What I like best about computers is that they are super miniature machines. And unlike mechanical machines, they can do the same thing over and over again - not millions - but 10^20 or so times over and over. And they do this really really fast.
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.
Well, if you've ever written some trivial program in a high level language (Fortran or Cobol or whatever) and then disassembled it, you know the value of Assembler. There's nothing quite so convincing as seeing your program broken down into Assembler to appreciate how much garbage is included by a high level language compiler/linker and get one to thinking how one could extensively clean it up using assembly code. Ah, the good old days, when program size and speed were at a premium .
Learning about how a computer actually does what it does is referred to "computer organization" and any University that offers a computer degree without a course or two in organization is (IMHO) severely lacking.
by Randy Hyde at Univ California - Riverside. To learn about assembly on 80x86 processors, check out the printed book, or download the text with a Linux or Windows point-of-view. It's written in a style that's not overwhelming to the novice.
I had been programming for years in assembler under various platforms from minicomputers to microcontrollers: PDP8, PDP11, Motorola, Zilog, NEC, Intel's microtroller family 8051s, and then I tried the processor family from hell: x86 family.
It felt like I knew nothing cause the whole x86 platform on the PC is interrupt driven as opposed to memory mapped. Any time you wanted to do anything, you talked to a software interrupt. And then your memory is segmented into four segments: data, code, stack and misc. You can only talk in small chunks of memory (soemthing like 64KB because of backwards compatibility to the old 8 bit processors IIRC) and are forever swapping out. Not to mention the 640KB limit. Aaagh!
The x86 family is based on the 8085 family which was based on the 8080 family and so on. The built on the core of the previous processor which sounds like a good idea but in fact, it added the previous generations limits into the design. It's a perfect example of how not to design a processor.
Program in assembler on a Zilog or Motorola processor and you can see engineering brilliance at work. Things were well thought out and done with a purpose and not because a deadline had to be met. I'm sure that most of the Zilog and Motorola design engineers had hands on experience with Intel first and new what not to do.
I can't say little enough about the x86 platform on a PC. I pity anyone who has to program assembler on it.
As a graduate compsci student being also a teaching assistant for classes on programming language, I think that's a really bad idea.
People need to abstract from the computer hardware to develop means of reasonning, creating abstractions, solving interesting problems and writing understandable programs.
Introducing someone to computers by learning him assembly won't help their development at all. Low level development is tedious, it is not something that should be used to teach people how to reason about programming.
Also, how many people writes assembly in their day job? The only assembly I produce comes out of my compiler's code generator. I'm not stupid enough to go write it myself.
Definitively, assembly has its use, but it is not for teaching basics of programming. Using it with that goal in head is a very bad case of premature optimization.
A message from the system administrator: 'I've upped my priority. Now up yours.'
I've written object oriented assembly code before. Very possible, and not particularly difficult. There's a little bit of setup work involved, you just can't jump in: but that's true in all pure OO systems: hello world's are larger in OO systems than in structural languages.
Assembly language OO is certainly easier than structured language OO. Take a look at GNOME for an example of the latter.
In a similar vein to the FP, writing OO assembly makes you a much better coder. For instance, before I wrote the project, I didn't have a good idea of the difference between a class and an object. I definitely do now!
The only thing OO assembly doesn't give you is protection, and that's no loss. Python doesn't have a "true" protection scheme either for it's objects, and it's a better language for it.
Bryan
I've found that the key difference between mediocre and excellent programmers is whether or not they know assembly language.
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.
WTF? Assembly language for an architecture is
the same regardless of the OS.
The Parent post is mis-informed.
Back in the early 1980s, you had a text prompt and that was about it. Maybe a mouse. Learning Computer Science via ASM was possible because there was a small subset of function the computer would accomplish. Today, I think its drastically different. There are a billion things one piece of software does, especially software with a GUI, API calls, etc. I would think that its so convoluted it would be hard to pick out one consistent stream of thought from inside the software.
The Doormat
If you're not outraged, then you're not paying attention.
Most programmers who know assembly don't use it much.
Why would you make a claim like this without checking it?
Let's leave this assembly crap, and it is crap
What exactly do you think your C compiler is written in? How about very good portions of the Linux kernel?
You don't need low level programming languages for every application, or even MANY applications, but understanding machine code is the difference between a trained monkey and a Computer Scientist.
Your farming analogy blows, by the way. A more apt analogy would be Farmer Brown doesn't know shit about botany or genetics, he just buys the seeds Monsanto tells him to and plants them the way his "paw" taught him. Farmer Jones however understands botany and plant physiology as well as a bit of meterology. He understands how plants work, what fertilizers to use and in which conditions to use them, and when to change his planting times/methods. Farmer Brown will have a harder time adapting to conditions outside his skill-set. Farmer Jones is less likely to run across conditions he can't handle.
Besides, understanding how the machine interacts with the software goes well beyond writing assembly code.
This message brought to you by the Council of People Who Are Sick of Seeing More People.
I thought that's how all computer science and engineering learning starts out?! With the fundamentals of the computer itself and how it is controlled? Is that not true any more? I learned the fundamentals primarily by programming the 6502 on an EMMA training board (anyone remember those?) using a hex keypad and an 8 digit LED display.
re-invent wheels
From a research point of view it's far more interesting to look at new (or emerging) programming paradigms like Functional Programming, or mathematical models.
Anyway, if you really want to go low level, go learn how a turing machine works :)
Bob
You think that cpu's are really doing exactly what you tell them to do when you program them in asm? What about hyperthreading and pipelines and pre-fetching and all the other insane stuff modern CPUs do? I hate to break it too you but even ASM is now a higher level language.
. html
http://arstechnica.com/paedia/c/cpu/part-2/cpu2-1
There's more there then just that one article, this one just seemed like a good place to start people at.
From the book's presentation page:
To be a programmer without ever learning assembly language is like being a professional race car driver without understanding how your carburetor (sic) works.
To which I reply: To be a book writer without ever learning how to spell properly is like trying to teach programming by starting with assembly languages.
A message from the system administrator: 'I've upped my priority. Now up yours.'
In my (granted not extensive) teaching experience the assembly programmers are the worst of the bunch when it comes to doing CS. Followed closely by the basic programmers. Then followed by the other "Prior Programming Experience" folks. Prior programming experience seems to make people think that CS is about programming, and not about math - which of course means they don't do so well. Of course maybe the blurb is incorrect and the book isn't about CS, but is about programming, which the title of the book indicates. But since the blurb author is the book author the point still seems valid. So is it about programming, or about CS?
"Old-timers" are often viewed as "wizards" because they have knowledge and experience, that they know assembler doesn't seem so important - they probably will know at least one flavour of assembler because of their experience of course.
So have you got some numbers to back up the "I've found that the key difference between mediocre and excellent programmers is whether or not they know assembly language" statement? Or is it anecdotal (which of course doesn't mean it isn't true)? Experience needs to be considered - if the assembler programmers have more years of experience then you would expect them to better programmers (that's what I would expect to explain the observation, since assembler use has declined over time, so people with experience in it probably started earlier...).
Of course a book which teaches programming and not a specific language is a good thing, provided it is well written, edited, and tech reviewed.
I think whether this idea is a good one or not depends on what the program considers a Computer Science Degree. Where I have taken classes, the philosophy of Computer Science is more the science of algorithms and mathematics rather than practical programming experience. The idea being the research of new and more efficient algorithms or data structures not tied to a specific language . This is more suited towards graduate work in the field of Mathematics and Computer Science.
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.
-- Wolfpup
"A man whose circumstances went beyond his control." -- Styx
Assembler is good to know how to program in.
When I started programming as a job I was trained as a IBM s370 mainframe assembler programmer. I did it for a little over 2 years before I was asked to apply for a COBOL job at another company by my old team leader.
Being quite young at the time I just did what was asked and went along to the interview. They asked me how well I knew COBOL and I said I didn't. My old team leader said "He's an assembler programer, he will pick up COBOL is a couple weeks". And I ended up getting the job.
When I started the job I didn't even get any COBOL training, but I IBM CDROM on COBOL and access to the bunch of programs I had to work on. Given a few weeks I didn't have any problems.
A few years later I was getting sick of the mainframe and wanted to get into client server or PC related stuff. So my team leader gives me the job of re-developing the IVR (Interactive Voice Responce) system that was used for our banks Telephone banking system. Again I was given a couple manuals, access to the system and told I have 2-3 months to redevelop the system to intergrate into the new backend. And I did it.
Soon I got sick of working in a corporate environment. So I threw in my job and started doing web work. I've programmed in Miva Script, PHP, Python, Perl and javascript on various projects. I've never had a lesson in any of the languages. I just searched the web for a manual and started coding or hacking away at code I could find that did simular stuff.
My point is that I honestly believe without my assembler traning and experince I doubt I could be as felexable a programmer today as I am.
Write just enough of it to accomplish what you are doing.
Call this code from a higher level language.
More and more, assembly is not needed except for embedded systems, and I've even used C sprinkled with inline asm for embedded code.
I've always felt this whole "assembly language makes you a tough guy" argument to be an elitist one. For the record I did study assembly in computer science. Did it make me a better programmer? Maybe, but then learning regular expressions probbably would also have made me a better programmer too (had to learn that on my own). What I have a problem with is this attitude that if you _don't_ know an assembly language, then you're just a mediocre programmer, or somehow a lesser mortal than someone who does.
There's some specific instances where knowing how assembly works might give you some insight into strange esoterics like instruction re-ordering problems in certain multi-threaded atomic operations in Java. (That was a discussion one year at Java-One). But then what area of knowledge in programming doesn't have some specific instances where that special knowledge is extremely pertinent?
I'm glad I know a bit of assembly, how processors work, instruction re-ordering, pipelining, etc. It's all damn cool stuff. But then there's all this other stuff I have little clue about, like bayesian filtering, fuzzy checksums, etc that would be helpfull to know as well. Are the guys who know a lot of assembly better than guys who know cool algorithms? I think they're just different skillsets, and people need to get over their zealotry for a particular skillset.
AccountKiller
It is not assembly language. It is the way we think - and in the world of computers there are 5 types of languages that will make you take on anything very easy.
1. Procedural (Pascal/C/BASIC)
2. Object-Oriented (Eiffel/Smalltalk/Java/C++)
3. Functional (Scheme/Lisp/Logo)
4. Declarative (Prolog/Forth)
5. Assembly (x86 etc.)
I dont think this is a novel concept. When I started my comp sci degree, an assembly lang class was one of the first 3 classes.
100% Insightful
Real men go to the beach and grab a bucket of sand which they refine into silicon.
BY FAR THE BEST CS COURSE I EVER TOOK!
b i/ 360.html
http://www.cis.ohio-state.edu/courses/cis_sylla
We used "ISAM" which emulates sparc assembly while it is a little closer to a sandbox than "real" assembly...
On a more humorous note, there is a "Get it to your Valentine on time!" button on the book's page.
Now, that a sure-fire way for me to get laid... (not!)
A message from the system administrator: 'I've upped my priority. Now up yours.'
... the practice will never be widely adopted because it's a reversal of the trend. How many kids today are learning arithmetic without a calculator.
Research shows that 67% of those who use the term "research shows", are just making shit up.
Last time I checked an architect doesn't 'architect', she 'designs', therefore the past tense is 'designed' not that godawful non-word 'architected' that has sprung up here on /. several times recently.
Tony Williams
knowing assembly language to be a good programmer is like knowing the molecular composition of egg whites to make good cake. It's a waste of time and not needed
Obviously the submitter has never attempted to teach introductory computer science with an eye towards theory. Teaching most languages has the effect of reaffirming in many students' minds that Computer Science is all about misplaced semicolons and curly brackets; it reinforces a cut-and-paste view of computer science. This is exactly what you don't want!
But if we want to talk about returning to roots, why don't we teach computer science with the lambda calculus? Actually some schools do use an extended lambda calculus, Scheme. This is actually what teaching Computer Science is all about: abstraction with an eye towards a study of the computable. Not to say that graduates shouldn't also be rigorously trained in how to program, but the best starting point for a computer science degree is in computer science, not programming.
I'm a software engineer and I work for a major CPU manufacturer. As you might guess, my job involves a ton of assembly progamming.
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.
Okay, now this is the first thread that's made me feel old, and I STARTED college just last decade. C'mon, let me get out of my twenties before you act like my education was dead and now you're revitalizing it.
To wit: based on a new concept - teaching computer science through assembly language [...] This is why the old-timers are often viewed as 'wizards': they had to know assembly language programming.
I object to the use of "old-timers", first and foremost, and I secondly object to the thought that your book is a "new concept".
Assembler may not have been the first thing I learned in my undergraduate CS curriculum, but it was darn near the first thing.
All that said, understanding Assembler is a huge asset to learning general Computer Science. If you want to know how any other language works, you need a grounding in Assembler concepts. Still, this is nothing revolutionary, and CowboyNeal should be flogged for posting such a story without at least a review from someone other than the author.
.. on different machines and different sets. I started out back in the days when you had to use assembly to gain speed, and slowly changed it for c/c++ as time went by. I've been programming for years back, making mostly graphical application.
Guess what? I'm a bricklayer.
Albert
Computer Science involves a lot more than just programming. Thus, I would have to say that I agree that I've never learned subjects such as computer architecture and algorithm design and analysis through a course regarding a programming language. Courses on programming languages are just that, courses on programming languages. They are not, by themselves anyway, the definition of Computer Science.
Why not learn using an assembly language that was intended for teaching like MMIX? I know there's always ``the Art of Computer Programming'', but it would be nice to have a shorter simpler book for beginners. The problem with teaching 80x86 is that it's already hard enough to get people to move on as it is.
I think you're confusing "Computer Science" with "Programming".
Every program I've heard of has an ASM course to lead into computer architecture classes. I think it's wise, but I do not think it's wise to have ASM as a 1st course in a Programming series.
I first learned BASIC. Then I learned assembler. Now what's that you say about me being NERRRRRRRR?!?!
Assembly language programming has done wonders for teaching me algorithmic efficiency. Before I started writing code in assembly, I would always use random-pivot quicksort (with insertion sort on small base cases) to sort large data sets, but once I started using assembly I realized that bubblesort is much simpler and more elegant. I've been using bubblesort ever since. I can't say that programming in assembly has done anything for my knowledge of computer architecture, but it's definitely helped me write more efficient code.
WARNING: there is a trojan on your
OK, I think this whole thing is a great idea. Tired of seeing graduates with no clue.
:)
:)
at 11 I was writing small machine code routines for the spectrum by manually translating the op-codes into decimal and entering them in data statements
at 13 I wrote a forth style compiler in assembler (using machine lightning) for the speccy. the listing from the zx printer was around 20 feet
at 15 i was writing assembler for my atari st, patching the operating system to provide a number of missing functions.
after that i started programming GEM. that was too much of a pain in the ass in assembler so I turned to C - after that it was a long and slippery slope to PHP
knowing assembler give you a massive insight. comparing your favorite compiler code generation to what you can write helps you to help the compiler
Ewh! Yuckky. Teach them a *REAL* assembly language like MIPS or ARM.
x86 is just an abortion that got to full term.
But if you want to be able to teach assembly with fewer architecture-dependent quirks, try something with a cleaner instruction set, like MC68k or PowerPC. Orthogonal, linear address space, elegant indexing, etc.
But the theory of the article is right. Too many programmers are coming out of schools with little or no understanding of the hardware. They have too much tunnel vision in their narrow field of expertise. And I agree with Assembly first, other languages afterward. This is much like teaching Calculus. Teach them the hard way first, then the shortcuts.
New, huh? When I took Intro Comp Sci back in 1972 we had half a semester of IBM 1130 assembly followed by half a semester of FORTRAN. IMHO, '86 assy is a rotten machine to learn (or program) on. The real classic, of course, was the DEC 10; but if I were teaching an intro course right now I might be tempted to use a PIC. Speaking of which, is there a decent DEC 10/20 emulator out there? That might make a useful pedagogical tool...
>I've found that the key difference between mediocre and excellent programmers is whether or not they know assembly language
Which is the reason all the best software is written in assembly.
In my experience, the key difference between mediocre and excellent assembly programmers is whether or not they know assembly language.
If this is for truely CS students, I'd have to agree. I wish the corses at my local collage would have done this, and been structured to really teach me programming as a whole, with a set thread of corses, rather than piecemeal. I personally had to teach myself project management, code orginization, and design techniques. The results have been varied, but a deffinate improvement from the folks that I know that kept going to that same school for CS. A sad thing indeed.
;)
On the other hand, there is the serious consideration that there are perfectly valid computer career choices that don't need low level languages at all. Can you say Sci majors that need computer programming to be able to do calculations more than anything? I can think of a few more, but I don't think all of them are that valid of career choices
I wholeheartedly agree. Introductury computer science courses should teach students about computers rather than focusing on how to code. Assembly language is a great way to do this. Just like you wouldn't want to teach kids how to add using a calculator, people shouldn't learn how to program a computer using a high level language.
When I took my first programming course for EE computer folks at UC Davis our first course was in PDP-11 assembly language. It was a great way to learn both an environment and the up-close details of how to make a machine work.
The PDP-11 has a great orthogonal instruction set which let the student explore a wealth of different addressing modes.
It was a great WELL ENGINEERED place to learn to write programs since it was engineered and didn't grow up loaded with garbage the way the 86 has. The macro assembler was excellent and RT-11 gave a great little runtime environment.
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 :)
Perhaps it's time that computer science curriculums start teaching assembly language first.
Maybe it would be better if some of the curricula started teaching basic English instead...
It's official. Most of you are morons.
Really need both. Can't really say which is the better order as long as eventually both are learned. The primary thing I've walked away learning is that no matter what you call it, all program seems to be about is just about shuffling data around in sometimes very creative ways.
/ ap pa.html
The difference between learning the algos vs the machine is that divide between the theory and the practical. Remember Tanenbaum and his infamous "Linux is obsolete" quote?
http://www.oreilly.com/catalog/opensources/book
It really depends on what you want to put out. It seems like programming as a field is changing as well, with so many layers of APIs, wrappers, systems, it's becoming almost a danger to do anything but the plodded path...
Currently I write several processor dialects in assembly (8, 16, 32bit systems)... ;o) ;o] but even sun seems to be in danger of following the M$ business model of infinite version release).
Wholly cripes! I sometimes can still speak English too...
It is much more restrictive a language on any system, when doing data abstraction I must confess I would rather see a nice graphical GUI, IDE, and good hardware documentation (ha ha lol). In terms of quick & maintainable Application development assembly was never a "good choice". Some parts of the language may lack in flexibility because of architecture restrictions. The restrictions are bad for applications (unless you write BIOS firmware). However, the language that is spoken in decompiler terms is unmatched when it comes to analysing security problems, stability issues, and forensic data.
Perhaps the allusion to Linux OS (btw: multi-Platform OS means asm instructions unlike C based languages sometimes look completely different on other processors) refers to a black-screen-of-death or perhaps a core-dump post crash analysis. Ah yes, I keep forgetting that the legacy i386 based instruction core seems to beget further development of legacy i386 based instruction cores with "new" features and even "Newer" legacy technology.
Unfortunately, It is a full-time job keeping up & on the "In" with hardware designers who hardly ever show empathy for application designers (embedded Java VMs were supposedly going to stop this trend
The assembly language seems like more academic trivia, but it is far more useful in teaching good data abstraction technique then any of the high-level languages. Some compilers are now using low-level optimizations and compression that get very close to the same code space and efficiency (not O theory though, its all the same in terms of algorithm design... Crap code is Crap code....) Oh yeah, what ever happened to good data abstraction into a good algorithm design? The answer, what has advanced calculus got to do with computer science... =o)
Perhaps it's time that computer science curriculums start teaching assembly language first.
Having taught an assembly/into computer arch class, I agree with the sentiment that students who get "under the hood" gain valuable knowledge and working skills. Not just pounding ASM, but in learning how the machine works. Point agreed.
Also having taught first year computer science students, and seen how some of academia's transitions in pedagogy affected students... I have to say that the idea of teaching first year students in assembly is friggin' daft.
My reasoning is the same as why I strongly advocated an objects-first teaching model. It is increasingly critical for students to build a strong sense of software design and abstraction early on. This foundation makes students much better prepared to solve problems of many different scales (asm to component-systems) in the long run.
There's evidence from a paper in one of the Empirical Studies of Programmers workshops that this approach does trade off design skills for purely algorithmic reasoning for students at the end of their first year. But my own experience, as well as that of some prominent Comp Sci Education (CSE) folks seems to indicate that this is far more than compensated for as a student's skills grow.
Here's my theory as to why this is the case:
The details of debugging, alogrithmic thinking, and problem solving are very much skill building exercises that really require time of exposure to improve. But it is much more difficult in my experience for students to build good design sense on their own. Once the framework for thinking in terms of good abstractions is laid down, it provides much stronger support for later filling all of those gory low-level details.
Historical perspective: Ironically, this same reasoning is much of why I believe that academia's switch to C++ from languages like Pascal, Modula-2, etc. was an educational disaster for many years. The astute reader is now thinking: "hey, you just said you like objects-first; what up?" In the Procedural Era, many schools wouldn't expose students to C in the first year, as it had too many pitfalls that distracted from learning the basics of algorithmic thinking and important abstraction skills. Once the foundation was put in place, it was okay to swtich 'em to C for the rest of the program.
When C++ and the early object boom really hit, this put on big pressure to teach first year students using C++. At one point in the mid-90's, upwards of 75% of 4-year institutions were teaching their first year in C++. Thus a language that had plenty more pitfalls than C, previously shunned for its pedagogical failings, entered the classroom. Combined with a lack of of proper OO mental retooling on the part of first year instructors and faculty made for something of a skills disaster on a broad scale. At best, students learned "Modula-C" instead of good OO style. At worst, they were so confused by this melange of one-instance classes and sloppy hybrid typing that they didn't get a cohesive foundation whatsoever.
You have to make the difference between schools like ITT, DEVRY and real Comp Sci schools that teach the real stuff such as system programming and other stuff. But again, you cant force anyone to go to the bottom. Comp Sci has been created to allow people to move to a higher level of abstraction. But you need people at every level. From people that have no clue of what a stack is to people that understand how the flip flops in his ram act to store his porn videos. It's all about placing the people at the right place. Computers spawn EE->CE->CS . If you want someone good with ASM, you re more likely choosing a CE person. Someone in CS will be more interested in Algorithms and other stuff that rely on the language API which is a trusted component (u assume people who write languages know their stuff). And also, ASM is fun, but its also chip specific. So what is important is the concept more than the application to the computer: stack, registers, memory addressing etc than the specifics of an X86.
Donald Knuth did this 30 years ago in "The Art of Computer Programming", by providing sample implementations of the algorithms in MIX, his assembly language. There is something to be said for this: he justifies its use in the preface to Volume 1.
Certainly having to learn assembly language gives you a better understanding of the machine: I learned alot peeking and poking (no pun intended) around with the catridge-based monitor on my VIC-20 in 1981, which put me in good stead for when my Apple ][ arrived: remember when the assembler listing for the ROM was included in the box? Those were the days. Of course back then you didn't have much software to use, so you had to write your own. Now you don't have to.
I'm an advocate of starting CS students with a very high-level language, like Scheme. That allows them to learn to _program_ instead of wasting time learning a _language_. Once you know how to program, languages can be picked up relatively easily. As long as the students are exposed to lower-level languages later, things are good. People coming out of good schools knowing Java and Scheme only are in for a rude awakening when they hit the real world.
What's the problem with getting people interested in CS turned off by assembly language? Those individuals are most likely the students taking the major because back in the 90's they heard there was "big money in computers." They're 50% of the people bitching about not having jobs because they never cared enough about computers and how they work to get the best understanding of them.
Now I expect to hear complaints from people saying "I don't have a job, and I know [x], [y], AND [z]." I'm not talking about you.
At my school I watched the students who had no interest in computer or electronics drop like flies as we took basic classes in logic gates, digital circuitry analysis, etc. I was happy to see these students leave because they were not only wasting their time, but my time any money as well by asking their foolish questions. These were the students who complained, "But why do we need to know this? We won't use this in industry."
Perhaps you won't use much Assembly in industry, but as stated above, it sure as hell will make you a better programmer and a worth-while employee.
*steps of soapbox.*
my two cents.
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...
One of these days I'm moving to Theory - everything works there
I spent a year in the late 80's on a three person team writing a paint package entirely in assembly for Truevision.
It all ran on the TI graphics chip on the frame buffer. The result was fast, tiny, and surprisingly versatile,
fast or faster than Gimp does today on your average Linux box, which is surprising considering the CPU speeds at the time.
I think that every CS student needs at least a couple semesters of asm before they can call themselves
a computer scientist. There's no better training to teach you how to avoid bloatware and feature creep and
how to approach things with simplicity in mind.
There was a time when obscure objects (C++) was cool. That led to bloated designs, spending too much time on reusable code that wasnt really reused, memory leaks and of course highly unoptimised binaries.
Programming with abstract objects is no fun. Its like youre sitting on a machine and have NO clue what its gonna do with your typing. Youll be a slave to the IDE and the language. Good code comes from the pride of developers that are pefectionists, a lot like the BSD developers. They didnt develop much over a long period of time, but spent time making it perfect from the ground (hardware) up.
I enjoy developing for embedded chips for the same reason. Youre given hardware whose specs you know exactly and its functions are 100% predictable.
Giving students that same taste of robust predictibility (like flooding address A0000 in DOS DEBUG) will interest them in designing everything from the ground up all perfect and efficient. That kind of software development just happens to be far more interesting than the boring Java classes and professors.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
a 255-byte range from address $00-$FF
Um, that's 256 bytes. Hey, on the 6502 and zero page memory, every byte counts!
-rickhow about I correct you if you're anal?
Suggesting that all good programmers (should) know assembly language is spurious. Most old programmers know assembly; many good programmers are old; consequently many good programmers happen to know assembly language.
Does anybody actually program in assembly language these days? I thought compilers had been beating hand-coded assembly for years. Certainly my old CS prof gave up competing against optimised compiler code 15 years ago.
If you dont understand how things work at the register level, then you dont have any clue what you are really doing..
Learning at that level, using assembler or even microcode is what it takes.
Its a shame that has been lost on todays generation.
Any ignorant boob can drag and drop components.
---- Booth was a patriot ----
At work about twenty years ago (I was a EE for a power utility), I taught myself basic 360 assembly by writing a Forth interpreter (I had to have a goal before I could learn anything). Six months later, a local business oriented community college got my name during its search for someone to teach an evening class in 360 assembly to some Cobol programmers at a bank. This conversation followed:
Q. When does the class start?
A. Tuesday. (it was Thursday).
Q. What textbook are you using?
A. What textbook would you like to use?
Always ready to accept what I didn't have sense enough to avoid, I took the job. I selected a textbook from the local university, wrote a syllabus and grading plan and I was as ready as I was going to get in five days. I figured that anyone willing to work with JCL would have no problem with assembly, but just in case, I had a plan for motivating people to cherish assembly language programming.
During the first half of our three hour class I taught machine code, and hinted as we went to break that by the end of the semester we would know 160 op codes. After that, assembly was a god-send.
I think Motorola 680x is one of the most elegant assembly languages ever. Does the word "orthogonality" mean *anything* anymore?
"We don't need no stinkin' mmx"
I'm surprised you could reach your keyboard from way up there on your high horse.
Thank your for enlightening me Mr. Pointer Expert. You truly articulated your point with one anecdotal cliche after another.
-Mr. Naive Idiot
https://www.accountkiller.com/removal-requested
There are many, many such 'emulators'. They are called debuggers.
I and others disagree. Here's two:
...
Consider Paul Graham: Beating the Averages. Considering that he's the kind of guy that gets invited to MIT as a language wizard (along with Guy Steele, David Detlefs, Martin Rinard, Jonathan Rees, and David Moon), and considering that he has a net worth in the (hundreds of) millions, I'll go with his choice: abstraction rules.
Consider Erann Gat from JPL (the guys who get to send robots to Mars and build autonomously controlled space probes) disagrees and empirically proves it.
Diamond Walker emphatically endorses LISP - his story is very compelling.
The list goes on and on: Dan Friedman, Mitchell Wand, Shriram Krishnamurthi, Christian Quiennec
But, to paraphrase Graham, if you don't know these people I guess I don't have to worry about you.
People who know assembly produce better code by almost any measurement except "object-oriented-ness", which assembly makes difficult to an extreme.
Actually, they don't.
A study was done, some decades ago, on the issue of whether compilers were approaching the abilities of a good assembly programmer. The results were surprising:
While a good assembly programmer could usually beat the compiler if he really hunkered down and applied himself to the particular piece of code, on the average his code would be worse - because he didn't maintain that focus on every line of every program.
The programmer might know all the tricks. But the compiler knew MOST of the tricks, and applied them EVERYWHERE, ALL THE TIME.
Potentially the programmer could still beat the compiler in reasonable time by focusing on the code that gets most of the execution. But the second part of Knuth's Law applies: "95% of the processor time is spent in 5% of the code - and it's NOT the 5% you THOUGHT it was." You have to do extra tuning passes AFTER the code is working to find and improve the REAL critical 5%. This typically was unnecessary in applications (though it would sometimes get done in OSes and some servers).
This discovery lead directly to two things:
1) Because a programmer can get so much more done and working right with a given time and effort using a compiler than using an assembler, and the compiler was emitting better assembly on the average, assember was abandoned for anything where it wasn't really necessary. That typically means:
- A little bit in the kernel where it can't be avoided (typically bootup, the very start of the interrupt handling, and maybe context switching). (Unix System 6 kernel was 10k lines, of which 1.5k was assembler - and the assembly fraction got squeezed down from then on.)
- A little bit in the libraries (typically the very start of a program and the system call subroutines)
- Maybe a few tiny bits embedded in compiler code, to optimize the core of something slow.
2) The replacement of microcoded CISC processors (i.e. PDP11, VAX, 68K) with RISC processors (i.e. SPARC, MIPS). (x86 was CISC but hung in there due to initera and cheapness.)
Who cares if it takes three instructions instead of one to do some complex function, or if execution near jumps isn't straightforward? The compiler will crank out the three instructions and keep track of the funny execution sequence. Meanwhile you can shrink the processor and run the instructions at the microcode engine's speed - which can be increased further by reducing the nubmer of gates and length of wiring, and end up with a smaller chip (which means higher yeilds, which means making use of the next, faster, FAB technology sooner.)
CISC pushed RISK out of general purpose processors again once the die sizes got big: You can use those extra gates for pipelining, branch prediction, and other stuff that lets you gain back more by parallelism than you lost by expanding the execution units. But it's still alive and well in embedded cores (where you need SOME crunch but want to use most of the silicon for other stuff) and in systems that don't need the absolute cutting-edge of speed or DO need a very low power-per-computation figure.
The compiler advantage over an assembly programmer is extreme both with RISC and with a poorly-designed CISC instruction set (like the early x86es). Well-designed CISC instruction sets (like PDP11, VAX, and 68k) are tuned to simplify the compilers' work - which makes them understandable enough that the tricks are fewer and good code is easier for a human to write. This puts an assembly programmer back in the running. But on the average the compiler still wins.
(But understanding how assembly instruction sets work, and how compilers work, are both useful for writing better code at the compiler level. Less so now that optimizers are really good - but the understanding is still helpful.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I'd want to see a TOC and some excerpts before I plunk down $35 for the book. It's not on amazon and the author's site gives no information like that. But, you CAN get a larger image of the front cover. Maybe that will get me to buy it over another book.
this nation, under God, shall have a new birth of freedom. -- Lincoln, Gettysburg Address
Hardly.
:)
When I studied IT in the 90's (that'd be 1990's, I'm not *that* old) one of my subjects was Computer Architecture, studying different computer systems, processor architectures (CISC/RISC, ring stacks, etc) and support hardware down to the register and inter-connects level and beyond.
All of the practical work in this course was done in assembly language to ensure that we grasped the guts of the particular item. While it was mostly x86 and under messy-DOS (one of our assignments was to write an INT33 mouse driver) we got to play on other stuff too like Zilogs and Motorola 68x's in various boxes.
This was one of my favourite courses since I'd been assembly programming long before I went to Uni and wasn't panicking like some of my classmates.
I think everyone in IT should have done something like this (it seems a lot the up-and-comings think "assembly" has something to do with IKEA) as it gives you a really good understanding of what's going on behind the scenes and a view to conserve system resources and be more successful at debugging other than saying "Crap, it doesn't work! Can you help me?"
A modernized version of this course could even have a hardware project component with PIC's and STAMP's being so cheap and readily available nowaydays.
This same principle proves true for studying mathematics . In order to understand the system as a whole, you must first understand the basic constructs, or thereoms.
In computer science, it can be assumed that the basic constructs can be found in assembly language.
Even lower level math students get some exposure to thereoms, so why should Computer Science be any different.
Thanks for reminding the forum that Assembler is already one step removed from the actual machine language. I threw myself against several assembler lanuages and never got the result I desired. I loved the logic but hated the syntax.
Personally, I wish that, in the evolution of computer languages, we spent a little bit more time evolving a somewhat more intuitive set of languages at the assembler level. As there is still a great deal of programming that really should be done at the machine level, an assembler rival might help spur on the use of linux.
The book is going into my wish list.
To be a programmer without ever learning assembly language is like being a professional race car driver without understanding how your carburetor works.
Do you really think the driver needs to know how the car works? What a strange analogy.
Indeed, learning ASM before, or while you're touching a simpler programming language is a great step to learn on how to write tight and efficient code.
However, it's not just the comprehension of how the CPU works that is required. I've noticed many junior programmers, when they code, all they write and think about is inside their own little box surrounded by their compiler. Not thinking of network performance issues, interrupted database connections, data scalability, the fact that the day there is a bug, the presence of external dependancies, etc..
The problem resides on understanding the impact of all systems and subsystems that your program will be calling-out. When you program, and you're calling-out ressources that are outside of your program, you must be aware of what you're doing and who are you affecting. And, while you're at it, anticipate worst-case scenarios, like growth issues, fucked-up customer networks, the firewalls that break all the fun of calling-out RPC over a wan, etc..
So, ASM is a good step, but, it takes more than that, you need to understand (at the very least, conceptually) every single element that constitutes your production environment.
I don't think learning assembly can necessarily make one a better programmer.
I taught myself assembly a long time ago, and 20 years later I'm making 6 figures programming VBA macros for Excel. It's more relevant I know the ins and outs of the Excel VBA objects rather than lower level registers and memory allocation, though I do have to worry about memory leaks if I don't close out my objects.
"Easy" languages can help make the job simpler to accomplish, especially in cases where staffing is low and business demands are high.
Besides, as we design higher level languages to build software tools for us, I think the understanding of lower-level computer operations may not be that relevant to some programmers.
...where doing things in ASM isn't educational, it's torture. If you want to make kids lean how to do things in ASM, that's fine...but anything more than that is a waste of time. ASM is all well and good, but most CS curricula fail to put it in its proper contex. Nowadays, you use ASM in small functions where speed is absolutely imperative. Learning how to shave a few cycles off a nested loop in C++ is useful...making kids spend hours hunting for typos when pushing the stack is just a waste of everyone's time.
I would personally have students start in a C++ compiler, and have them drop down to ASM and write a print function...then say ok, on to the next thing, but you get to use printf() whenever you want, etc.
But there is another kind of evil that we must fear most... and that is the indifference of good men.
Today's generation has zero clue what it really takes to push those bits around.
All they know how to do is drag and drop widgets and call it 'programming'.
Or stick a Motherboard in a case and claim they can 'build computers'.
No clue.
Until you learn how a cpu works internally, and can build a system from scratch from just a data book, and then recite hex code for assembler you don't know diddly.
---- Booth was a patriot ----
The book was released under the GNU Free Documentation License, and it can be downloaded for free (in PDF format) from: http://savannah.nongnu.org/projects/pgubook/ .
Look again.
send us
YOUR
Action
Shots!
Anyone who cannot simultaneously consider the position of every logic gate and every memory register has NO business being in the same time zone as a computer.
Just a nitpick from an AC. "Disclosure" is what is missing here.
"Disclosure" is when you reveal your hidden interest, like the submitter's interest in the book that he's pimping. "Disclaimer" is when someone says that they are not speaking officially for someone else.
If assembly coding were a true Lovecraftian nightmare, then what would happen is this:
Programmer:
Noisome Bubbling Voice: Thou hast not installed a division by zero interrupt handler. Great Cthulhu requires one pint of thy blood, and thou must sacrifice the value in thine cx register.
--Rob
Towards the Singularity.
I would have thought throwing you into x86 ASM would be a bit harsh.
In first year uni we learnt R2000 MIPS Assembler which is the simplest of the MIPS family of processors,
which is alot cleaner, only 32 registers, all instructions are the same size, most instructions run in one clock cycle. This makes it easy to pick up, and once you understand it, migrating to x86 asm is pretty easy
x86 assembler is not a good beginner language, it has a lot of confusing addressing modes and exceptions and generally it's alot more complicated as it incorperates backwards compatibility with Intel 8086.
Instructions vary in length, complexity and execution time and i imagine would confuse a bunch of first year uni students who have never programmed before
I remember first year Computer Science, people had enough problem understanding C, things like understanding how pointers work is quite a challenge for students who 30% have never programmed before and 70% have probably done nothing more than introduction to Visual Basic.
I thought this was very interesting when I saw the article. I started learning computer programming with assembly language in the 1980's. In my case, I was too cheap to purchase any proper language (like C etc.) so I settled with playing around with DOS's DEBUG (this is an interactive assembler). I gained an understanding in x86 assembly fundamentals which along the way taught me plenty about interrupts, timing, device and memory use of course the fundamentals of CPUs.
:)
Though to many people this seemed to be a weird way to learn, I was very happy with it and it was nice and challenging to code entire applications in assembly language. My freeware is still posted, actually
Since then I've learned C++, Java, etc. but I've really settled on C. It makes the most sense to me from a power and efficiency point of view, since I'm mainly concerned with applications where performance is critical.
A new book was just released which is based on a new concept - teaching computer science through assembly language
I didn't know The Art of Computer Programming was a new book.
I have discovered a truly marvelous
This is the only way to truly learn about computers and to be a true programmer. It should be required learning before moving on to high-level languages.
First year Electrical Engineering students at the University of Texas at Austin take an Introduction to Computing class that starts with the transistor and uses a book written by Yale Patt, 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.
If you are too weak minded to learn a language as simple and basic as assembly, I'd suggest you stay away from all computer programming. We don't need another lousy programmer.
Fact is assembly is all about logic and moving numbers around/setting bits. It is about as simple as it gets if you can think logically.
One thing that has peeved me... I wanted to learn ASM when I was about 14/15 years old. I went to my high school's head of computer sciences to ask him about learning such a language (either as a class or on my own).
Being the naive "adults know best" type of kid, I just took the guy's word for it when he said "you need lots of math". DUHHHH. Fact is you don't.
I wish I hadn't given up at that point (sticking to slow as molasses BASIC). 3 years later I bought myself a book, read a few chapters and off I went coding games and demos on my C64. I really regret not learning it when I first wanted to. I could have accomplished much cooler things...
way to totally ruin it
The 68K instruction set is better than most of them, although if memory serves the Z80000 was even better.
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.
Need Mercedes parts ?
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.
The Story of Mel
Abolish Copyright. Restore Freedom.
Eh, it isn't really unheard of today.
In the old days, computer scientists didn't really exist. You basically had groups of electrical engineers, mathematicians, etc, developing what is today computer science.
As a graduate of an accredited Computer Engineering curriculum, my take is this; computer scientists develop software, algorithms, etc. Computer engineers design the underlying digital circuits, logic, and such. Software guys vs. hardware guys.
As such, you'll find computer engineers use assembly a heck of a lot more than computer scientists. I've worked with MIPS, x86, motorola's, and several others. And when you get down to it, I like to work with C more than I do with languages like C++ or Java. I enjoy the low-level nitty-gritty.
I'm making a generalization of course; there's no great schism between the two groups and our work often overlaps. We just each use the tools most appropriate for our jobs.
A preposition is a terrible thing to end a sentence with.
I learned BASIC and Assembly Language together when I bought a C64 a lifetime ago. I found Assembly to be the easier of the two, although more time-consuming to write and debug.
And Assembly is a lot easier to write than any Object Oriented language I've ever seen. If I had the time, I'd write everything in assembly, but I don't, so I won't.
By the way, you have never lived until you've written 4K of assembly code on a Machine Language Monitor instead of an Assembler (C64 graduates know what I'm talking about. Remember HesMon?). No nmemonics for variables or addresses -- all hex, baby. That is a lot of tedious coding, so you learn the value of small programs.
The last commercial program I helped write took up 8MB on the disk. Oy!
I am currently a Computer Science major (last semester!) and one of the required courses is Assembly on the SPARC architecture. I took the class a couple of years ago, but at the time it was the first semester since they had switched from x86 to SPARC. I'm not entirely sure why they switched, but I really appreciated learning an architecture that I don't use on a day to day basis.
I clicked on the OSDN ad from Microsoft with the "FREE .NET STARTER KIT" so that I too can be a CS wiz4rd.
Seriously, when did OSDN start lapping up Microsoft ads?!
Full Story Here
Abolish Copyright. Restore Freedom.
I know many Computer Scientists who spend their whole day at the white and black boards or on paper.
Rarely do they touch code and rarely do they ever need to.
Computer Science has some programming
Programming is not Computer Science
From the description:
To be a programmer without ever learning assembly language is like being a professional race car driver without understanding how your carburetor works.
My corollary:
To program in assembly language is like driving in the Indy 500 in a car that doesn't have fuel injection.
WARNING: there is a trojan on your
What a luxury that is. Why, in my day, we had to stick the ground wire up our arses and alternatively stick the "1" wire and the "0" wire in our mouths.
It really sucked when the ground wire and the zero wire were the same color, too. Boy, you didn't want to get that messed up.
there is a difference been an architect and a designer.
an architect lays out what a program will do, and how it will do it.
A designer lays out how the code of choice will facilitate the architects design.
an engineer puts it together in a way that it runs well.
a developer maintains it and adds new functionality.
an intern gets the mocha's.
There is no opinion on how something is put together, either it is well engineered, or it is not.
The Kruger Dunning explains most post on
Not to mention that the time when humans wrote assembly that was better than a compiler's output is long gone. Processors these days are just too damn complex. Direct assembly might be the best choice for simple processors on embeded systems, but certainly not for superscalar processors.
How many assembly programmers unroll loops for instance ? Loop unrolling is crucial for good performance, as branches are the 2nd biggest performance killer. How many actually think of instruction latencies and schedule instructions accordingly? How many people realize that the processor actually has caches and missing to main memory can take as much as 400 cycles ? How many people use predication to get rid of branches ?
Yes, a good compiler has knowledge of these things ...
The Raven
(waves)Hi!(waves)
That would be me. I did assembler programming (with some C when I could get away with it) from 1976 to about 1989 and have programmed, in assembler, almost every cpu and bitslice beast there was back then from microcontrollers to minicomputers.
Thw x86 instruction set, with it's puny number of registers was by and far the absolute worst piece of shit it's ever been my extreme displeasure to get paid to program. To add insult to injury those lame assed segment registers have been IMO, the source of more bugs than I could shake a stick it. It's hard enough to get this crap right but when you have the "oh, CS: I thoight it was DS:" nightmare it's just untenable.
I bet you could make a good case for estimating how much programmer time was wasted dicking with those stupid segment registers, and for no good reason, and come up with an insanly huge number of dollars wasted by some bad decision early on at Intel.
As one comp.arch poster put it so succinctly a long time ago:
Segments are for worms!
Looking at x86 I'm not surprised people have a fear and loathing of assembly. Assembler used to be fun, but hasn't been for decades. Bleh...
The best, as I said in another post, was the PDP-11. That was a downright elegant machine and it's no wonder C and unix are the way they are. God forbid DMR had had an Intel processor back then.
Need Mercedes parts ?
has been available for some time under the GNU Free Documentation License. I tried to use it a while back when I decided to learn assembler, but I found Paul Carter's PC Assembly Language to be a much better introduction.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
Am I the only one who went to a school where it was expected that you already had a solid knowledge of programming? From day one I started taking theory classes. Aside from a digital design class where we briefly worked with motorola assembly, the only programming I did in school was to aid in math, physics, and CS theory. I personally find it offensive when somebody assumes that, because I was a CS major, I am nothing but a programmer. Honestly, I was a better programmer before college, because afterward all my time was spent on doing proofs, developing algorithms, studying computability, etc. Implementation was, for the most part, trivial.
Anyway, that's what I learned about computer science. There are apparently a lot of school that teach *programming*, and I find that to be a real shame.
ascii art
Nothing else in the Universe can make students grateful -- grateful! -- to be allowed to use C
I'm a second semester computer science major at the University of Pittsburgh, and I'm taking a required course in assembly (albeit MIPS, not x86), and computer hardware fundamentals. Next year I'll even be taking a course in writing an OS (also required). Is this really unusual? I thought all computer science majors would learn these things.
As someone who had some knowledge of assembly prior to college (the z80 processor, as well as some very basic x86), I'm sometimes suprised at how little my classmates understand how the computer actually works. I definately feel that assembly has helped me in this area.
As a bit of illustration, I had no idea C used a stack, until I was playing around on the z80 (my TI-83... those were the days...) and realized that I could make a C compiler using a stack (but too lazy to actually do it, of course). I later found out that C compilers really do use the stack - but assembly helped me understand this better.
I'm NOT an awesome programmer by any means. But I bet as far as someone that doesn't do it for a living, I'm damn good and could probably hang with a lot of pros.
I programmed 8510 assy. on my Commodore-128 as a kid. Yeah, I had to, due to limitations of basic.
There's NOTHING like knowing how a computer works to make a computer work, ya know?
--Jim (me)
sorry if I'm a little skeptical... the poster is "johnnyb", the author is "jonathan bartlett" and the publisher is Bartlett Publishing? Granted I think that asm is useful, great to know, and does build a solid foundation for understanding. I just find a fundamental flaw when someone gets something /.'d that benifits them directly. "100,000 targets in this demographic... for free... sweet"
More likely, they're "wizards" because they've been programming since the release of the Apple II. If you had been coding for twenty five years, I sincerely hope that kids just coming up see you as a wizard. Otherwise, you have just wasted the last twenty five years of your life with no visible improvement.
All of the veterens know assembly because that's all they had. In twenty five years, all of the veterens will have started with Java or Perl or Python. They will probably have picked up some assembly along the way, but they will be able to whip out an efficient, global-scale, distributed program far faster than those old assembly coders.
- I don't need to go outside, my CRT tan'll do me just fine.
A great idea, C++ is useless unless you've done at least some basic programs in assembler.
I learned MIPS ASM and yes it was useful when I was programming in a structured language. But, once you goto a OO language, all that knowledge goes right out the window!
I don't mean to be a troll, but I really do foresee the need of ASM slowing diminishing to that of COBOL. After all, with the drive of C# and Java you aren't even compiling to ASM.
I am an HUGE advocate for always teaching assembly to early CS Grads. It's a right of passage, and will get the CS majors to the next level of understanding. But don't confuse a course in Assembly Language with a Course in using Assembly as a tool to learn about Computer Architecture. I can remember my first day in our "Machine & Assembly class". The first words out of the Prof mouth were "I am not teaching you any assembly, you have the pick that up as we go along. Depending on the teacher at my school, you either were learning assembly to do Bubble Sorts and very simple tasks, or you used assembly to wire up ISRs/catch keyboard interrupts and call into an out of C Programs. The latter resulted in an excellent introduction to how computers worked, and was an excellent prerequisite to an Operating Systems Class. The students who took the Bubble sort version didn't really learn much more than how to do a Bubble sort in a language they would never use for that purpose.
Now - As for using Assembly as the primary language for CS education, I don't think so. Like so many things in the CS world, use the right tool for the right job. If I am teaching a class in Database Implementation, I going to use SQL, Algorithms I will use some other higher level language. It all depends on what the focus of the class is = What you want your students focusing on.
The Operating Systems 1 Class at my old school used to use a language called Turing Plus, which lent itself nicely to the study of concurrency issues. Then in Operating System 2 you dove into using Heavy C/Assembly to write an OS from scratch.
Again - It all goes back to using the best tool to carry out the learning objective.
Ridiculous. At MIT (6.251) they threw IBM Assembler H and 370 Principles of Operation manuals at us on the first day of class, and we had to teach ourselves. The lecturer just ASSUMED we knew the language. The first programming project was due 3 weeks into the course. I think there were a couple of "extra" TA sessions for those who didn't get it, but that's it.
And, that was 1973. The projects were on punch cards. No full-screen editors, no CRT's, not even a printing terminal. So we had to learn to program keypunches, dup and sequence card decks, learn enough JCL to get by, and so forth -- also on our own.
I guess nowadays it's "Oh, wait a minute... is my object model right?"
No, asshole, half the programming you do ISN'T object-oriented, OK?? And a significant piece of the other half shouldn't be written in Java, OK?? Oh, and by the way, that piece of SHIT code you wrote, multiplied by all the other pieces of SHIT code that you've written so far, adds up to ONE SLOW M-FING APPLICATION, in case you didn't notice.
Remember, we used to run pretty effective word processors in a 48K TPA on a 4mhz Z80. Think about that the next time you power up 37 megabytes worth of MS Word.
Christ.
OK, I feel better now. Thank you.
Basically, I liked my education where I was taught concepts in the context of a language. You want to learn about memory allocation? Teach pointers and things in C. You want to learn about object oriented models... use Java or C++. You want to learn about how a computer functions at a base level, learn assembly. The language itself should never be the end goal, it should be a means to learn the concepts. The best programmers I've encountered are ones who have ideas, not ones who can't think outside a particular language.
"Oh dear, she's stuck in an infinite loop and he's an idiot" -Prof. Farnsworth (Futurama)
Hmm.... let's try a bit of 'reductio-ad-absurdum'
Best programmers are the ones who know assembler.
Knowing assembler is having a 'deep understanding' of computers.
Those who cant program assembler don't "really" know how computers work...
I'll agree that knowing what assembler is and how it works may yield a better understanding of computing as a whole, especially when compared to someone who's only programmed in a high level language. But to suggest that those who know assembler are generally better programmers is frankly ridiculous. I know plenty of people who know assembler (6800, x86, etc.) who couldnt develop software, let alone program themselves out of a paper bag.
That's right Mr. "Oh, I can't write a program without both 1's AND 0's". And if you think considerling logic gates and memory registers is powerful, just imagine what it must be like to be me, who wouldn't even consider posting this without knowing the precise state of every electron covalence field of the atoms which MAKE UP those logic gates.
Yeah, so just think about that the next time you ask me to bring you another cup of coffee and the check, you arrogant 10% tipping bastards.
its not that knowing assembley makes one a better programmer; its that better programmers know assembley cause they harder working and brighter people
Here, here. There is no verb, "to architect," hence no past participle, "architechted." Natural languages are equally deserving of respect as the artificial.
Perhaps it's time that computer science curriculums start teaching assembly language first.
Yeah, as a mathematics major I've often felt that number theory is glanced over far too often in high schools. Kids really ought to learn why 1+1=2 and how to strictly define multiplication of integers before getting into such oversimplifications of mathematics as the Pythagorean Theorem.
I think the submitter is proceeding from a false assumption. Anyone who's really pursuing a BS in Computer Science (from a reputable school, anyway) is probably going to get a course in assembly language whether they like it or not, and anyone who hasn't earned a BS shouldn't be calling themselves a "computer scientist."
And I submit you have no basis for that assumption, other than an outdated idea notion that the processes should be separate in all instances. Isn't one of the points of Pragmatic Programming, Scrum and eXtreme Programming to eliminate the separation and make the code the design? Even old style development models a "capture" phase.
:)
The idea that the process of making software and the process of coding should somehow be separate is old-fashioned. Even massive corporations like Lockheed Martin realize that the processes are bound together (although not every manager goes along with that philosophy very well).
We need to stop thinking this way. Software is not an engineering process like other ones, where designers design and then manufacturers go to work on it. People actually realize this these days, and it's slowly becoming an accepted fact.
The rest of your post I agree wholeheartedly with.
Slashdot. It's Not For Common Sense
I had to use boxes, but sucked the air out of them.
Really. I learned assembly language first. The mere thought that there are 'programmers' that don't know assembly is uncomfortable. I really don't know what to think of it. It's kind of like as if someone told me that Jesus, Santa Clause were at the door and wanted to play poker, and they brought their own booze and hookers, and that Elvis was on his way on the back of the Loch Ness monster.
HOW DO THESE PEOPLE UNDERSTAND THE MACHINE? In a way, I guess that's what separates the men from the boys, or in this case... real programmers from the lusers... the ability to blueprint the code, how the code works in the machine, and where/if/why errors appear.
Steve's Computer Service, Hobbs, NM
From the little bit of coding I've done (used to write in BASIC, years ago, took a course in C programming in college, etc.), and from all the work I've done along-side software developers while working in I.T. - it seems to me you really can divide programming tasks up into two basic types.
You've got "low level" and "high level". If you aspire to do the "low level" development, that means you're looking at such projects as building device drivers for hardware, code for embedded systems (maybe it's the applet that runs the front panel on a laser printer, or the display and controls on a car stereo or cellphone?), or possibly even developing the compilers themselves.
Meanwhile, the "high level" developers are helping work on larger projects... full-blown applications, front-ends to databases, maybe even computer games (where nowdays, you can basically purchase the whole "engine" from the "low level" guys who did that part for you already).
If you're working on the "low level" stuff, I'd agree that you better learn assembly code, and learn it well!
If you're just doing database front-ends and the like, it's probably not really necessary. I won't argue that people who know assembly understand the real inner workings of the computer better than those who don't. That's probably very true. It's just that sometimes, that's not critically important. (EG. I'd rather have someone with a good eye for color and a good artistic background helping build an action game, especially if I already paid for rights to use the Quake engine or whatever....)
Hasn't assembly been around for a while?
But seriously, I had to take a class that delt with assembly language. Unfortunately it wasn't x86 asm but rather MIPS. It was a good course, taught me a greater apreciation for the higher level languages. (That and to run away from any job with assembly in the job description)
It's cool to learn and to help in debugging but I wouldn't want to write code in just assembly.
I'm sorry guys, that sounded bitter. But I'm really good at Uniary, does anyone have a job? Seriously, I haven't worked since writing
"Microsoft Off, Version 0.0".
Then they turned it into "Microsoft Off-ice", and it was it "so long Dr. Zero", wasn't it? But when you're computer goes haywire, whadda they tell you to do? That's right, it's Dr. Zero to the rescue. So please give a second chance to an old computer purist like me? Or at least, stop sticking your chewing gum under the damn table. I got hepititus 3 times last week!
In a real high level language, say OCaml, you're going to be able to write a given data structure in a tenth of the code that you'll need to write it in assembly.
It will be portable between different machines.
It will be polymorphic.. allowing you to use the datastructure with different types.. a list of arrays of hashtables of red/black trees containing strings.
You won't tell the computer what kind of pointer you want. I'm not sure why you imagine this is an issue in the 32 bit world we live in.
You will appreciate having the typechecker catch bugs in the code, because you're working on a problem of some complexity. Often, when your program typechecks, it will work perfectly.
Everyone should learn assembly. It is important that you know how the machine works so you can get a good idea what the costs of various operations are going to be.
But outside people writing device drivers and maybe some code for embedded devices, (highly machine dependend and not algorithmically complex), nobody should be programming in it.
# (/.);;
- : float -> float -> float =
To say that knowledge of assembly language is a requirement of programmer excellence is a ludicrous generalization. The measurement of the ability of a programmer is enormously context-dependent. I can imagine that a low-level micro-controller programmer could possibly be far less qualified as a developer for a large Smalltalk based order management system, than a programmer with no knowledge of assembly or even C, who instead has a strong theoretical basis in object-oriented systems and Smalltalk development experience. Programming abstractions have created vastly different programming contexts which resonate with markedly different programming abilities and experience. Why does such ignorant conjecture pass the moderators on Slashdot?
Arizona State requires one semester of digital design (with the final project being to build a simple 4 bit programmable computer in LogicWorks) and then x86 or 6800 assembly before moving on to higher languages.
I was able to build a 4 bit random number generator in LogicWorks (that has a non repeating sequence of hundreds of 4 bit numbers) along with an 8x8 programmable LED display and other parts required to put together a Tamagochi.
OpenTama project complete with all the schemetics for all the parts I've assembled down to the gate level. The only thing missing I can think of off the top of my head is the state machine to drive it all.
The final project in Assembly is a "stop watch."
I highly doubt ASU is the only university to start off the Computer Science degree with how to build a computer before learning how to program it.
Ben
Work Safe Porn
JohnnyB, use your lightning powers to teach us ASM!
assembly is standard material for any cs student, and using AND and NAND gates, how about flip flops? resistors! building your own 8 bit processor!! I did these all last semster for my cs210 and cs220 classes! revolutionary, indeed :-O
Start with a nice high level language like C++, then take assembly. Although CS students should eventually learn assembly.
> High-level languages are great, but learning them will never teach you about computers.
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.
OK, so you do lab experiments with staffers and image consultants or something?
Military Science
"What have we learned?"
"When we dump fuel air explosives on things, they explode."
"Fascinating. Let's try it again and see if it still works."
Library Science
So damn silly, I don't even need to bother with an amusing comment.
About being told dumb things about computers by adults: I had one of the old Radio Shack color computers, circa 1984. I went down to the local Radio Shack -- not one of the mall stores, this was the Columbus (OH) Computer Center. They told me "there's no such thing as an assembly language for those computers". Argh! I might have become a computer wizard instead of a failed music teacher turned perpetual grad student.
The full x86 instruction set is large and complicated (some of the complexity because of its history). Adding an OS like Linux and all the hardware for a PC just adds a whole lot more stuff for a student to have to deal with.
If this is a learning exercise, wouldn't it make sense to reduce the clutter of the environment (OS, PC hardware) and isolate the learning to only what is relevant. Why not start with a simple 8 bit microcontroller like an Atmel AVR, TI MSP430 or prehaps Cypress PSOC? Once the teaching mission has been accomplished and students are comfortable with programming concepts and basic computer architecture ideas, step up to using a higher level language like C on these micro's, then step up to the PC environment including an OS like Linux. At that point, the learning options expand greatly.
This plan lets students acquire a deeper understanding at first, because they can explore the microcontroller completely - it is simple enough for a beginner individual to understand every aspect of its operation, unlike a PC. As a bonus, there is a great sense of accomplishment in fully understanding something instead of partially understanding it, and a stronger feeling of connectedness if you can make a micro do something physical.
Those of us whose introduction to computing was through simpler machines like the Apple II (it even came with a full circuit diagram!) must know what I'm talking about. I don't know if I'd be nearly as interested as I was in my youth if I were just starting out in computing today and my introduction was a PC. I'd probably just use it to play games, like most kids seem to do.
I hadda study fotran,jiva and paxcal before I could go homey.
Last time I checked an architect doesn't 'architect', she 'designs', therefore the past tense is 'designed' not that godawful non-word 'architected' that has sprung up here on /. several times recently.
I hear you. My peeve is people who verb nouns. It's a losing battle.
...his site is at http://www.grc.com, he's got loads of security related info on his page and a shedload of Win32 progs coded entirely in assembler, every last line of em. He also created the very neat ShieldsUp tool to scare people into getting a personal firewall installed (like listing their netbios share names, doing a remote port scan and telling them the gory details of what people could do to their computer etc.).
Most of the progs are under 30k in size, including a very cool sub-pixel font-rendering demo, and ones to disable messenger, dcom and upnp. A really nice touch is that some of them have sound fx, produced by a simple virtual synth, also coded in assembler...just cause he could (a true geek!)
I am NaN
Its sort of like comparing Renoire with Picasso.
All the kinks and weirdosities in x86 make the programs written in it beautiful, like the artist that paints with his toes. I even had a chance to use the JPE instruction once, it was a beauty to behold!
Why waste time reading, learning about computers; the indians are the new geeks. Americans are just dinosaurs. It sucks, I know.
Sorry if this has already been mentioned, but the book is available for dowload from this site, under the filelist link. Here is a direct link to the pdf.
--
Was it the sheep climbing onto the altar, or the cattle lowing to be slain,
or the Son of God hanging dead and bloodied on a cross that told me this was a world condemned, but loved and bought with blood.
I race cars, albeit not professionally. You are very incorrect.
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.
..don't panic
Modern compilers are smart enough to perform many of these optimizations, and sometimes obsfucating your code can even interfere with their ability to recognize optimizable situations.
I am suspicious of onlien bookstores which do not even show the table of contents. So do I just buy this book since it has been '$touch assembly-book slashdot' ?
"High-level languages are great, but learning them will never teach you about computers."
Sense when is computer science supposed to teach you about computers? It's supposed to teach you about computer science (algorithms, language theory (not languages), etc). Teaching people in assembly may help them learn more about a computer they might use, but that doesn't mean you're teaching them computer science.
Of course I'm probably one of the few people who thought CS 1 using pseudocode was a (potentially) good thing (the graders were a bit to anal, "you forgot the '.', 0"). Pseudocode allowed for students to learn CS Theory without having to get stuck in syntactic hell. Follow that up w/ some high-level languages, and they can apply what they've learned. Let assembly be where it belongs, in a course on, oh say, computer architecture? Not as a beginning language.
I really need to learn how to not ramble.
I know and have hired many people in the field, and I say that abstract theory is more important that assembly. Yes there is great value in knowing the details of how the processor works, but really, anybody can pick that up.
What more people have difficulty in is algorithm and data structure theory, which has more intellecual leverage than the simplicities of assembly.
For example, who is going to build a better database, one who knows assembly or one who can compute big O algorithmic runtime? I say the latter.
I am relatively new to the CS world compared to those "wizards" but my favorite class a University was a ASM course (which was required) Our first proramming assignment was to program a keyboard controller, that took all the scan codes from the keyboard and allowed one to type on screen. The class was delightfully difficult. We had a crappy textbook, but we had the Motorola 68000 "manual" basically a brochure with all the instructions, their opcodes, operands and other basic info. The sheet was worth nearly its weight in gold. This course gave me a deep understanding into computers and the logical thought required to program well. I definitely think it is a good idea to learn assembly.
The School: Indiana University.
The Course: C335.
Did anyone else notice a very well hidden joke in parent? Very nice. :-)
Or maybe I'm just a crazed illiterate.
However, when my then employer needed a high performance CPU for their missiles, they designed what in later days would have been called a RISC chip. The instruction set was all of maybe 20, so few that many of us found ourselves coding patches directly in hex. There were just a few general purpose registers and four pages of memory to worry about.
It was elegant, straight forward, and only took a few sessions writing a patch to get the hang of. Once over the hurdle of writing a few lines on an embedded system like that, taking the next step and coding to an API of an open source system ain't too much bigger of a deal.
Luke, help me take this mask off
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
jim frost
jimf@frostbytes.com
lesson 1: never listen to radio shack employees, you would probably get better advice from some random homeless people on the street, at least one of them is probably an out of work software engineer these days
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.
Anyone remember, or still able to read, Knuth? He was Mix'ing it up before most /. readers were born. Real computer scientists can disassemble core dumps at the console
Umm, thanks, but I think Calvin, of Calvin and Hobbes fame did it better. :)
Assembly is the ONLY way to get a full appreciation of how computers work. The University of Colorado doesn't start with Assembly, but it definitely gets you there eventually. If you've never coded Assembly you might as well be a mindless .NET spewer-of-white-paper power words...
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.
Fire up an old Apple ][ emulator and check it out..
Seriously though, starting in ASM is a GREAT way of weeding people out of CS. OTOH, unless you're developing hardware drivers or embedded systems software (or working for NASA), it's pretty much a waste at this point, and it is highly unlikely you can beat a modern compiler for optimized code anyway.
Seriously, I remember teaching RB to 4th-6th graders when I was in HS, and I'd end up playing it myself for hours, 'twas hella fun..
I find the best programmers are the ones who are a whizz with the soldering iron.
Sniff your programmer, and if he smells of molten metal and old boxes, you know you have a real expert on your hands.
Charles Babbage was a great programmer and he didn't even know BASIC.
Well - I could be moderating!!!
I have no intention of drooling in this glass of wine I am enjoying... but...
This is a good idea. It is a very good idea. Every real profession needs to have both roots and wings. The idea has merit from many points of view. And the more I think about it the more merit I think the idea has.
Having more than 25 years experiance and more than 20 years as a consultant, developer and so forth... I can say that from my perspective there are patterns I have witnessed which I find very disturbing.
I will summarize. I personally consider many (and perhaps the majority) in this profession to be totally incompetant. Having said this - I'll contrast to the feild of Geology and Geophysics (both feilds of which I have strong ties). In my years of working with the Geologists, Geophysists, Reservoir Engineers in every major corporation and instution which has paid me A LOT OF MONEY - I have NEVER run into a single instance where the cheif geologist, or cheif engineer or cheif geophysist was not very well respected by their collegues for their experiance, their judgement and so forth.
Yet - in my proffession. The horror stories I can tell and the incompetance.... whoa boy! Abject stupidity abounds.
Let me ask. If you look at a gneiss rock - most professional geologists can tell you the minerals and related rocks. So can I actually. To be promoted to cheif whatever - you gotta know your stuff.
What of the IT people?
Do you want to know of the manager of a computer department who didn't know the numeric data types the computer supported? what of the programming languages and what they supported? Would you like to know of the suggestion to try to develope a Production Acccounting package using a programming language where you could not write a callable function/subroutine? Where the variables were restricted to A1, A2, B1, B2 and Same with $?
This was a major oil company of Royal Dutch decent that tried this trick.
This is just the tip of the 'berg. How about the consulting firm out of Winnipeg,CA that recommended after intensive study the purchase of a computer which you could not install enough disk drives to carry the data... and at the same time recomended the development of the applications software in a language that did not support a data type that could even count the number of oil/gas wells drilled - much less the technical data collected.
Oh - and after 3 years not a single line of code was written.
They were doing _HIGH LEVEL_ work!
In my entire life I have experianced such a deplorable level of BULLSHIT as seems to course normally through the feilds of comp science and IT. Yet when I look at related fields - I am totally impressed with the caliber of the work that is done.
A simple example in the feild of Physics for instance can be found by reading the Feynman books.
If anyone who chooses to read this post cares to call up the local public library and ask what they have on Feynman.... perhaps ask for the Feynman Lectures on Physics ON TAPE - ALL OF THEM - then this would be a good start.
Feynman knew his stuff. So should IT people. I for instance should not have to walk into a room full of IT people and find that not one knows what COMP-3 is and why it needs to be there and why C++ really doesn't do the same job.
To draw this post to a close. A geologist is expected to know his mineralogy.
In the IT world - even the analagous basic level of knowledge of the data types the computer or language supports is often mixed in with the vapid ideas of abstration that float through the ether of higher intellectual thought.
Real programmers convert thier algorithms to state machines, then build the state machines out of nand gates. User interface, LED's and toggle switches are an excellent user interface
I think this internet thing sounds like a good idea
I'm all for the bottoms up approach to learning about computers.
Here is a book that every aspiring computer scientist should read:
Introduction to Computing Systems: From bits & gates to C & beyond
by Yale N. Patt, Sanjay J. Patel
"Computer science is as much about computers as astronomy is about telescopes" -Edsgar Dijkstra
That's not to say that, however, that understanding machine code is not a useful skill, but it is certainly the wrong approach to teaching "computer science." When searching for this quote, I found this page which outlines why "computer science" is not about "hardware" at all.
...not Computer Science.
"Computer Science is as much about computers as astronomy is about telescopes." - Edsger W. Dijkstra
Berkeley EECS majors do ASM last:
CS61A, "Structure and Interpretation of Computer Programs"
- Scheme
CS61B, "Data Structures"
- Java
CS61C, "Machine Structures"
- C
I just spent the last few months hunkered down with the Art of Assembly book by Randall Hyde. I worked my way though all the HLA functions in a matter of days, then switched to writing in masam and using hla's output to figure out how he was doing things so i could replicate them. I still suck at floating point, but i'm getting better and hope to start in on sse and mmx soon. I have learned way more about how computers work in the last few months then in the last 8 years as a programmer. I know some C, some C++ (never really use them, i do lots of web scripting), a lot of perl (I love perl), php, VB and the .NET's (who doesn't know vb) and of course my new baby that I do a lot of at work,java.
I'm finding myself writing less code now that I understand better how to problem solve. And I am not complaining as much about language syntax. But I do find myself over analysing the issue. I have to keep reminding myself that sometimes their isn't some super awesome way to do things and you just have to grind it out.
Overall, I recomend learning x86 assembly. Learning it the way Randall Hyde suggests was really easy to anyone who knows C syntax. And if you do as he suggests and slowly stop using his code and start using "pure" assembly slowly (writing your own loops, and functions and learning the hard way to preserve your registers) It doesn't seem as bad as it would if you had to jump in and write your own print function on day 1.
Please don't even suggest that this is a new idea. Donald Knuth wrote his books not using assembly language, but one he created for a machine that didn't even exist (MIX). Ask your dad if you borrow his Volume 1.
I remember using debug to find copy protection and then using NOP commands to circumvent it...
I learned 6502 assembly language by hand assembling opcodes at a "summer program" at an NYC-area tech institute. We literally "wrote" code in pencil on graph paper, then triple-passed it against an assembly->machine language chart. When the bank of Apple ][+'es was available, we squirmed our little 11-year-old bodies up into the operator stools, hunt/pecked "call -151" for the machine language monitor, and righthanded the hexadecimal onto a numeric keypad. Then saved to tape for backup, and ran it. For better feedback in debugging, we ran lots of bitmapped routines, so we could see our bugs in action. We had lots of help from the curious grad students, working the DEC GIGI graphics terminals on the VAX mainframe. They had the biggest comp graphics lab in the world at the time (generating about 3 minutes per team per semester), but they could tell that these kids with Apples were the future.
Later, when I learned forth, I already knew what the language was directing the CPU to do. And C just seemed like a great macroassembler, C++ like an aircraft carrier of macroassemblers. The underlying computer architectures haven't changed, in spite of the arrival of genetic algorithms, neural networks, and reconfigurable computing. I have benefitted not only from the intimacy with the machine I'm instructing, but from seeing the reiteration on every scale of the same underlying structures that assemblers process. And the value of just importing C++ classes, or calling remote procedures and web services, rather than writing all that stuff myself, is the oxymoronic moral of the rags to riches story of a happy, generous miser.
--
make install -not war
Who is Jon von Neumann? If you don't know and are planning on programming you should find out. Worse, if you already have a CS degree and don't know about "von Neumann" architecture then you missed am important topic.
....
If you want high performance code, you must understand procedural programming and assembly language. You must understand the components of the modern "von Neumann" architecture like RAM, Registeres, L1 cache, L2 cache, ALU etc
While everyone has gone OOP (Object Oriented) crazy, the "von Neumann" architecture is NOT optimized for OOP programming. Because modern CPU's have lots of cache, the latency that exists between the CPU and Memory is reduced. This is called "faking" memory bandwidth, read this article on the von Nuemann bottleneck.
Serious coders should learn ASM, then move to a higher level language like 'C' then see how the 'C' statements compile in ASM and then analyze efficiency.
Modern wisdom says, be wasteful, vendors will make bigger/faster machines and we won't have to care that our code is slow, inefficient, and not optimized for the architecture. Keep in mind, you can save substantially on hardware expenditures by hiring good coders that know how to tune and optimize code but, if you don't want to be bothered, just plan on large capital expenditures every couple of years. Also write everything is JAVA and make sure you create indexes on every column of every table in your database for faster lookups.. ( I am joking, don't really do this. )
...available at ProgrammingGroundUp
It was called "C".
dinner: it's what's for beer
Real programmers already know machine code.
Bill wants you to renew your MSDN subscription and use C# and .NET so your apps can run on heterogeneous systems.
Do Bill's bidding. Do it now.
Trolling aside, go to Gibson Research and download some of their apps. They're most if not all written in assembly language, and they're fast. They'll portscan your system for you, too.
DT
Is this thing on? Hello?
I disagree. The best reason for learning assembler is to understand how computers work in the most minute detail. This may or may not be helpful when working in higher levels of abstraction. The best reason for learning Latin (or any foreign language) is to be able to read it (or hear it) untranslated.
The correct answers are down there, but just to collect them and clarify - you can build anything using nothing but NANDS. Alternatively, you can build anything using nothing but XORS. You can prove this easily using demorgan's theorem.
However, in the real world, NANDS are cheap (2-3 transistors), so that's what everyone uses.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
- Your high level language programs run faster when you know assembly? Well, maybe 20%, but how is that relevant today? Computers will be 20% faster in 6 months. And better algorithms can get you 2000%.
- Your HLL programs are better if you know assembly? None of today's techniques to create maintainable code (structured programming, object orientation) came out of assembly. Quite the opposite.
If you're a PHP or Perl programmer, how does assembly knowledge influence your programming style?Seems like we have some dishonest self-publication here. The person who posted the slashdot post also published the book.
As the poster of the article misleads the reader into thinking the book is not related, and is also a heart-on-the-sleeve Christian, What does the New Testament say about misleading others?
For my introductory computer engineering class, every year the midterm includes a question: "Built the above circuit using nothing but NANDS/XORS" (they change that last part from year to year)
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
ATARI games were written in FORTH, not assembly.
FORTH is soooo much better than assembly, and just as close to the metal.
When I started at IBM, in 1962, they sent us to programming class and the first thing they taught us was ... all together, now ... Assembler!
... Fortran. Not Fortran 96, nor 77, nor 66, not even Fortran IV, but Fortran II (ugh!).
...
Of course things were much easier then, we were on the 7090 which is a "direct address" architecture, that is, the actual address (all 15 bits of it!) is part of the instruction. There were index registers, and occasionally you might code an address of 0 and use the index register as a "base" or "segment" register, but that was the exception. The 7090 architecture had its glitches (index registers were subtracted from the address, but by and large it was much simpler than most of today's machines, and much easier to learn assembler for.
Oh, after we finished Assembler, then we moved to a "High Level" language
By the way, I'm doing this post as AC because I've got lots of copies of my resume out there, and not one so much as hints at my having been working in 1962
Sounds like a bad idea to me, for reasons pointed out in other posts.
.
For a first course in CS, I think it would be hard to do better than one based on Structure and Interpretation of Computer Programs
This book takes one from zero to writing a compiler in a few hundred pages, including a chapter on writing code for register machines which gives the student a good idea of what is going on "under the hood."
To those who would say that Scheme is useless outside of academics, I would counter that once the concepts in this text are mastered, it is easy to transfer them to other languages.
Considering the amount of reasoned, informed debate his submission has generated, it's clear that the question of teaching assembly language to beginning CS students is worthy of slashdotters' attention. His submission may have an element of self-interest, but its content has obviously prompted a lot of discussion--which is, after all, what we're here for.
I'd agree that to really know computer science you need to know how a computer works.
and a good way to do some of that is to learn assembly tho basic understanding at an even deeper level can be helpful.
at Purdue University there's a computer architecture course thats required for CS students. it was recently overhauled (im told it was pretty irrelevant a year or two ago) to include things like actually building digital circuits and learning assembly (SPARC this semester).
I'm pretty sure that any good CS program does or should include this sort of thing.
It is correct that many (most?) good programmers have a decent understanding of the underlying machine. I wouldn't go farther than that and claim that it's the assembly knowledge that makes them better. Gigantic logic flaw. You're immune to it though, once you put the magic "linux x86" in it, your submission will be published.
Shut up or i'll knife you in the face.
Then I'll shovel your decaying body into a box, and fire the box up in a crematorium.
You're doing it wrong.
Does anyone have pointers on what types of chips and where to purchase the small displays used in bicycle computers that monitor cadence, mph, avg speed, etc.?
I've purchased various cyclometers, but would like to add features and customization abilities.
These days, kids come out of school unable to manipulate simple pointers. Why? Because the sissy langauges they use don't even USE pointers, so they were never TAUGHT pointers. God forbid they have to figure out how a machine is going to execute their code!
What they do know how to do is read. They read what's going to happen in the future. They read about the NEXT version of Java and its speed and other associated wonders. They read about how feature xyz is supposed to work (I read the source code for feature xyz; it doesn't work that way). They read about the flying car they're going to be cruising around in in a few scant years.
As a fallen Java evangelist (not to pick on Java, but it deserves it), I've learned that there are a few constants in that particular language. It's slow as balls; it has been since I was using it in alpha 7 or 8 years ago, and every version promises that the next will be faster than C. Container-managed beans suck; for 5 years, they've been saying that the mythical container (read as: someone else) will magically optimize them, which we all know is bullox. The more fictional something is the more it's talked about; Java's been talking about Jini for something like 4 years now, with absolutely nothing to show for it.
If students spent more time learning assembly and less time fluffing around with "references" (which is short for "retarded pointers"), they'd be much more bitter and cynical... Like me.
:wq
This sounds like a really good approach. The trouble with computer science is that there's the mathematics and logic behind it, the comparatively simple digital hardware, and then a lot of jargon gobbledygook and quaint, contemporary fashions that so often passes for "science". The truth is that CS is about moving bits and bytes of information around and changing them on an increasingly large scale, and the basic algorythms for doing that. High level languages try to hide the fact that the way any computer works microscopically is basically the same way it works macroscopically. While reducing complexity for the user is an obvious design goal for programs and computer languages, teaching CS with just high level languages is like teaching magic (a contradiction in terms). It becomes very hard to understand what the limitations of a computer are when students are given an ideal, abstract mental model of a computer instead of a real one.
I wouldn't say the make|break point of determining the prowess of a programmer is assembly language. It's more like the types of skills they've acquired or classes they've taken in college - those who wonder what the difference between going to college and hitting the job scene can benefit from knowing college provides the opportunity to create a structured environment for learning specific skills and be exposed to particular topics.
When I graduated almost twenty years ago, I'd written my own DBMS, my own compiler (for a semi made-up language - an extension of DCL on a VAX), Language Structures - what languages tend to have and don't have in common, how to examine a language and acquire experience in that language quickly. Several other classes in specialized (but part of a broad experience) helped.
Assembly language? Yes. We were permitted to use single character input and single character output. All other forms of I/O were up to us. First programs were "input a number, then output the number." "input a list of numbers, then output them." "input a list of numbers, sort them, then output them". I was turning in programs of three or four lines because I wrote my own library routines (but they were small, easily maintainable calls).
Where does this apply today? There are tons of people today who submit resumes and what's listed for college or the first two or three jobs out of college? Programming. Programming. Programming. No balance. They seem to have no balance except for programming.
I have to agree that this is a very good idea. Now that I'm in my fourth semester of programming classes (first 3 all being Java) I'm now learning C and assembly, and must say, it's quite enlightening. You can know a lot about computers by learning higher level languages, but when I finally started learning assembly it drew that final link between software and hardware and finally the whole picture came together.
Good idea, I say!
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!
Speaking as someone who's been there and done that with MIPS assembly code, I'm not entirely convinced that programming stuff in assembly is going to do much of anything for the average program.
Problems with writing in assembly:
1. It's slow to write. IIRC, there was a study done that people who wrote in C and assembly produced the same number of lines of code. That means the assembly guys were producing less work than the C++ guys.
2. It's non-portable. System calls differ. Not all machines have the same register conventions. Hell, the NUMBER of registers differs wildly. Your wonderful hand-coded assembly is going to be mostly worthless outside of the platform you programmed it on, and if it ain't, you probably weren't exploiting the architecture all that well to begin with.
3. Improperly optimized assembly isn't going to net you any performance gain. Even GCC is going to do a better job than the average assembly language coder. So, yeah, the best of programmers 5% could do better on 5% of their code, but that's not going to convince me it's the best idea for even "just great" programmers.
In other words, it's probably better and more efficient to program in a thoughtful way in C rather than try to shove assembly code everywhere in hopes of some sort of speed gain. Certainly, there's reasons to use assembly, but at this point, I would think it's mostly on embedded apps.
The idea of getting to know at least one architecture on an assembly language level (hell, a binary level) is not a bad idea at all, and will indeed probably lead to better higher-level code in general. But trying to say that it's some kind of magic barrier between being mediocre and good is entirely off the mark. Being a good assembly programmer doesn't automagically confer you amazing abilities in Lisp or Prolog.
I have no idea what the submitter thinks goes on in good CS schools these days. I know they worked me to the bone with large projects in assembly, C, Java, Lisp, Prolog, you name it. The idea that they don't teach assembly is idiotic.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
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
i goto Baylor, a school known more for republicans so conservative rush limbaugh pitches a tent, and even here we have at least one assembly class required.
p.s. read the rope
lose != loose
Speaking from some experience (CS undergrad TA while in grad school)....
... wait for it ... PostScript. PS sounds wacky but it's the only stack based language widely used on modern computers (APL and Forth have died out).
...) had BASIC interpreters in ROM, and they were mostly OK, though the only one with a really good BASIC language (proper procedures, not GOSUB) was the Acorn BBC.
A few thoughts:
It's essential to teach some assembly at some point in a CS undergrad - A CS course should give full insight into the workings of a real CPU, and should give as wide a variety as possible.
At Edinburgh the first year CS course included assembly, C, and
When I was a CS undergrad we had practical classes in no fewer than 17 languages, covering the range of imperative, declarative, functional and stack based, plus specialist toys like theorem provers and SQL.
The best starting point for a university level course is the good old procedural language - in my day it was Pascal, C++ and Modula-3, these days I'd use Java (and many CS departments do).
Also, when you do get to assembler, I don't think using a real assembler is the best teaching tool - assemblers are intended for developing real low level code, or as back end targets for compilers. For teaching at Edinburgh, we used an X11 based tool called xspim which simulated a MIPS R2000 (we actually ran it on Sun Sparc-II's, not that it matters), and it let you single step and examine registers without the complexity of adding a debugger, and had a window where you could see the registers, CPU pipeline etc. displayed.
For introducing programming concepts to a younger audience I think an interpreted language which will execute command lines, allowing them to experiment while avoiding the edit-compile-run cycle, is very important. Some are better than others; when I was a kid the 8 bit micros (Apple, Commodore, Atari,
I don't like Pilot or Comal for teaching (failed experiments of the 1980's) but I think LOGO is a very commendable way to make concepts accessible to the young.
A perhaps unexpected place I was made to learn with an interpreted environment was as an undergrad at Cambridge University, where the first programming language taught is ML which for the CS people who haven't heard of is an implementation of lambda calculus with a sane syntax.
assembly language programming is a good way to learn how computer architecture and programs interact. it's not a good way to learn how to write modern computer applications. there is a place for both kinds of programmer. some code needs to be written closer to the hardware, and some code needs to be written closer to the user. there is a need for both kinds of programmer.
New concept? Sorry children, but back in the day (mid 70s for me) we all started out with assembly language. It isn't new - it's mostly a lost art.
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
Seems like Knuth's books have been out for a long time...
Correlation doesn't necessarily mean causation.
I'm completely convinced you cannot be a computer Master if you didn't learn assembly language when you were a grasshopper. Respectfully, Quai Chang Kane
However, in the real world, NANDS are cheap (2-3 transistors), so that's what everyone uses.
Well, NANDs are easy to make with MOSFETs or vacuum tubes.
But I suggest that, in order to simplify the learning of digital logic and avoid this whole nastiness of DeMorgan, we should adopt relays as our primary logic device.
Think about it: two relays with their contacts in parallel = OR. Two relays with their contacts in series = AND. A relay with normally-closed contacts = NOT.
In this way, all design work can be done with natural logic (AND, OR, NOT) rather than "efficient" NAND, NOR, etc.
On top of that, your computer would make satisfying clicking sounds reminiscent of a pinball machine's scorekeeping system or an old elevator contoller, while you're crunching SETI@Home units.
I'm building a 4-bit binary full adder with nothing but relays in order to demonstrate their sheer computing power, and was hoping that someone could write me drivers to allow it to have practical uses.
Fire and Meat. Yummy.
That was in 1965 and the unit was the only one for our whole school district and worth about $30,000 (CDN - about $35000 US at the time)
From there to today's Object Oriented Programming languages has been an interesting time. I wouldn't have missed it for anything, and I honestly think that living through it has given me a perspective that many more recent programmers don't have and IMHO need, sometimes.
Where "brute force and ignorance" solutions are practical, there is no gain in knowing enough about the underlying hardware and bit twiddling to make things run 1000% faster after spending 6 months re-programming to manually optimize. In fact, since (C and other) compilers have become easily architecture tuned, there really are few areas where speed gains from hardware knowledge can be had, let alone made cost effective. Most are at the hardware interface level - the drivers - most recently USB for example.
If you're happy with programming Visual Basic and your employer can afford the hardware costs that ramping up your single CPU "solution" to deal with millions of visitors instead of hundreds, then you don't need to know anything about the underlying hardware at the bit level.
On the other hand, if you need to wring the most "visits" out of off-the-shelf hardware somehow, then you need to know enough to calculate the theoretical CPU cycles per visit.
Somewhere between these two extremes lies reality.
Today I use my hardware knowledge mostly as a "bullshit filter" when dealing with claims and statistics from various vendors. I have an empiric understanding of why (and under what circumstances) a processor with 512 Megs of level 1 cache and a front-side bus at 500MHz might be faster than a processor with 256 Megs of L1 cache and a 800MHz FSB and vice versa. Same thing for cost effectiveness of SCSI vs IDE when dealing with a database app vs. access to large images in a file system (something that came up today with a customer when spec'ing a pair of file servers, one for each type application)
Back in the mid 70s I dealt with people who optimized applications on million $ machines capable of about 100 online users at one time. Today I deal with optimization on $1000-$3000 machines with thousands of 'active' sessions and millions of 'hits' per day. Different situations but similar problems. Major difference is in the cost of "throwing hardware at the problem" (and throwing the operating systems to go with the HW - but then I use Linux so not much of a difference ;)
Bottom line is that understanding the underlying hardware helps me quite a bit - but only as a specialist in optimization and cost-effectiveness now, not in getting things to work at all as in the past.
Been there, done that, paid for the T-shirt
and didn't get it
I ended up teaching introductory Pascal back in the late '80s and found it to be useful only for teaching programming concepts but useless for teaching the students about how computers actually work. As an alternative to Pascal, I would choose FORTRAN over C because its possible to introduce students to things like internal representation without getting them tied up in their shorts over things like pass be reference vs. pass by value, pointers, etc. If C is bad, assembler is worse because the students will more likely get bogged down in nuances of assembly syntax. Also, if someone simply wants to learn how to program in C, I would suggest they buy "C for Dummies" and knock themselves out. On the otherhand, if someone wants to learn about how a computer works while at the same time being introduced to programming skills, debugging, etc., I'd go with something like FORTRAN as the teaching language.
The goal of a first "computer science" class should not be to merely teach technical skills (programming, debugging, program design) but to also give the students an understanding of how computers work. Even with today's proliferation of home computers, most people (student or otherwise) have utterly no idea how a computer works internally since their exposure is limited to simply installing software someone else wrote. Assembler is too far on the side of "how the CPU works" without giving the student any better insight into how the whole system actually operates (memory, CPU, storage, peripherals, etc.) than a higher level language while requiring much more effort by the student to accomplish anything useful. This would seem to indicate that a second generation language such as FORTRAN (or C) would be more likely to let the course delve into programming, machine operations, machine organization, etc. It also means that the students can produce "interesting" programs fairly early on which will keep more people interested (which would you rather have: a PHB MBA with no programming classes or one that has at least sat through enough classes to have some understanding of what goes on inside the box and how difficult that can be to accomplish).
One other complaint against assembler as an introductory teaching language is that, depending on the specific assembler, it is usually difficult to see the overall program structure even after the program is complete. This is primarily due to the low implementation level that leaves simple program controls (if-then-else, do-for, do-while, etc.) burried in the assembler syntax of loading and testing registers and smeared out over what is generally multiple individual statements. The student *may* end up with an appreciation of what it involves to implement these structures but will loose site of the tree (control structure) and never even notice the forrest (overall program design).
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Why don't we just learn to code in binary? If we really want to get to know the computer, then binary is the only way to go... Computer Science is as much about computers as Astronomy is about telescopes. While knowledge of assembly would be useful, I don't think it is absolutely necessary. I know that several CS professors at my university don't even know any programming language, because it's not what they really do. They write algorithms to solve complex problems more efficiently. If learning Assembly helps with that, then fine, but I don't think it's absolutely necessary for CS. Now engineers, that's another thing...
I've always liked the method I learned to program and have communicated this to others.
Here it is:
1) Basic (of the applesoft variety to be specific) This language teaches the basics, ordered execution and program flow
2) Assembly (the 6502 variety in my case) This shows you what the processor is actually doing when you use functions like print.
3) C/C++/Java/etc These higher level languages provide time saving libraries and remove a lot of tedious manual register management allowing easy creation of useful programs.
4) Profit! (I haven't made it here yet)
I believe that jumping straight into assembly would be too daunting for most people, and basic provides a nice introduction into programming in general. Assembly is necesary, with out it you don't know what C (or whatever language) is doing when you use pointers, structs, malloc, etc.
I use to say "Real programmers code everything in assembly!" The thing that blows my mind is that, with many newer processors, the compiler knows more than I ever will about the processor and can take advantage of all kinds of quirks due to the internal architecture to produce better code than I ever could without studying the internal design of the processor. Just knowing all of the instructions isn't good enough anymore!
This strategy generally works better for Computer Engineers rather then Computer Scientists because what you are really learning with Assembly tends to be how the hardware functions. In fact if you are going to learn assembly, you could spend just another month and learn the basics of computer architecture. I feel like that is what really helped me de-mystify the computing process: the ability to trace back all the way to elementary physical processes, and see the computer as a almost a physical entity rather than a magical black box.
For an example of this, you can see Patt and Patel's "Introduction to Computing Systems:From bits and gates, to C and beyond." I took and TA for a course that uses this book.
-ashot
Although unheard of today, this concept isn't really all that new -- there used to not be much choice in years past.
Well, it's actually still done today. While most CS1 programs use a high level language like Java, Scheme, C++ or (less common) Pascal, Yale Patt and others have text books, commonly used, that use assembly. There's a community of CS educators that advocate what's called the "machine model" of learning--starting with bits and gates, and working up to assembly.
But in the slashdot "learning via google" community, this point is probably lost on most people.
If you want to learn more, visit his web page: http://www.ece.utexas.edu/~patt/
Ok, I can make my way through a couple different assembly languages, but I'm missing something important.
Every program you write is run inside the operating system, right? So how does an OS switch between all those tasks if it seems like you're intimately working with the hardware? You put something in a register, well what if a new task comes along and want's to use that register also?
Is everything virtualized from the kernel, sort of as if the kernel is the machine? How do you differentiate between accessing kernel memory and accessing virtual memory?
Also, doesn't the operating system implement the RTS and other basic features? If you're programming a kernel, do you not have the RTS available?
I think that all these questions are related. Would someone please enlighten me?
Social scientists are inspired by theories; scientists are humbled by facts.
No one would really call the PDP-11 a CISC machine. You might call it a RISC VAX however (pause for audience laughter).
Also, many PDP-11's were random logic and not micro-coded. The later 11's were microcoded, of course, the 11/60 being the extreme because it had a writeable control store that let you define your own micro-coded instructions.
It's important to remember that the entire RT-11 operating system was written entirely in MACRO-11 by some amazing software engineers who knew the PDP-11 instruction set inside and out. The result was an operating system that ran very nicely in a 4K word footprint.
The VAX had a terrific compiler, BLISS-32, which created amazingly efficient code; code no human being would ever create but fantastic none-the-less.
...I actually got my first taste of machine language programming as a kid on the...
? ma sterid=12&cartid=12
MAGNAVOX ODYSSEY2 Game Console (complete with sync-sound action and lots of exclaimation points!)
OMFG. It was called, "Computer Intro." You had one line of 8 characters to program on, one 8 character line to use as a display. Basically, you could animate a few characters and make it 'buzz' annoyingly.
Incredibly primative, but it did in fact teach me the basics of assembly. One quote I remember from the manual referred to how 'microprocessors might someday fit as many as ONE MILLION transistors on ONE CHIP!' Heh.
More info here:
http://www.classicgaming.com/o2home/db/cart.asp
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."
Afterward a cute Pembroker in a really short skirt came up to introduce herself. I don't know if she agreed with our argument, but she's been my wife for quite awhile now. I don't teach much any more, but when I teach beginning CS, I teach assembler. The students we taught machine programming to back then have held positions like VP at Microsoft, CS Department Head at MIT, Princeton, Washington, UNH, and Waterloo.
I wish people wouldn't keep referring to C as a "programming language;" it's a pathology.
That set needs a 307 to be complete.
the growth in cynicism and rebellion has not been without cause
anyone ever try writing asm with debug.exe?
now that was fun
ender-iii
I don't know if your submitter knows any history at all, but for me, circa 1989 - 1991, we learnt IBM 370 machine architecture and Motorola 68000 assembly language for two first year subjects. Nearly useless then, and completely useless now. So it's not a new idea, and in fact, it's a complete and utter WAFTAM.
... a bit. By unrolling the stupid hand assembly and getting rid of the "register" hints in the code. That made it go about 20% quicker. Then I unrolled a hand rolled up loop because someone thought they knew how compilers and assembly worked on a wide buffer. By simply making the instructions simple, gcc managed another 20% then and there because it understood what the code was SUPPOSED to do rather than what someone thought gcc might do. Then Klamer Schutte came in, and rejigged the gamma table lookup code and shaved more than 97% off the 40% faster execution time in return for 4k of memory in a look up table. Simple algorthmic improvement - and no assembly.
Learning good software engineering skills, working with peers, and instill a desire for continuous lifelong learning is far more important than being tought a ridiculously low level representation.
Just as you get to know x86, and it'll be obsolete as you should now know x86-64 extensions, or an embedded instruction set (gasp!). If you are really going to do embedded stuff, you should learn the PPC instruction set (this week) as IBM's 400 series embedded processor rules the roost or Intel's (ex ARM) XScale instruction set for PDAs.
On some ISA's, hand coded assembly has NEVER been faster than the C compiled variant. On Pentium III and 4's, you need to know how to fill the two integer ALU's and order instructions properly to prevent stalling. You as a human are too mentally puny to do this properly. More to the point the time you might be able to achieve by hand coding something is better spent looking at the algorithm. You might be able to save 30-80% off the overall execution time if you spend your time properly, rather than a few nanoseconds here or there.
For a hard example, I sorta maintain Pnm2ppa, the HP print driver for HP's lamest printers. They print the bit pattern under the head at the time, and they're incredibly dumb. pnm2ppa is a master work of reverse engineering done by a few others, but I optimized it
So it's completely a useless skill. For the average CS major (not engineering major), do not waste your time on assembly.
Instead, learn five or six languages to reasonable competence, and two well, and master one. This will stand you in good stead if another language or framework comes out and becomes the defacto commerical tickbox (C-> C++ -> Java -> C# for example). Don't learn COBOL unless you want to maintain bank software.
But most of all, learn how to project manage and write documentation. These are a real world skills you can use to kill off projects you don't want to do, or at least make a go of them if you are forced to do them.
Andrew van der Stock
(And yes, I agree, knowledge of Assembly does give you better fundamentals, even if you only use it occassionally. However, I can appreciate why people don't want to write 25 lines of assembly to achieve the equivalent of 1 line of C.)
They say the first thing to go is your penis. Well, it's either that or your brain. I forget which...
I graduated from an accredited 4yr with a degree in Engineering. Can I call my self an Engineer. NO. I would still have to pass the EIT (Engineer in Training Test), then work for at least two years in Engineering and then I would have to pass the PE (Professional Engineer). Only then could I say that I am officially an Engineer, and this is the "fast track" in the US.
Those in CS seem to think that all they have to do is get a job writing HTML and they should put Engineer in their title.
Don't get me wrong, I know a lot of people in CS who I would consider Engineer quality. It just annoys me, all of the "Software Engineers" who are reducing the reputation of Engineering.
If you want to be considered a Software Engineers then you should have to pass certain standards created by a group of professionals. The schools need to be inspected by these professionals to make sure that they are teaching to certain standards.
In the same breath, I do some programming, enough to impress those who don't and enough to know when the CSs I work with are blowing smoke. Do I pawn myself off as a CS. Hell No! I am realistic about it. I know some CS who should be considered Engineers of the field, and others while they claim to be Engineers write code so bad that I can see the bugs.
You joke, but the SATURN CPU is very educational, AND available. But I recommend you get the special cable for PC hookup, for obviously the keyboard and screen aren't programmer friendly.
An excellent course taught in Carnegie Mellon University is "Computer Systems: A Programmer's Perspective" - CS:APP or 15-213, the course number by which it is better known. A better way to put it is that they are teaching computer systems and not computer science, which by definition is much wider in scope. A book based on this course, (which is immensely popular among CS and ECE majors here) is also available. Check it out at http://csapp.cs.cmu.edu
not teaching a coder how to program in assembly lang. is like teaching a student how to read by by having the student listen to books via audio tapes
As someone with MSCS and experience of knowing 4 different Assembly languages, I think students need to be taught Assembly. The key is chosing the best moment to do that.
This moment is defined by the GOAL: teaching the students to write efficient programs.
In my opinion, Assembly should be studied AFTER students study:
1) Algorythms and data structures;
2) Procedural programming;
3) OOP and component models.
These things are good to be taught using C and Java.
At the same time, Assembly should be mastered BEFORE the coding style of a new student will be formed (as well as before different scripting languages).
Tigers respect lions, elephants and hippos. Maggots respect no one. (C) S. Dovlatov
Not sure if this is "new" or not, but I'm sure that Donald Knuth's "The Art of Computer Programming" is written in assembly code (MIX). Want to learn computer science? Computer Architecture, Automata Theory, Formal Languages, Compiler Technology, Algorithm Analysis and Math are usually good (required) starting points. The language should not really matter - even the JVM has "assembly". We should teach people general truths, not specifics. What if this "Linux x86" assembly students face a PowerPC? or a SPARC? or sometihng with a different ISA?
When I took programming class in 1977, we started out with a limited instruction emulated assembler language one of the instructors had designed. Then we learned assembler language, and then finally Fortran and Cobol. This forced us to learn the binary reality of the machine, it's data formats and how it actually worked instruction by instruction. I've met programmers in years since who lacked this approach to training, and thier lack of understanding of binary data representation and the assembler code generated by the higher level compilers always keeps them from reaching the highest levels of proficiency. In programming you will inevitably be faced with situations in which a deep level of what is happening at the assembler and binary level will aid you in solving a problem. It's what separates the good programmers from the excellent programmers.
... Forth.
Tigers respect lions, elephants and hippos. Maggots respect no one. (C) S. Dovlatov
"(But understanding how assembly instruction sets work, and how compilers work, are both useful for writing better code at the compiler level. Less so now that optimizers are really good - but the understanding is still helpful.)"
Slightly OT, but are there any XML optimizers? Specifically SVG.
No one would really call the PDP-11 a CISC machine. You might call it a RISC VAX however
/96 or something - that was also microprogrammable, you never really heard of one, ever.
I've always held RISC to mean "executes an instruction in a single cycle" and the PDP-11 cpu's did not work that way. The instruction set was no more reduced than any other 16 bit minicomputer of the time, it was just more powerful, sensible and orthogonal than anyyhing else.
Also, many PDP-11's were random logic and not micro-coded. The later 11's were microcoded, of course, the 11/60 being the extreme because it had a writeable control store that let you define your own micro-coded instructions."
All PDP-11 cpu's other than 11/15 and 11/20 were microcoded, only the 11/60 had a writable control store and was user microprogrammable. I never saw one - like the IBM 360/84 or
It's important to remember that the entire RT-11 operating system was written entirely in MACRO-11 by some amazing software engineers who knew the PDP-11 instruction set inside and out. The result was an operating system that ran very nicely in a 4K word footprint.
RT11 was awful and made Z-80 CP/M look advanced. RSX-11M was another story but by '76 pretty much every PDP-11 at a university was running UNIX while very few if any in industry were, they used RSX-11M or RSX-11D. RT11 died out pretty quick when RSX-1M became stable around '77.
Fitting in 4K wasn't a big deal, by the mid 70s 16K was still considered pretty minimal and most machines had more, like 128K an big system might a total of say 90K used by the various tasks running in your average "big" application.
Need Mercedes parts ?
For what it's worth, they don't use just NANDs in cmos chip design in the real world. The primary primitive is the AND-OR-INVERT (AOI) structure.
In the cmos world, pass-gates are much cheaper than amplifying gates (in the size vs speed vs power tradeoff), although you can't put too many pass gates in a row (signal degradation). So in fact MUX (multiplexor to pass one of the two inputs using the control of a third) and XORS (use input A to pass either !B or B) are used quite a bit.
Some background might be helpful to think about the more complicated AOI struture, though...
In a cmos NAND-gate, the pull-up side is two p-type pass gates in parallel from the output to Vdd (the positive rail) so that if either of the two p-type gates is low, the output is pulled high. For the pull-down side, two n-type pass gates are in series to ground so both n-type gates have to be low before the output is pulled to ground. This gives us a total of 4 transistors for a cmos-nand where the longest pass gate depth is 2 (the pull-down). The pull-down is restricted to be the complement function of the pull-down in CMOS (otherwize either the pull-up and pull-down will fight or nobody will pull causing the output to float and/or oscillate).
A 2-input NOR gate has the p-type in series and the n-type in parallel (for the same # of transistors).
Due to a quirk of semi-conductor technology, n-type transistors are easier to make more powerfull than p-type so usually a NAND is often slightly faster than a NOR (the two series n-types in a NAND gate are better at pulling down than the two series p-types are at pulling up in a NOR gate). However, this isn't the end of the story...
Notice that you can build a 3-input NAND by just adding more p-type transistors in parallel to the pull-up and more n-type in series to the pull-down. You can make even more complicated logic by putting the pull-up and pull-down transistor in combinations of series and parallel configurations. The most interesting cmos configurations are called AOI (and-or-invert) since they are the ones you can make with simple parallel chains of pass transistors in series for pull-up and pull-down.
For most cmos semi-conductor technologies, you are limited to about 4 pass gates in series or parallel before the noise margin starts to kill you and you need to stop using pass gates and just start a new amplifying "gate". Thus most chips are designed to use 4 input AOI gates where possible and smaller gates to finish out the logic implementation.
Thus "everyone" really uses lots of different types of gates (including simple NAND and XORS as well as more complicated AOI).
And found out that it was THE best source for learning assembler for me. Almost every other asm tutorial I found on net was for windows. And everything else I found for linux wasn't beginner friendly, I tried to learn it from those sources but simply it was bits and pieces everywhere and nowhere anything comprehensive. So basicly if you use linux as your only OS, and wan't to learn assembler. Then get the book as pdf from savanna.nongnu.org , its practicly your ONLY reasonable source for doing it from material from net.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
I understand that much of C was inspired by that instruction set.
I'm not sure inspired would be the right way to say that. C was invented a shorthand for assembler, in particular PDP-11 assembler. I'm probably just being pedantic but I think it's an important distinction.
We owe a lot to those machines, by '74 UNIX and C were available (barely) from Bell Labs but by the late summer of 76 Dave Conroy at Teklogix in Mississauga, Ontario, had written and made work the only C compiler not written by Bell Labs, which ran under RSX-11M. This became DECUS C, and then gcc.
I worked there between high school and university ; Dave taught me C to test his compiler and must have got all of about $1200 for writing it as it only took him a few weeks. It was of course written entirely in assembler.
Need Mercedes parts ?
The book is free. Yeah he should ave disclosed that he wrote it, but its free
Because the Indian programmers currently eating our fucking lunch, well they took the time to learn assembly language, right? Right?
If you were blocking sigs, you wouldn't have to read this.
there is some irony here somewhere....
I fail to see the causality here. How does "excellent programmers know assembly" translates to "teaching assembly to everyone will make everyone an excellent programmer" ?
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).
I second that. I would suggest ARM to learn assembly. ARM has an elegant instruction set & an nice collection of registers, it is widely used (palmtops, embedded...) and several operating systems (Linux, EPOC/Symbian, RiscOS...) are available.
-- Qu'est-ce que la propriété intellectuelle? It is thought control.
Remember manually typing in assembly or machine language code straight out of Compute! magazine into pfs:write on your double floppy disk apple IIc or e to play the latest video game of the month?
I was 7 when I started doing that.
I have to agree that understanding at least some of the basics of assembly forces you to have a better understanding of how computers work in general. For every 10,000 visual basic programmers, there is one guy out there who could tell you accurately how a computer works.
I'm afraid in 10 years there won't be any real OS upgrades because the current crop of graduates either don't know how to build the basics of an OS, or aren't interested in doing so.
Real progress won't be made until a visionary comes around who can build a computational system more efficient than a large grouping of transistors. That visionary is probably in diapers now, and won't realize the fruits of his labor until most of us have laid down our keyboards in favor of shuffle board sticks.
The best code I ever wrote was when I wrote my own homebrew assembler in Basic (on a Pertec PCC2000 with ROM basic, no other OS). I didn't write a debugger, so the only way of testing a routine was to run it. You very quickly learn to write things RIGHT when any bug means rebooting and starting again!
I wrote a whole CP/M BIOS using that system, so then I had the world's only PCC2000 with CP/M. But more seriously, the code I produced there lasted 8-10 years in commercial packages I produced. With no bugs. Not one.
I'm not boasting: it was the lack of a debugger that did it.
Someone said: "programming in assembly is like shaving with a machete. If you are very good at it, you can get a decent shave; if not... well let's forget about it."
-------- Cluster bombing from B-52s is very, very accurate -- the bombs always hit the ground.
Not only did the submitter hide the fact that he wrote the new book he's hawking, but he's also a homophobe who likens homosexuality to rape, in this article:
When you see someone who is a murderer, a prostitute, a rapist, a homosexual, a cheater, or whatever, God's instructions are to simply view them as people who need Jesus.I know this comment will get lost in the (nearly) one thousand other comments, but never-the-less I feel compelled to call it out.
Assembly languages have been in my CS curriculum's first year (Delft, Netherlands) for years. It was PDP-11 assembler when I started but got changed (fortunately) into PowerPC assembler in '98 orso.
It is used to show the students the inner workings of a computer rather than really teach them the full power of PowerPC assembler, since knowing any assembler language itself is rarely needed in real life.
The inner workings of other programming languages when translated into assembler (function calls, stack, etc) are covered in the second year.
I never managed to do much beyond a few fancy screen scrolls and a very fast encryption program, but in my Computer Studies coursework, I was God - no-one else submitted 6809 assembler listings :-)
Nowadays with gigabytes of RAM and fast CPUs, I believe the emphasis is on easily created and reusable code, rather than the days of 1MHz CPUs and 32K of RAM, where the object was to bum the code into the fastest, smallest possible form. Sad to see it go, really.
When I am king, you will be first against the wall.
How about just..
'start teaching assembly language'
There's lots of 'Comp Sci' students out there that really don't want to learn the basics. They want pointy clicky, draggy droppy and really hate anything like real work (ie a command line).
This is a big problem for the Uk Universities as each module has a point system, and you pass so modules = get a degree.
Alot of students are avoiding programming courses (or any course with programming content), and still get a comp sci degree.
This means the 'programming' course have low numbers and are therefore under pressure to 'close'.
IHMO there should be a core set of courses + a few options, not totally choice based. This means that you HAVE to pass the programming courses the maths courses etc etc.
too much choice makes the world a bad thing, too little is bad too..
There is an amazing concept with Assembly programming: Macros!
Seriously, this difference isn't really all that big if you really know how to use the assembler properly, and with most of the modern assembly languages many of the concepts that you might be familiar with in HLL (High-Level Languages... does C++ count?) like arrays or even objects can be done fairly effectively in assembly as well. It is possible that you are using an underpowered assembler, but the same can be said of a poor compiler.
When I am programming, especially time critical functions even when using HLL, I am very much aware of what the compiler is going to translate that code to in assembly. I had a co-worker who was trying to review a particularly tight routine, so he challanged me to compare the compiler's output with what we would do by trying to do it by hand.
Besides some quirky register usage (which is typical with most compiler designs and a necessary component of designing a compiler) our code was identical.
The point is, like mentioned elsewhere, you really need to know assembler and how the computer archetecture is affecting your code to write quality code yourself.
I guess this is why I am anti-Java and to some extend dot Net (.net) or other similar VM implimentations: They keep adding abstraction that makes you lose sight of how the machine is actually functioning. These VMs have their place, don't make it sound like I hate the entire concept, but eventually you have to understand that individual gates inside a chip on actual hardware must be trying to interpret your code and if you can't translate a line of code down to that level you really don't know programming.
What total rot! Donald Knuth was doing this about 30 years ago. His MIX is an ideal virtual machine carefully honed for its purpose. To teach Comp. Sci. via Assembly code.
While I think that assembler (and in general low-level languages) are neglected now in favor of high-level concepts, learning about a specfic computer architecture is definitely not enough. It is a well known fact, that most times a clever application architecture or algorithm is far more efficient as any low-level optimization (think 'quick sort'). A balanced approach between low-level concepts (assembler, programming on register level, knowing what pointer arithmetic can be good for), datatypes and algorithms and high-level concepts (modeling and higher OO languages) is needed. What engineering teams needs often most, gets sometimes not taught at all: project management, requirements engineering, team communcation, testing (and so on..)
I learnt to program on an ancient aquarius at the age of 9. It was great and my first steps were done in BASIC. I then got an Atari ST and the M68K chip blew e away. I wanted to be "like the other demo crews" so i set about learning. I got pretty far and Assembly language was pretty easy. Once PCs came to the fore i thought "Great! I'll transfer my skills to a mainstream platform". How dissapointed i was to discover that the x86 was a crippled chip with only 4 registers. I know things have changed these days but it put me RIGHT off. The M68K had 8x16 bit data registers and 8x32bit address registers (IIRC). It was a dream to push around bits and have plenty of storage. So has the x86 platform evolved to a better state of afairs (like the good old 1979 M68K?). I certainly hope so, as it would rekindle my love for "to the metal" programming. I'd be interested to hear your comments.
Learning assembler is not about learning programming. It is about the integration of the theoretical basis of serial computing by interacting with its representation in physical hardware.
Of course it may seem difficult and irrelevant. Assembler is not about providing abstractions so you can more easily develop working programs. Its all about the most basic logical operations combined by a programmer to achieve a finite state machine (the program). When you finally have a mastery of assembler, you come to appreciate boolean algebra and the concepts of serial computing. You learn to think as the CPU thinks. You develop a genuine understanding of the nature of a computer and an appreciation of the theory that made it come into existence. It must be like the feeling some physicists had at the turn of the century when they were muddling through general and special theory of relativity and a couple of decades later be able to validate the theories' "correctness" in the a-bomb.
If you go through the trouble of learning to program assembler on more than one architecture you will come to realize that even though all the instructions have different mnemonics, (one CPU will have branch on condition instructions, another will have test and jump on flag instructions, some combination of instructions are more efficient on one CPU but not another -- whatever!) *its all the same*. And that's because the basic theory is all the same, regardless of CPU, or who made the computer.
(This elegance of assembler of course does not apply to Intel CPUs, which incorporated all sorts of horrible kludges in order to add functionality to the CPU. Its the last CPU I'd want to be using for an assembler class.)
I find people's reactions to assembler to be a good sign of the individual's grasp of computing. Those that can't interface with the core being of the machine is better off being a theoretician or go into management.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
You weren't there, and you apparently havn't been reading the comments from the veteran programmers here.
The folks who got started on Apple ][ computers (and TRS-80, Commodore, Atari, etc.) really needed to learn about the architecture to get stuff to work. Memory was measured in kilobytes, and that was only a two digit number at that. Even a typical programmer would eventually write a program that would use the entire available memory space, so you had to be forced into writing more efficient code and doing things that would never be done today with GB of RAM and TB of hard drive space.
One of the problems that I see is that even fairly good programmers that are graduating from CS programs now take for granted that there is going to be lots of memory availble, so they tend to be very wasteful with both memory and CPU cycles. Then they wonder why their software seems sluggish and why the old-timers just about throw up on their code.
Oh, BTW, in regards to who is going to move into management first, yeah, they may be able to impress some CEO if they have lots of flash, but that doesn't mean that some idiot who never really learned computer archetecture theory and became boss really knows what he (or she) is doing. It just means that the Peter Principle is at work. (Do a google search if you havn't heard about it.)
The knowledge of assembler language and the way computers work deep inside can help a lot in designing software, but they often lead to "clever code". I.e. a code which is so sophisticated and so cool, that you as the programmer will be very proud of it. But the pitiable new employee who is assigned to your team will struggle with that code as it turns out to be so clever that no one else will be able to maintain it.
The thing is, I took a course on x86 Assembly in college. We wrote a bunch of assembly programs. I would tell people honestly, if they asked, that I know x86 assembly, but that I haven't used it for years. ( since that class actually ) It would be possible to debug a compiler if you were familiar with the way that compiler lays out code etc. Merely knowing what 'mov eax, 3' and suchlike means is not enough.
int 21h
Eat at Joe's.
I've found that the key difference between mediocre and excellent programmers is whether or not they know assembly language.
You've found it wrong. Learning assembly language is not that great undertaking, and clearly it is not the decisive factor in programmer's qualification. To bend the book's metaphor, knowing how a carburetor works isn't the thing that makes you a good race driver.
Being in the trenches since '97, I find your implication (that such a trivial thing as knowing a few mnemonics and monkey tricks is what determines excellence in our trade) insulting. For heaven's sake, most of CS grads here go through assembly course: it's just as basic as it gets.
Lisp is the Tengwar of programming languages.
90% of the code nowadays have much more to do with the speed of the network between the database or another server and no assembler will really improve that. Algorithms, Caches, yes.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Hmm?
I am very small, utmostly microscopic.
You would access the array using that 'subroutine', so you could forget about the mechanics of the actual dereferencing process. Maybe someone else would have written an nice 10 dimensional array member-access 'function' that you use, so you have no idea at all how the data in the array is stored. This is much the same as someone coding in C who doesn't even know assembly language.
Eat at Joe's.
Sorry - Have recently started working for a firm where that kind of noun-to-verb conversion is commonplace. Must be strong in the face of corporatespeak.
"The new wave is not value-added; it's garbage-subtracted" - Esther Dyson, Dec 1994
Based on the last 20-30 programmers I interviewed, I think teaching assembly language is a great idea. One of the questions I ask in the interview just to weed out the posers is to whiteboard how each type of number (int, float, double, etc...) is represented in memory. Then I ask them how a simple string is handled in memeory (c or c++ style). Anyone who can't show me confidently is confidently shown the door. Last time it cleared 8 out of 10 candidates.
-- $G
Assembly language poised for a revival? Wow, next thing you know people will discover how to emulate the working of a comuter using nothing but pen and paper.
No, i was serious.
Though i never said they couldnt also get a 'pc', but they should *Learn* how to do it the right way first.
I detest 'appliance' types that think they have a clue.
---- Booth was a patriot ----
My point wasn't that you had to know how things actually function to drop and drag and pretend you are a programmer, or IT guy or 'leet hacker'.
My point is you have no clue unless you do, and you have no right to call yourself, anything other then a moron.
Most of you people wouldn't recognize the details if it bit you in the ass. And personally the entire concept of the knowledge loss that is occurring ( and the arrogance of those that don't have a clue ) sickens me.
---- Booth was a patriot ----
Yeah like morons that like to call ::toupper() Clib functions, rather than use a macro in a loop.
100000 calls to toupper() will thrash the stack/cache, and be way slower than a pure optimized smart macro inlined.
No clib funcs get inlined, face it.
No wonder some peoples code can be 50% slower but barely look any different than a good coders code.
Things cascade , and bingo, you get an application which is 3x slower than a good implementation.
Like someone said, software is years behind hardware engineering, perhaps more software programmers should know more about hardware.
No wonder some hardware engineers think of software engineers like software engineers think of managers.
Liberty freedom are no1, not dicks in suits.
I can't disagree more strongly.
Higher level languages should be taught first (preferably an OO and a Functional language followed by a logic language to gain an overview of different paradigms)
Assembly language should be taught in conjunction with a study of hardware and its design.
There is very little need for assembly level programming with today's optimising compilers, time would be much better spent learning about algorithm design and software engineering.
Infact, it is much more useful to learn the principles of computer science (ranging from programming and hardware principles to theory) which can then be applied in many different areas than the specifics of a small area which is of little use outside that area.
I also don't see how assmebly language helps you understand the internals of the processor and the design choices made, assembly language is an abstraction layer.
Efficiency is also not gained through assembly level programming, but through good software design, engineering and the right algorithms and datastructures.
I was very tired when I posted that stuff last night. I *meant* to say NOR, but I said XOR (in 2 different posts, no less)
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
I've been comtemplating engineer students who learnt high level languages and still don't understand how parameters are passed on the stack, or how pointers work. That's so depressing. I begin to think the bottom-up approach is the only valid one.
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.
Anyway, OO is yesterday's buzzword. There are times when it's the only sane way to go, and others when a different approach would work as well. Probably everyone who understands OO has at one time been somewhat of an OO fanatic. But although it's a useful tool, there is life beyond OO.
People who don't know assembly often associate it with some kludger that, although they may be expert at obscure details of often obsolete technology, writes unreadable and unstructured code because they somehow can't resist obfusticating things with some special 'secret' non-portable 'performance enhancing' trick. This hypothetical kludger likes to apply their very limited knowlege of assembly to problems it is best left out of in an attempt to impress the younguns whose knowlege may be completely nonexistant.
This association between kludgy programmers and assembly is 100% BS. If anything, assembly is MUCH LESS forgiving than other languages of programmers with bad habits about structuring code. While most other languages provide things ( like subroutines ) that tend to provide structure in a standard way, the assembly programmer has no compiler to enforce this. The assembly programmer has only their own habits and comments to enforce structure and readability. If you can write good readable assembly, then your skills at structuring code can survive in any environment. If your assembly programs work, then they are structured. If they are not structured, they do not work, or they appear to but have serious bugs.
For the OO fanatics: OO does not conflict with asm. Remember that OO languages compile to an assembly representation.
In the same way that an assembly programmer might define subroutine-like goto labels that expect a pointer to some parameters to be passed in a certain standard-throughout-the-program register, one could, ( and compilers do ) define objects in some standard way in assembly.
Learning assembly teaches you the wisdom and value of all the helpful features that a higher level language provides. To get anything sizeable accomplished in a readable and relatively bug free way in assembly, you end up implementing those high level features yourself by convention.
Assembly teaches that good coding style does not need to be enforced by the language ( it really can't be ), it comes from within the programmer. The helpful features of high level languages hint at some good ideas though. The enforcing of certain style rules can be a check against typographical errors, but it can not make a bad programmer into a good one.
Perl also doesn't legislate or enforce things. It gains the power of flexibility, while providing high level features to those who can appreciate and use them. You can write really awful Perl code because of this, but you can also write really beautiful Perl code because of this. It depends on you.
Eat at Joe's.
Assembly language is one of many tools that programmer can know and use in their craft. Whether you need to know assembly depends primarily on what kind of programming you are doing. It certainly helps if you work on kernal code or device drivers, but isn't likely to give you a huge edge if you work primarily on business applications written in Java.
Knowing how the computer works at a fundemental level is not nearly as important for a high level application programmer as writing code that can be clearly understood by those who have to maintain it. "Wizard" code can be difficult to understand and nearly impossible to maintain. It's best used where it can do the most good, in low-level and/or high-performance areas.
Most compilers already turn out far better assembly code than can be written by the average assembly programmer. This is the result of more than thirty years of work on optimization research that has been built into modern compilers.
If you really want to hit high performance, though, knowing assembly is not enough. You also have to have a detailed understanding of how the target chip works, the sizes of it's L1 and L2 caches, how branch predictors, byte-order, and lots of other details.
When it comes right down to it. I think that all programmers should have some exposure to assembly, but that an application programmer's educational time is better spent learning how to refactor than how to write clever assembly language. It's kind of painful to say this, since I was weaned on Z80 assembly, but I don't think my knowledge of assembly language helps me greatly when working on my Java application code.
-All that is gold does not glitter - Tolkien
www.ra
I learned assembler first myself, although I'm of a somewhat newer generation (27 atm) than older programmers who were forced to. I think it's a big help for the same reasons stated, and I've noticed too that the best programmers I know are people who, like myself, know assembler. Of course you need other things too :), but it's a good start.
You can even take this a step further and say that before one learns assembler, one should learn basic electronics, both analog and digital. You don't need to go so far as designing microprocessors - but at least far enough to build little logic and timer circuits from standard TTL and CMOS ICs, perhaps advancing from that towards building circuits around a PIC microprocessor and writing asm code for the PIC to control little hardware devices.
Then do x86 assembler, preferably without a real OS in the way (e.g. MASM/TASM under plain old DOS without using MSDOS interrupt functions, or even BIOS ones if you can help it), then graduate to using assembler and C both seperately and linked together under a protected-mode OS where one must use system calls (ala Linux like the book), and then move on to regular C/C++ coding without doing anything in asm unless neccesary for speed (which is very rare), and THEN, PERHAPS, if the situation warrants, or other things (available contracts, stupid corporate policies, etc) require, you could learn ugly languages like Java and code in them.
11*43+456^2
Taking a course on compilers is probably the best way to improve your programming skills. You will learn exactly how your high level instructions map into assembly. Especially if you cover optimizations, you'll get a much better idea of how to write efficient code. Secondly, a course in modern chip design can be very useful so you know about how caches, branches, etc will effect your code.
Is Jeff Duntemann's Assembly Language Step by Step, I have the original edition from 92' and it appears there's been a revised edition that covers some Linux. Whats nice is that he has always taken the approach that it is your first language to learn, and he does a great job of laying it all out in very layman type terms. I still have that book and it will be one that I always keep around.
Sehr geehrter Toilettenbenutzer!
Knuth has been teaching CS using ASM for a *Long* time.
*shrug*
A lot of people have enough trouble figuring out C/C++ when they start programming. Starting out teaching assembly would turn a lot of potential computer scientists away in frustration before they ever get a chance to get a feel for what they would really be doing (which would likely be using a higher level language, and not assembly). The computer science program I am going through right now includes an assembly language class and a more advanced class that follows up and teaches more about the basic machine architecture. Based on the reaction of my classmates, the majority of them would have probbaly switched degrees if they had started with assembly.
~Warning!~ The above is encrypted using rot676!
When I was still in school (seems like a million years ago, but it was only about 15 years ago), we only had one assembly language class. That and the two intro courses are the only ones I didn't go to (did the homework, went for the the midterms and finals, got As).
I don't think one semester is really enough assembly language, though. I think people should really have to understnad both assembly language and compiler design, though. I think it's important to understand both, though. As a programmer of a higher level language, you then have a fairly good concept of what's happening to the code you write.
And while I think that's still important now, I don't think it always will be important. In fact, I think over the years, its importants has diminished significantly and will continue to do so.
As an example, when machines were much slower and optimizations far more important, I remember jumping through a lot of hoops to optimize my code so that it would compile more efficiently, or embedding assembly routines for speed. I haven't had to hand code assembly since the mid-90s, though. So it seems to me it's far less important these days simply because machines are so much faster.
and start learning math from calculus. this is why cs students are past ignorant.
Just depends on where you go: el-collegio around the corner for a quick "Computer Degree" coding Java, or a university degree.
i sure as hell know *WE* had to code fs#@%* ASM
The sound of this message makes me guess that johnnyb considers himself being one of those wizzards ;-)
My approach would be -- exactly the opposite -- to teach lisp wich, is as independend of the underlying architecture as a language can be.
As machines are getting faster and faster efficiency by investment of hardware knowledge is getting more dispensable for most of us.
An example that illustrates the overestimation of hardware knowledge very well: When Sun presented its servlet concept, webapps started to be excitingly fast, even though java is considered a 'slow' language. Why was that? Not because they thougt about register optimisation, but because they abandoned the traditional one-request-relates-to-one-process concept (an CGI does it); in other words this improvement was born out of pure software architecture considerations.
I think its quite good for a programmer to know some assembler (maybe java byte code?) but teaching beginners this ugly i386 assembler would be an exaggeration.
Titus v.d. Malsburg
I got my BS in CS at a state university and part of the program included assembly language and computer architecture. I would imagine that any accredited CS program would cover assembly language and computer architecture. It won't necessarily be x86, but the vital concepts will be there.
The first, and so far only, assembly language I have learned was for Motorola 6502 chip which powered the Apple ][+. It is a very compact language and very suitable for programming. Armed with the reference for interfacing with the GUI toolkit (and believe me, the gui toolkit was very basic on the Apple ][+), a skilled bit-munger was capable of rather complex achivements.
I cast my vote in that Assembly Language, for any CPU, is more crucial to gaining an understanding of computers in general that a college degree showing you learned C++.
As an idea of when this was, when I went to college the language of choice was Modula-2. Make of that what you will.
This post encoded with ROT26. If you can read it, you've violated the DMCA. Handcuffs please, sergeant.
As the old saying goes, "Real Men program right down to the bare metal."
I'm currently taking a class for my Computer Science degree that is required. It's a course that includes learning the MIPS assembly language. The course includes basic system design and processor design. I'm enjoying the class and wish that they would offer more assembly classes. This one could be a prerequisite to one with the x86 architecture or others.
r1 += r2
r3 = [bp+3]
It may not be as traditional as other assemblers but it is straightforward to pickup.
Most of us here are acquainted with the Jargon File, I suppose.
There is always something to be said for understanding the native language of a CPU. How can there not be? You can put it down all you want, but someone has to write the code generator for each processor. There's also much benefit from writing domain specific languages. Contrary to popular opinion, writing a compiler is fairly straightforward undergraduate project. Anyone who thinks otherwise should be ashamed to be in computer science.
But let me rewind a little.
The entire point of language design, compilers, and so on, is to make programming cleaner and more reliable. Assembly language is not an ultimate goal. Neither is C++. Learning PowerPC or x86 assembly language does a good job of explaining how those architectures work, which is not necessarily a good blueprint for the future (in the case of the x86, doubly so). This is much of the reason assembly language for popular desktop processors has fallen by the wayside. x86 assembly language is more of a mid-level language, with the processor using a huge register file behind your back and reorganzing instructions on the fly. You don't have the ultimate control, which used to be one of the primary reasons assembly language was interesting. Now you have a patched-up and ugly architecture with implementations that have been tweaked and twaddled into performing well for certain types of well-behaved applications. You can break things fairly easily on the P4, such as by putting code and data in the same 1K block, or by performing simple return stack manipulations that cause the branch predictor to fall down hard. It's all very dated and byzantine and ugly.
A better method is to design an architecture for more specific needs, one that isn't trying to be the giant 1970s C machine. Keep it clean. Keep it specific. Keep is reasonably small. This makes assembly language meaningful again, and worth knowing. For example, Ericsson prototyped a processor for their functional, concurrent language, Erlang (which is used to run many of their telephone exchanges). At 20MHz it was outrunning their damn-fast interpreted implementation on a 500MHz UltraSparc--by a factor of 30. This is where the future is. Figure out what you want to do. Once you've implemented it in software, iterated it a bunch, and nailed it completely, put it in hardware. And then there's much to be had in knowing how things work all the way down to the metal. But for modern desktop processors, no, there isn't much point. It's all too soft and vague and complex and meaningless.
I.e. Destination = Src
It's the 68000 and ARM that got it wrong by doing things the COBOL way (MOVE src TO dest). Pah. And they got the high bytes in the wrong locations goddamnit, so that a value is different depending on its type (and multi-unit arithmatic is less sensible).
sydb: I am a pedantic twit.
;)
Paolomania: I am a bigger and more pedantic twit.
sydb: I am the biggest, most pedantic twit that ever was and ever shall be. Do not meddle in the affairs of big pedantic twits, for they are subtle and quick to anger.
theghost:
The only thing necessary for the triumph of evil is that good men do nothing.
Anyway, at best you demonstrated poor judgement. At worst, it was a deliberate deception. I don't know you, so I don't really have an opinion.
Now, regarding teaching assembly language programming:
I don't know what planet everyone else studied on, but my Computer Science curriculum (I studied computer science for a while after earning a B.A. in Philosophy) required assembly language programming. Our software emulated the Z81 and ran on NeXT workstations. The introductory programming course was in Ada - which is a underrated language (switched to Java later). C was also required (and fun).
Ladies and Gentlemen of the Slashdot community... Code in C.
/opt directory thinking it to be "optional" while trying to make space for his porn collection, or a lethal bug in your fancy CASE tool.
If I could offer you only one tip for your future as programmers, C would be it. The long-term benefits of C have been proved by scientists, and academics, and professionals, and corporations all over the world, whereas the rest of my advice has no basis more reliable than a Microsoft marketing report. I will dispense this advice now.
Enjoy the power and beauty of simple command line tools. Oh never mind, you will not understand the benefits of vi, make, grep and gcc until you're working as a contractor, and that fancy environment you have at home isn't available. But trust me, in 5 years, you'll sit down in front of an expensive IDE, pore over the GUI menus and checkboxes, read the badly written two-inch-thick manual twice, and still not be able to write a program to say "Hello World!" You'll then recall in a way you can't grasp now, the importance of understanding how to get useful work done with the standard, simple tools.
Don't worry about not using the latest and greatest Microsoft tools or language; or worry, but know that worrying is as effective as watching all your carefully crafted code fail because a registry setting or dll you depend on was changed by the installation of some do-nothing program. The real troubles in your programming career are apt to be things that never crossed your worried mind; like a middle manager who wipes out the
Write one script every day to aid you.
csh!
Don't be reckless with other people's test procedures, don't put up with people who are reckless with yours.
Lint.
Don't waste time on hand-optimizing your code; sometimes you're elegant, sometimes you're a kludge... The optimizing compiler will do it better anyway, and in the end you'll have to maintain the source code - so keep it readable.
Remember the useful code snippets you receive, forget the cruft. If you succeed in putting together an elegant an efficient source "proverb" library, send it to me.
Keep a logbook of your programming efforts. Toss your core dumps.
Top.
Don't feel guilty about not following a particular development methodology completely. The most useful programs I've seen have been cobbled together ad hoc. Projects I've seen follow the Rational Unified Process, Extreme Programming or Aspect Oriented Programming methodologies to the letter, dies over budget and behind schedule.
Get comfortable with revision control.
Be kind to your O'Reilly books. You'll miss them when they're gone.
Maybe you'll become famous, maybe you won't, maybe you'll win the Turing, maybe you won't, maybe your codified soul will be ignored sight unseen, maybe you'll crank out the next Mosaic... Whatever you do, don't congratulate yourself too much or berate yourself either - the commercial success of your program depends more on the whims of lawyers and marketing drones than on the technical merits of your application or the effort you've put in. So does everybody else's.
Enjoy your home computer, use it every way you can... Don't just use it to hack away at code or to automate your bedroom lights or to run a website, it's the greatest tool for self-expression you'll ever own.
Learn... even if you have nowhere to do it but from a weblog forum. Read the responses, even if you don't agree with them. Do NOT read Ziff-Davis magazines, they will only make you feel like a long-haired, smelly zealot.
Get to know your kernel, you never know when you'll need to recompile it yourself. Be prudent about your patches, they are the best trace of development and the means most likely to keep you safe and relevant in the future.
Understand that CASE, GUI and other developer tools come and go, but for the precious few you should truly know. Work hard to bridge the gaps between convenience and uti
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
As a former college lab instructor, I have a lot of experience with CompSci students that don't understand how a computer works. Some assembly language would have helped, but it's not the only solution.
... in other words, build a peripheral and write a driver. The lab used a combination of C & assembly code.
... then you end up with bad code (too big, too slow, large memory footprint, etc.).
... it's to understand the computer at it's lowest and most fundamental layer. If you don't think it makes a difference, go check out the educational background of the average Indian programmer.
I used to teach a lab at Clemson University for Computer & Electrical Engineering students (ECE371). Students built a piece of hardware for the ISA bus, then wrote software to control the hardware
Assembly Language was a pre-requisite for the ECE students, but CompSci students could take it without the pre-requisites. In general, I had to spend more time explaining basic concepts like input & output to the CompSci students than the ECE students.
Most of these students had no exposure to assembly language of any form (RISC or CISC). The inner workings of the processor were described in general terms, but they had no practical knowledge.
The industry trend in firmware development is away from assembly, moving to something like C that is abstracted from the platform. This is good because it requires more 'general' programming knowledge, but it can backfire if the C programmer a company tries to convert to a firmware/embedded developer doesn't understand how the computer works
The point of learning assembly isn't to know assembly
this is completely appalling! object oriented programming doesn't care about the machine it runs on, only a functionally (including object based as most people attempt to create object oriented programs) cares about the way a computer thinks. we need to break this habit, and it starts with those who start learning programming.
Assembly Language Step by Step is an excellent source for beginners who want to understand the concepts of Assembly.
Have you read my journal today?
Knuth's "Art of Computer Programming" uses a fictional assembly language written especially for the book!
Has any of the /.ers read this book? I would like to find out how those who have read it would rate it,as far as depth and subject matter.
/.ers could recommend would be apreciated.
I am very interested in learning ASM, but I need a good reference. I know some ASM via HLA, but I want to take it further. Any books that
"Oh no theres another bug."
"Shut up! We'll tell them it's a new feature."
I am Bennett Haselton! I am Bennett Haselton!
Now, if only we could get these paper mills to stop teaching the answers to certification tests and start teaching how everything works we might have some IT people out there who are capable of doing a job.
I've known too many people who come up with the oddest shit because they just don't understand AT A DEEP LEVEL how a computer works. They're users who got a slightly deeper understanding, but that's it. When I went to get my degree. You learned how the computer worked by starting with resistors and capacitors before moving on to digital circuits and eventually processors. It was only after you understood how a processor worked that you learned assembly programming, and only after you learned assembly did you learn higher-level languages.
What an ideal world IT would be if there were more people who knew what they're doing....Sigh, a dream never realized, I suppose...
Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
I studied Computer Science at the University of Michigan and recently graduated. My curriculum there was overstressed with the hardware level. In some ways it was very valuable to understand the underpinnings of hardware and be able to translate that into valuable knowledge for programming well in a high level language. However I felt my education was spread too thin. My goal was to come out of college as a software engineer. I feel utterly lacking because I believe too much emphasis was put into the hardware side. I encourage anyone who is going into a Computer Science program at a University to closely examine the curriculum and see how well it weighs with their goals for after college. College is expensive! Don't pay for something that doesn't give you what you need.
Gaining a good understanding of the internals of the computer may not be the most useful thing for a new computer scientist. Teaching data structures and algorithms (sorting, binary trees etc) in assembly would be impossible. Assembly would still be useful perhaps but would not always make a computer scientist better. There's so many things like databases and AI where the conventional perhaps introductory material would be more suitable. For myself however I have to say that I would be interested into gaining a deeper understanding of the actual machine throguh assembly.
We learned to program in Hex on punch-paper tape. Only after we knew what we were doing could we move on to Fortran on punchcards.
And yes, we also had to walk 12 miles through the snow to school. Uphill. Both ways.
The closer you are to the code, the happier you are. - Ancient Geek Proverb
Its why IT is in such sad shape today.. The people who were really interested in computers/tech took engineer or CS in university... The other group, who are just here for a job, did history or religion in University, realized they have no marketable skills and went to some overpriced IT-farm. They have no real interest other than getting a cheque every two weeks. They don't really understand or care about what they are doing.
Yes, i'm making a rather blanket statement but i'm getting stick of having to put up with this crap. But from what I have seen, these IT-mill people are good for very junior positions. And yes, there are some exceptions to this, but these people are genuinely smart and could pick up anything they wanted. There aren't too many of these people around tho.
Sorry, but I have had to clean up other's messes too many times. I'm sure most other _real_ IT people would agree with me.
"Thanks to the remote control I have the attention span of a gerbil."
I think we're muddling a few issues here, thanks to the lack of distinction in much of academia between computer science and software engineering. Just as I would not reasonably expect a Physicist to be a bridge designer (Mechanical/Civil Engineering), or circuit designer (Electrical Engineering), I would not expect a Computer Scientist to write software. A Computer Scientist is concerned with the theory and science of computation-algorithms, data structures, number theory, language research, and the like. They're the folks who are working out the theory on how something we may not see implemented in 30 years functions.
Really, we need to understand that there is software engineering (the folks who *design*, develop, and maintain software) and software science (what we call Computer Science). For software engineering, I believe it is fundamentally important to understand languages at as low a level as assembly, and as high a level as Prolog and the like. I have seen many poor design and implementation decisions made in professional code that would not have been made if the developer understood what was happening under the hood-or if they were aware of a higher level tool that would cut their development time dramatically and simplify their codebase. To be a good software engineer, you have to understand these things, and be able to judge the time to use a given tool. If you don't, you're doing a disservice to yourself, your employer, and your profession.
Now, I know there has long been an issue that (at least in the US, I don't know about other countries) there is no legal definition of what a software engineer does, or what qualifies a person to hold such a title. That's something we will need to change and address in this profession. The reality, though, is if you design and write software for a living, you really aren't a computer scientist-you're a software engineer.
Having read code from many other programmers and having interviewed scores more, I've found that the best programmers are those who learned simpler, higher-level languages before others.
If Jessica learned Pascal, then C, then assembly, I'd bet she's pretty good at all three. If Samantha learned the same languages in the opposite order, chances are she's not as good at any of them.
You may disagree, but it has certainly proven true in my experience. My impression is that the folks who learn low-level first get bogged down in the details and have a harder time finding the elegant (read "simple") solutions. Once the problem is decomposed, experience with lower level languages translates into tools for building a clean implementation of the solution.
A background in electronics is also very beneficial, these people tend to have a better grasp of timing issues, synchronization, and "getting it right" verses "it works, good enough".
All the best designers and developers I have met have had a background in assembly language and most have had at least a hobbiest interest in electronics too.
And then of course there's the whole discussion of how people with a creative bent -- especially in music -- make for the best developers.
In a previous life, if we had a choice between two equally strong candidates we would always hire the one with a musical interest.
AJ
I don't think that teaching students assembly makes them programming aces. I think that programming aces embrace difficult techniques like assembly.
If you try to jam assembly down the throats of a wider audience, you'll just have _more_ students bailing from computer-related fields.
You'll probably get the same number of programming gurus out the other end as you would have without broadening the exposure to assembly programming.
A developer must be able to utilize all the tools available to him or her. That means leveraging high level languages, applying libraries, and utilizing design tools like Rational.
Likening good developers to the level of assembly they know is just pure elitism.
Yup, that's Dave. After Teklogix he went to work for DEC and worked on DEC-TALK and then the Alpha.
Dave is the ultimate uber-hacker and I never met anybody like him. He could talk more quickly than a country auctioneer and code even more quickly and was never wrong, ever. He works for MS now in the machine architecture group last time I talked to him about a year ago.
Need Mercedes parts ?
This disturbs me. I have completed two years of a Comp Sci degree and I have been taught Java and a little html. I hear that a new teacher has taken over that subject and the now learn css as well.
Whoopee.
We were taught jsp, and given the option to do our major assignment in php instead if we liked. They didn't teach us any php, nor supply a computer to host it on, but after some research on the market share that php had and the way it was growing, I decided to take the road less travelled.
I was the only one.
I taught myself php and figured out installing it, creating a dynamic dns so I could host it on my dialup account, installing mysql and getting the whole lot to work together.
It may not sound like much, (it doesn't to me now) but I had no help, and this was a group assignment I was doing on my own.
Now I'm employed as a web devloper creating web-based systems using php and mysql.
We have not been taught C or C++, no assembly, no php, no xhtml, no css, no bash. Yes, the taught us enough of how to manage our files (cd, ls, rm, and a supplied script for mounting floppies), but nothing serious like scripting or evening piping one command to another.
I have very little idea about memory management, and yet the university claims that they are teaching me "programming concepts" that will enable me to learn another language very quickly. I should be able to just pick up C and start.
I was stuck with my first C++ program for days before someone told me that I should be using g++ to compile it instead of gcc.
All this makes me wonder. What have I learned at Uni ? What jobs can I apply for NOW ? I can apply for a job programming in C++, but who would hire me if I told them I had a degree in Comp Sci and I'd never used C or C++ ? Sure, I can probably learn it quickly given a decent programming guide and a reference guide but it makes me ask again... why did I go to Uni ?
I taught myself Apple Basic at the age of eight by looking at the code of the games that came with our Apple ][e. OK, I had some help from a couple of books from the library that had some simple 50 line games listed in them but the point is that I learned it with no help other than that. If a University has charged me $600 per semester per subject to teach me one language and the ability to learn more, and I already had that... I wonder what point there is.
Up until now, I thought this is what Uni Comp Sci was all about. This is what they teach everywhere. How wrong was I ?
The three most useful subjects I did were Theory of Computation, Algorithmics and Advanced Algorithmics. No programming was taught, when you were expected to write code it could be in C, C++ or Java but nearly everyone chose Java because that's all they knew.
What we learned was that the difference between N^2 and N(Log(N)) was far more important that any optimisations you could tweak in assembly language.
So, the final question remains; am I better off with a degree in Comp Sci and only one language under my belt (I don't count Apple Basic anymore) or am I better off teaching myself C and trying to get a job and some experience.
I suppose there should be a third option there: should I simply find myself a better University that actually has a serious Comp Sci course ?
Sig matters not. Judge me by my sig, do you?
From an old Dilbert:
Engineer #1: Back in the day we programmed everything in assembler.
Engineer #2: We programmed with ones and zeroes.
Wally: I programmed with ones only.
Dilbert: I had to use "els".
First, let's define "assembly language programming" as "accomplishing something using assembly language".
There are (at least) two components to doing that. First is knowing and using assembly language itself. This is knowing what the machine registers are (AX, DX, SI, DS, etc) and how to manipulate them using assembly instructions (MOV, JMP, etc.) This part is the same for all uses on an x86 platform - Linux or DOS or Windows or your own operating system.
The second part of assembly programming is interfacing with other software routines to do something useful or fun. Unless you're writing your own OS from scratch, this is necessary. Suppose you want to load a file from disk into memory space so you can do something with it. You'll want to interface with existing OS file operations; you don't want to write code to navigate the OS file structure and read from the disk byte-by-byte.
Under DOS, you do this by loading data into certain registers to indicate parameters (references of a filename and of a memory space to load the data into) and executing the assembly instruction INT 21h. DOS code then finds the file on disk, goes through file-locking routines as necessary, and copies its data into the memory space you specified.
Under Windows, this is completely different. You push parameters onto the stack to simulate a C stack calling frame, and then you transfer control with a CALL instruction to a Windows API function in a DLL somewhere. Then the Windows code finds the file and loads it into your memory space. That can involve very complicated things like connect to another machine over a network and pop up a box to the user for a password - you definitely did NOT want to reinvent all that in assembly yourself.
Under Linux, there's yet another convention to accomplish something like that (I'm ashamed to confess that I really don't know how it's done in Linux.)
But that's how "x86 assembler" is the same yet differs drastically on different platforms.
Hi, I'm new here. This thread was posted on the Win32Asm forum, where I spend a little time. http://board.win32asmcommunity.net/index.php I've been a professional programmer for about 35 years. I "worked" on the IBM 1130 "mini" at my high school, in my senior year, 1968-1969. I already knew Fortran, having taken an "adult school" class the previous year. I also had a second shift job after school, as an IBM System/360 operator. When I graduated, the company hired me as a junior programmer, and I started using Cobol. Cobol at the time didn't have much built-in error processing. Things like alpha data in a numeric field often resulted in a "core dump", a printed listing, showing the machine language and data in memory at the time. In order to debug the problem, you needed to know at least some machine language. Everyone had a "green card" that listed the instruction opcodes, formats, etc. When I did discover assembly language, around 1970, I already knew what was going on, from looking at Cobol dumps. Assembly was way cool. I could do what I wanted directly, without having to deal with all the overhead generated by Cobol. Even the "optimizing" Cobol compiler that came out a few years later still generated a ton of overhead, simply because it's such a generalized language. I instantly fell in love with assembly language, and it's still my favorite language by far, no matter if it's on the current IBM System/390 mainframe, the x86, or the 6502. It just seems like the "natural" way to program, a least for me. I tend to agree with a previous poster, people that put down assembly language really don't have much real world experience with it. I don't think they know much about things like Macros. I'm not talking about simple "text replacement" facilities, like in MASM, but a true front end pre-processor, like on the System/360/370/390. Things like Global Variable Symbols are very powerful. I've developed a couple of Macro assembly based "languages" over the years. They had the usual verbs, like ADD, IF, MOVE and so on. They also had application specific verbs, like INPUT and OUTPUT, for the 3270 terminal system that I worte. An entire source program was 100% macros, without a "native" line of assembly code in sight. Sure, it took quite a while to write all those macros. But once they were done, an "end user" program could be written very quickly. As the macro code matured, new programs were virtually bug free. Sure, it takes a while to write assembly code, and it takes even longer to write good, optimized code. But those of us that have been doing it for a while don't start from scratch every time. We've got a "library" of "reusable" code, that's been beaten up and fine tuned over the years. I get a kick out of comments like "you can't write a big application in assembly language". The IBM mainframe MVS operating system was once described as the most complex software project ever designed. Guess what it's written in. 100% Assembly Language. :)
What part was anecdotal?
And how am I being high-and-mighty if I point out the obvious? (or what should be obvious to anyone who has used assembly for a while).
Or better, what part of:
traverse: cmp esi,0
je endpoint
mov eax,[esi]
call ebx
mov esi,[esi + 4]
jmp traverse
endpoint: ret
don't you understand? This is a standard linked list traversal in assembly: it takes a pointer to a function as an argument in ebx, the head node of the list in esi, and it will traverse the entire list, calling the function in ebx for every node in the list. It's seven instructions, and it will work for any datatype.
In C++, the above would probably be written as:
template <class T>
class Node{
T data;
class Node * next;
};
template <class T>
void traverse (void (*func)(T),Node * list){
T tmp;
while (list){
tmp = list->data;
func(tmp);
list = list->next;
}
}
So, in C++, I've got to write 14 lines, where in assembly I have to write 7.
How is that harder?
How is this cliche? I can demonstrate with examples. I'm not repeating some tired old mantra - I've spent a considerable amount of thought on this. At one point in my career, I couldn't use anything but assembly; the experience taught me that assembly is a very versatile language, provided one follows some very basic coding standards (register usage, calling conventions, etc...)
It never ceases to amaze me the number of programmers who can't or won't write in assembly, almost to the point where it's a superstition. Perhaps they had a bad experience, so they've written it off. Perhaps they learned computer programming rather than computer science.
I understand assembly can present some difficulties. There are definitely some situations in which the project requirements would exclude its use - and this can be said for any language - but to say that data structures are more difficult to implement in assembly is more an indication of ignorance than enlightenment. Any data structure with a heavy dependence upon pointers is almost always easier to implement in assembly.
I'll leave you with this, though:
traverse:cmp esi,0
je breturn
push esi
mov esi,[esi + 4]
call traverse
pop esi
mov eax,[esi]
call ebx
push esi
mov esi,[esi + 8]
call traverse
pop esi
breturn: ret
What this does is left as an exercise for the reader, but its very close to what you mentioned in the original post...
The society for a thought-free internet welcomes you.
Use PIC embedded controllers, as made by Microchip. There are PIC controllers that have absolutely TINY hardware footprints. They make single-chip processors in as small as an 8-pin package, both through-hole and surface mount. For the kind of design you're talking about, you'd use an external LCD controller, probably one talked to over a two wire serial interface. If you start delving into the huge mass of PIC enthusiast's websites, you'll probably find your display technology without difficulty.
---
I definitely agree with the idea that computer programmers need to learn assembly, and other low-level programming skills. I started my education as an Electronics Engineering Technician in D.C., (i used to teach NSA techs how to build FM radios in the electronics lab) Anyway... my career has been mostly writing macros, maintaining networks, user support, light engineering, etc. and I feel that my in-depth knowledge of computers has helped me immeasureably in these higher-level areas of software maintenance. I laugh at "micosofties" that graduate from colleges here in Northeast PA with their MCSE... I outperform them on a regular basis.
In 1978 I had a liberal arts degree and no job. I borrowed $2000 and went to a trade school to learn computer programming. That $2000 has paid off big time of the last 26 years and continues to do so. The course started with a simulated, 1000-memory-cell decimal "computer"; we programmed it in assembler. We then went to IBM 360-style assembler (all this was on punched cards), followed by Fortran, RPG, and COBOL.
I got a job right away for a company that made data comm hardware and, naturally, used assembler. I didn't touch a high-level language till 1984 (and that was C).
As the years have gone by, the trade (NOT profession!) has become more and more the domain of the "computer scientist". These are the guys who learned how to write compilers in school. Often, they're disappointed when the job involves something more mundane. These are also the guys who have trouble with pointers and other basic concepts because they don't really know what's going on on the machines they program.
German machinists used to spend a year doing nothing but filing as part of their training. Nothing but filing. These were people who honored their craft. Assembler is the computer equivalent. Without it, you might be a "scientist", but you'll be a lousy craftsman.
I once worked for a guy who learned programming in the Air Force in the 60's. His motto: "It's all just loads and stores and branches."
instead of just slamming out pages with Dreamweaver or similar. Same concept, actually understanding what's going on beneath the covers.
One of the leaders in computer architecture, Yale Patt, has already written a book based on this concept. He gives enough of an overview of logic design to understand things at an RTL (register) level, and distills CPU design to its essentials. He doesn't get to C until half way through the book.
His observation is that CS students have a MUCH easier time comprehending things like recursion when they understand what's really going on inside.
(My efforts to get this book introduced at my old university were unsuccessful, as the department chairman was afraid that teaching assembly language would drive students away. He wanted to teach them Java instead.)
When I was a kid, we didn't have fancy CMOS gates, we had to pick NMOS or PMOS and go from there!
autopr0n is like, down and stuff.
Assembly Language Step-by-step: Programming with DOS and Linux
by Jeff Duntemann
ISBN: 0471375233
= 9J =
write microcode.
sig under development
25 years ago I started programing in CESIL (Computer Education in Schools Instructional Language), it made the assemblers of the day look feature rich (sic).
jonnyb decided to enlighten us... /.ers "a new book has been written", for "I wrote this book I am now selling" would be too much of a giveaway...
so jonnyb wrote a book...
and then jonnyb had it published...
figuring he may as well sell some copies...
but jonnyb had a target audience who didn't know the book was written and published...
so jonnyb decided to tell
jonnyb wants to advertise a product, but wants to be deceptive about it... it is cheaper this way I guess
o/~ Join us now and share the software
Assembly language for one course is great for understanding the low-level aspects of computer software. However, I have employed that level of understanding in my 23 year career less than a dozen times. Only one of those was mission critical. I would much rather see students equipped with VHLL (hint: Java ain't one) than assembler given a choice. A really good survey of languages course and a compiler course is more useful than assembler by far.
It's a contrived simple assembler they used to use at AT&T to teach programmers assembler. This is not a new concept. This kind of touches on one of my themes, that being that most younger computer science people are mere technicians who are in the field to make money, not because they love it. They don't have a clue about the history of their discipline, nor do they care. I really see this in the the 15 to 30 year olds. 99 times out of 100 they really don't have much of a clue. In a way I feel sad for them, because they didn't experience things before the huge monolithic companies (you know the cube farm sweat shops like Adobe and Apple and Microsoft) got on the scene and pushed lots of wonderful products off the market through business muscle and not survival of the best product. I also feel sad when I try to hire people. Most graduates that I interview know a whole bunch about Visual Basic and SQL, and not much else. (In other words they have no real training at all)
To the tune of "Buddy, can you spare a dime?":
Once I had a website,
made it run,
made it race against time,
once I had a website,
now it's gone [to India],
Buddy can you spara digm?
Once with Starbuck's coffee's,
gee - we looked swell,
full of that Yankee Doodle de dum,
Once we could buy Starbuck's,
now it's gone [to India],
Buddy can you spara digm?
Say you remember,
Oh - please tell me you remember,
Buddy can you spara digm?
Of course, when we started out at the beginning of the semestre it was all binary, our inputs were done in hex, and toward the end we were using standard MV, ADD assembly notation. Hard to believe it's been 8+ years; amazing what you forget.
Anyway, we were programming for the Sinclair Z81, which is odd because the first computer I ever used (and put together) was a Timex Sinclair.
Most of our graduates went on to work for the Department of Defence, NASA, or other government programming jobs (hence the focus on Ada for coding and rocketry in math courses) - fewer things are better cures for insomnia than taking lectures in aerothermaldynamics.
I didn't go for the M.S. in CS (which is why I was blasting through undergrad prerequisites); ultimately I just went to work doing web development. It pays the bills. Still, one day I'd like to add an M.S. in CS or a Ph.D. to my B.A. and M.Ed. He who dies with the most degrees wins.
So far no one mention this report from ACM/IEEE.
It is on computer science curriculum and it describes several approaches to introductory courses -- object-first, procedural-first, hardware first, etc.
My opinion is that it does not matter whether you start with high level or assembly as long as all levels are covered.
And many people mentioned Knuth and TAOCP. But this is not an introductory textbook for beginners. The reason he used assembly is to describe and analyse EXACTLY the cost and complexity of different algorithms. No one now could be called CS expert without reading this seminal work. So in some sense, expert programmers would know assembly but programmers who know assembly are not necessarily expert.
My experience started with Pascal in highschool, scheme in first year college and C++ in second year. I encountered assembly, and binary gates and hardware, in second year basic architecture course. So can I cal myself expert?:)
Anyway, computer science at UBC is quite good! (I am kind of sad when they change first year courses from scheme to java. Not that it is a bad choice, but I am not sure why I feel that way.)
...is to write a disassembler, preferrably in assembly language. Of course, you this won't teach you a lot of the required practical aspects (interacting with the OS, etc), but it will teach you everything you need to know about the processor's instruction set. Highly recommended.
You had keypunch machines? I had to make my own arrowhead to poke holes into a punch card.
Fight Spammers!
So, my problem with this idea is that it seems to assume that computer science is all about computers and/or programming. Granted, that's what alot of CS curriculums focus on, and that's what alot of CS-majors wind up doing, but computer science isn't really about computers... This sounds like something that'd be more appropriate for computer engineers.
On the other hand, if you say something more along the lines of "if you learn assembly language, you'll be a better programmer" or "you should start with assembly language before learning a high level language," then I sort of agree, but sort of don't. Knowing assembly most likely will give the programmer a better understanding of what's going on inside the machine, which is probably useful in lots of places, but not useful everywhere. I would expect that if you continuously think about the machine instead of about the problem you're trying to solve, you wind up getting bogged down in alot of mechanics of the machine. This is probably a good reason why you should start off programming in a higher level language (And I do not include C here, because C is too close to the machine) and focus on the real problem you're trying to solve, and go down closer to the machine only as it becomes necessary (i.e., something you obviously have to do if you're doing any sort of system programming). It would be interesting to take two groups of beginning programmers, and start one off with LISP and the other off with assembly, and see who really understands things better. I would expect that the LISP kids might have a better understanding of algorithms and high-level problem solving, while the assembly kids would have a better idea of what's going on with the internals of a machine.
There's also a fear that you will scare people off if you try to start them off with assembly (though those who aren't competent in LISP would probably say the same about LISP), but then I guess the question becomes are you trying to teach them how to be good programmers, or trying to attract as many people as possible.
Let me make it clear that I'm not 'bashing' assembly language, just that I think it's not the best way to do alot of things (and I've got a feeling anyone who's ever written alot of assembly will agree, to an extent, except those that have to be 'hardcore' and love assembly and only assembly).
In any event, I think the best way to learn programming is probably to have a little bit of high level stuff, a little bit of low-level stuff, and be capable of choosing an appropriate tool/language/whatever.
<wik>/bin/finger that girl in the back row of machines.
pics? links? /me is a K'Nex addict ;P
I used to get high on life, but I developed a tolerance. Now I need something stronger.
while(true) {MyCaseRests(0, null, false)}
If you look the poster is called "johnnyb". The name of the Author is Jonathan Bartlett. As far as I can tell most of the books on the Bartlett Publishing website are by Jonathan Bartlett. It looks to me as if this is basically a vanity press.
cheap labor conservatives - they want to keep you hungry enough to be thankful for minimum wage.