Why Learning Assembly Language Is Still Good 667
nickirelan writes "Why Learning Assembly Language Is Still a Good Idea by Randall Hyde -- Randall Hyde makes his case for why learning assembly language is still relevant today. The key, says Randall, is to learn how to efficiently implement an application, and the best implementations are written by those who've mastered assembly language. Randall is the author of Write Great Code (from No Starch Press)."
Because you can kill any 2.6.x kernel (Score:3, Interesting)
Why it's still good... (Score:5, Interesting)
Schools not teaching assembly anymore (Score:5, Interesting)
Re:Best, efficient or cheap (Score:3, Interesting)
Right. Because after reading that article, I thought, "Boy, if *I* was a CEO, this is how my guys would program everything." Actually, he says in there that writing everything in Assembly is not for every project.
So what's great about it is that if someone is looking to make a step to become a better programmer, this would be a good direction to check out so that you truly understand your code. If you are happy being a VB code jockey (or any code jockey for that matter) then rejoice! and don't take the time to learn Assembly.
how many people actually program in assembly? (Score:5, Interesting)
To make matters worse, each CPU has it's own instruction set, and special set of commands that you must learn before you can even sit down and start writing code.
With C++ or at least a C compiler, you don't need to worry about so many implementation details. You should only resort to assembly if you absolutely, must have the performance required. Maybe the author of this article forgets how difficult it is to debug assembly code, or how difficult it is to implement abstract concepts such as OO at such a low level.
I don't agree at all that writing "efficient code" necessarily creates better code. Writing "clearer" is better from a quality standard.
We have compilers for a reason, to produce assembly code as efficiently as possible for a higher level language. Most 99% of the time, the compiler will optomize the code just as well, or better than you can.
I would still recommend learning assembly language to C++ programmers simply so they understand how the computer is actually working. But to require anyone to program in assembly requires a great deal of justification.
Re:Schools not teaching assembly anymore (Score:5, Interesting)
Given the rise of byte code environments like Java and
Re:Debugging (Score:5, Interesting)
Disclaimer: I learned to debug before I learned to code.
With extremely few exceptions, machine code performs exactly as advertised. When things are not exactly as they should be, it helps to be able to see exactly what is going on.
Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.
Re:I disagree (Score:3, Interesting)
You're on. After my exams are over, I'll code a bubblesort algorithm in assembly language. I wonder how large the dataset will have to be before you win? Mail me [mailto].
Which Platforms? (Score:5, Interesting)
Intel could give many kickbacks to university programs, but they appear to get criticized for chips with too much baggage and backward compatability.
The RISC PowerPC processor has potential, but the number of consumer desktops with it has been on the decline (Is anyone but Apple left?). Computers might be too expensive for some students.
A Palm Pilot / Handheld sounds like a great choice to me. They're cheap and can be synced with whatever consumer desktop the user has (I can't imagine coding assembly in Graffiti). The limited hardware is probably a plus for academic purposes.
I think this fellow makes some great points, but what platform and tools would you choose to learn assembly with?
Re:Schools not teaching assembly anymore (Score:3, Interesting)
http://www.polylith.com/~brendan/ClassicC
Try the games industry (Score:5, Interesting)
To take full advantage of processor features like SSE or AltiVec you don't really have a choice.
For example, UT2004 contains SSE and AltiVec assembly versions of some of the vector and matrix manipulation functions, some of the visibility culling code, etc. The amount of work Dan Vogel put into this kind of optimization is one of the reasons that UT2004 runs better than UT2003 on the same hardware.
Learning assembly language is useful, as it's sometimes the right tool for the job.
uControllers + Assembly = Fun (Score:1, Interesting)
Where am I going wrong? (Score:2, Interesting)
I see very few links between the way I code in assembly, and how I write the higher-level languages. Yet according to this article I should have the makings of a guru. Where am I going wrong?
Presumably everyone understands binary encoding, shift right and left instructions, and the like? Anything much beyond this is liable to be very architecture-specific - which is bad. I look forward to the day when I can choose between a number of architectures and run the same open-source programs on each. I loathe X86, and I dislike apple for other reasons.
Perhaps we become more rigourous by writing assembly for small systems - with very few resources. But beyond this, I can see no real advantages to learning assembly.
I regard myself as a good programmer, but I see my strengths as being clarity of expression and design.
Skywolf
Learn compilers (Score:3, Interesting)
Re:don't bother........ (Score:1, Interesting)
The old days... (Score:2, Interesting)
However, My most sought after skill with my peers was not debugging programs, but using DOS debug to hack around the copy protect schemes in use at the time for various apps and games...
Never too much assembly (Score:2, Interesting)
I myself have learned two and a half different languages at Ohio State and am trying to find time this summer around work to learn a third. To be honest it is almost a "cool geek" thing for me now. I mean everyone and their mother knows C++ or can create a website. Those just aren't as geek as they used to be.
The two u-controllers (microcontrollers for the slow people) that I learned assembly on are the Motorola 68HC11 and on a fairly standard PIC, which one exactly I worked with eludes me at the moment. The half of a language I know is from the MIPS64 family of processors. I only know "half" because I sort of picked it up as a result of another class and have never actually used it myself.
The language I am hoping to learn is the x86 assembly language. It seems to me that of all the u-controllers and processors the one that is by far the most common is the x86 architecture. I can think of several good reasons for individuals to learn assembly language:
Re:I disagree (Score:5, Interesting)
Yes, this really is the crux of it all and I left that out. I participated in a very interesting challenge to generate 10 unique random numbers in a scripting language. The goal was for minimal time. As it turns out, a simple array check of whether or not the number has been included worked the fastest due to the fact that you're generating only 10 numbers. As soon as it got up to 100 or more, the array approach O(n^2) broke down.
So for a small dataset, I'll award you your prize already.
Assembly vs. scripting (Score:5, Interesting)
In this case I think the reason was the system having to load the binary vs. the script interpreter already being resident in memory. The start up overhead dominated the actual runtime overhead - binary searchs are very quick.
Re:Try the games industry (Score:3, Interesting)
This is true. However, the intel c++ compiler does a decent job of vectorizing code. I wrote some benchmarks comparing gcc, icc (intel) and hand coded
assembler using mmx/sse/sse2. Icc did surprisingly well, often equivalant to my hand coded assembly (gcc did less well).
"Premature optimization is the root of all evil" (Score:5, Interesting)
Having said that, knowing assembler is useful because it teaches you how the machine works.
However, most modern compilers can generate code that is much faster than handwritten assembler - especially because they know how to take advantage of the specialized processor architectures (hyper-threading, pipeling etc).
The Art Of Computer Programming (Score:4, Interesting)
I've been reading this site since it was chips n dip, but this is the first time i've ever felt the need to comment.
I can't believe that any developer could write and code without some knowlege of ASM. Disclaimer: I'm self-educated, so have no bias except my own.
More importantly, if you don't know ASM and can't understand machine language, you'd never get through Knuth's tome "The Art Of Computer Programming".
In my opinion, this is the most important work ever written in our field. Any developer worth his/her salt should have at least read and understood these books, and completed at least the simple exercises.
the examples in tAoCP are written in machine language for a fictional machine, but the depth one learns by reviewing what that machine does with its data is important in any project.
I've never programmed professionally in ASM. infact, i usually work in Perl/PHP/Python. But i would not be able to write quality code in those languages if my mind was not constantly thinking of the machine. After all, i'm a computer programmer, not a linguist or scientist.
Not knowing assembly, or at least having some idea as to how a computer processor works, would make a programmer useless in my eyes. leave them to Access or VBA, and leave the coding to us pro's :)
I beleive that ASM should be taught first. If you can't understand ASM, you'll neer be a good programmer, so why bother learning Java/C++ or whatever? would you trust a doctor who didn't know how the body works?
drewcOpen Source Business: The Tech Co-op [tech.coop]
Function calls and data buffering (Score:3, Interesting)
Given the way processors are pipelined, you take such a hit for any kind of function call compared to a set of arithmetic operations that the only way to go is to call functions on arrays or slices of arrays to process batch of samples at a time. If you implemented a digital filter by calling a function for each sample you want to process, that is going to be slow, while if you call a function for batches of 1024 samples, you are really pretty insensitive to the function call overhead. If the function call overhead is high, just make the batch size bigger.
This arises in other situations: for operations over a network it is recommended to make your transactions blockier or chunkier; for raster graphics, the naive Windows SetPixel() command is slow compared to CreateDIBSection().
Re:Smaller code? We can hope... (Score:2, Interesting)
I'd love to see a return to applications that were under 100K
No kidding. I'm not a programmer, but this guy [grc.com] writes little helpful applications in assembly that are like 20K. In this day and age, I'm impressed when anyone writes anything that can just fit on one CD-ROM.
Re:Because you can kill any 2.6.x kernel (Score:3, Interesting)
Re:Schools not teaching assembly anymore (Score:5, Interesting)
Re:Debugging (Score:1, Interesting)
++(char *) 0xb0000;
--(char *) 0xb0000;
Not printf(), but hey, it uses the (monochrome) text screen...
>
(Holds AM radio next to motherboard, listens to the bits going by)
>
Oooh, those are the worst.
>
Use SmartHeap.
>
Those are pretty much axiomatic at this point.
Toccata & Fugue for Eight Bits (Score:3, Interesting)
Re:Schools not teaching assembly anymore (Score:1, Interesting)
Re:desire to teach someone 6502 assembly language (Score:3, Interesting)
Maybe you are simply a teacher. I'd say just do it. I avoided college for 10 years because I simply hated being a student. Then, my wife practically forced me to go so I could get my degree and start teaching. I admit that I hated the undergrad junk, but now I am much happier to be in an academic environment than hacking away in some company.
Also, there's the Internet. To this day, any search for my nick (kainaw) still turns up "Kainaw's Amiga Internet Guide" - a guide to getting an Amiga on the Internet when all we had was SLIP over dial-up. Maybe you could write a good guide to 6502 assembly and be surprised when someone calls you in the middle of the night with a strange assembly question.
Good luck... (Score:4, Interesting)
Of course, there are other pre-existing C libraries you could use that do all of these things, but there's no telling whether or not they're faster than what Perl uses internally, and since you're re-implementing everything in C anyhow, you might as well just write your own!
So the point I'm trying to make here is this--Perl is convenient because it has all these things written for you and integrated together. Sure you could write a C program that does the same thing, but you'd end up re-inventing the wheel many times over, and you'd have to work hard to make it a better wheel.
Or you could target Parrot instead, for a lot of things it's already faster than Perl. It also has a JIT compiler, so who knows--it might generate some code here and there that's faster than what your C compiler generates.
laziness (Score:2, Interesting)
Re:I disagree (Score:2, Interesting)
To sort 3000 bytes of random data it takes 5.4 seconds on a P4 1.8Ghz while running in debug.exe under Win2K. That's 1.6 million comparisons (of AL to AH) per second. I wonder how long that would take on a Javascript quicksort implementation!
Counterpoint (Score:2, Interesting)
Every shred of C he's ever written is absolutely unmaintainable. It's just horrible.
The answer to the question "Is assembly language faster than C?" is the same as the answer to "Is C faster than assembly language?": "No." My point is that there's no magic bullet. The article was not nearly balanced enough to be considered correct.
There's a more fundamental flaw there (Score:2, Interesting)
Passing 10 argument is bad regardless of the performance issues. These students are making a much more fundamental mistake: they're not dividing up the problem properly into easy-to-understand pieces.
A useful analogy (but don't take it too literally cause I'm oversimplifying it): verbs in natural languages never have more than 3 arguments (subject, direct object, indirect object). If you find yourself crassly exceeding this, you need a justification.
Whats a good place to start? (Score:2, Interesting)
Re:Debugging (Score:5, Interesting)
Turns out I was overruning an array, and the static strings for the debug printf()s gave my process just enough space that it stopped trying to trash another process' memory (just its own).
Luckily, as a former assembly language programmer, from the mere change in behaviour, I had an inkling of what was going on...
--
Re:I disagree (Score:3, Interesting)
Re:I disagree (Score:2, Interesting)
A few years ago I worked with a gentleman who had graduated from a trade school. He was a generally sharp programmer, but he really put me to shame in database design and SQL. He had completely internalized the relational model, and could write a query in five minutes that was an order of magnitude faster a query I'd taken an hour to come up with. On the other hand he had no idea how floating point numbers were represented in the computer (he assumed everything was BCD). In database design there are so many levels of abstraction between you and the hardware that
understanding the CPU architecture is of very limited utility.
What Assembly Is... (Score:3, Interesting)
A computer is nothing more than a very fast player piano, and nothing less.
Simple, huh? But it is understanding this that is key. First off, how a player piano works: there is a reel of paper, the "roll", upon which is impressed, via a series of holes, one for each key, and a few for pedals - the notes which will be played. It is pulled past a row of vacuum air valves by a clockwork or electric motor. This same motor drives the pumps for the air system, when a hole passes, the note is played - how long the hole is determines how long the note is held down for. Other holes determine how long the pedals are held for. The roll of paper unrolls at a constant rate. I believe there were "operator" knobs to set this rate for various rolls, as instructed on the rolls.
And that is how one of the Victorian-era programmable machines worked. This is all a computer really is. This is how a CPU works.
Imagine the roll of paper with its holes, each "row" on the roll being one "address" in this very long (but finite) amount of "memory". At each address, or "row" of holes, is encoded an "instruction", consisting of a bit pattern, that is read by the "CPU" (the valve system), which "executes" the command to the rest of the "system" (keys and pedals). Then on to the next "row"...
This is how a CPU works, and it is how assembly works. The CPU has a bunch of address space, and it is mapped to the addresses to which the memory can be instructed to read or write. The clock on the system causes the CPU to advance states in the system, which increments an address counter, typically called the "instruction pointer" or IP. This pointer is set to a value indicating the starting address of the code. When the CPU is told to "run" the code, the instruction pointer is advanced one address at a time by the clock. At each point, the CPU reads the data at that address. Let's say each opcode in assembly for our fictional CPU is one byte in length. Some of these opcodes say that the next byte might be data, or the next two bytes are data, or no bytes are data (the next byte is another opcode). Each of these codes causes the CPU to read the instruction, switch logic gates via electricity in the electronics so that a logic path changes to read the next bytes as needed and assign them to whereever (other memory, a register, a pointer). Some of these opcodes may be jump (JMP) instructions, in which the next byte or so represents an address to which to set the instruction pointer (thus, unconditional branching). Other opcodes may indicate conditional branching, in which the processing the CPU does for such an opcode reads certain flags, memory areas, or registers, and then jumps (or not jump) to the specified address based on the boolean outcome of the comparison.
You should now be able to see how stringing a series of opcodes (bytes) and data (more bytes) together, with the CPU stepping through it, electronically and electrically reconfiguring itself to shuffle data (which is represented by electrical logic states, like +5V=1, 0V=0, in electronic circuits - it goes deep, very deep). Name the opcodes according to what they do, and how many bytes afterward are "arguments", and there is how a CPU works, at the basic level. Just like a player piano.
All the CPU is doing is slogging through a whole mess of bytes and interpreting them to electronically re-arrange itself to perform calculations. There are further refinements of this - my explanation of how a CPU and assembler works is only a very basic one (I can't write a book for ya, can I?). One such refinement (and incrediblely, none other than Charles Babbage implemented a form of it in his plans for the Analytical Engine) is the concept of "microcode". Microcode is essentially assembler for which the CPU is pr
More important to read than write (Score:5, Interesting)
An earlier poster mentioned how such a skill can help you find compiler bugs. This can be the case, but it is rare; I have located two such bugs in 20 years of programming. A more common use is to locate bugs in your code. When your brain refuses to see the missing braces around the wrongly indented code, or an spurious semicolon at the end of an if or while statement, reading the generated assembly code can save some extra hours of frustration. You will be able to see that the code the compiler generates differs from the code you think you wrote, and this will point you to the bug's location.
As I argue in Code Reading [spinellis.gr], other cases where reading assembly code can be of use are:
To read compiler-generated assembly code you need:
Obligatory "hello, world" program written in i386 assembly:
Diomidis Spinellis - #include "/dev/tty"
Virus and antivirus... (Score:4, Interesting)
I guess it helps if you are in the business of making bugs, too.
IRTA but found it poor (Score:3, Interesting)
seems that article is a try to hype the book: "Write Great Code". While some few small trues are in the articel msot of its conclusions are false conclusions
Some random quotes:
It's all well and good to say, "I'll just find a better algorithm!" However, finding and deploying that algorithm, if one actually exists, is another matter.
A programmer able to find a better algorithm is also able to deploy it. Why does the author think different there?
say, going from an algorithm with O(n^2) performance to one with O(n lg n) performance, but the truth is that most of the time a constant factor of two or three times improvement, applied throughout a piece of software, can make the difference between a practical application and one that is simply too slow to comfortably use.
Hm, isn't that a little contradicting to the authors rant? He argues that the programmers are so poor, they can not even find more efficient algorithms
Advances in computer architecture have exacerbated this problem--for example, you might hear a programmer say, "If this program needs to be a little faster, just wait a year or so and CPUs will be twice as fast; there's no need to worry about it." And this attitude, probably more than any other, is why software performance doesn't keep pace with CPU performance.
Ooops: he clearly does not know what programming is about
Well: but this is the most clear statement that teh author has really no clue how two write efficient software on old hardware:
Programmers were doing great things with software back in the days when their applications were running on eight-bit 5MHz 8088 PCs; the same techniques they used to squeeze every last bit of performance out of those low-end CPUs provides the key to high-performance applications today. So, how did they achieve reasonable performance on such low-end processors? The answer is not a secret--they understood how the underlying hardware operated and they wrote their code accordingly. That same knowledge, of the underlying hardware, is the key to writing efficient software today.
Assembly language or C
Most good programs used two principles:
a) lookup tables, e.g for sinus values
b) looking at the requirements from a different perspective, which seemed to behave from the outside like expected, but was achieved in a unconventionel way
Long after that the geeks started to look at the underlying hardware. Before a) and b) did not happen it makes no sense to check wether LD A, #$00 is faster or EXOR A, A.
Underlying hardware is the point where you have to fiddel far mroe than just knowing assembler. How do you access a Joystick? Today with DirectX or some other device driver. In my days you wrote to a memory locations. That caused a condensator to be loaded. Then you started to read a second memory location in a loop. The
Re:Debugging (Score:3, Interesting)
Re:Good luck... (Score:3, Interesting)
Depends.
If the bulk of the CPU is in the program code as opposed to the library code, then C should be substantially faster than Perl.
If the bulk of the CPU is in program code for C and in library code for Perl, then chances are high that the Perl is better coded and optimized.
If the bulk of the CPU is in library code, then it depends on the libraries.
Formatted IO tends to be heavily interpreted and the odds favor Perl as being much faster.
Abso-fscking-lutely (Score:4, Interesting)
I pulled it up in the debugger (a Sun box), and stepped through the code...and, when I found it was crashing in Tuxedo, I did something the consultants (young guys) had no clue you could do...I stepi'd *into* the binary.
Now, I didn't know Sun assembly language, but that was irrelevant. I nexti'd and stepi'd my way through, and found the name of the function it was crashing in, which will *always* be there, even in a stripped binary, and where it was doing it in the function.
I could then call BEA (I was senior technical, and Rank Hath Its Privileges), and get info from their developers.
Turned out to be the environment, not a bug, but the point is, once in a while, *knowing* what how things work Down There will save your butt, and maybe even lead you to better code.
mark "and I pushed my kids to know what
happens under the hood of the car, too"
Re:"Premature optimization is the root of all evil (Score:2, Interesting)
Re:Duh. (Score:3, Interesting)
Definitely not true of musicians who think in radically different terms from insturment builders. There seems to be a big hole in your analogy. Building an insturment is not analogous to writing in assembly language. A better analogy would be to say that building an insturment is analogous to building a CPU. Musicians think in abstractions such as beats and tones rather than in the terms of resonance, refraction, interference, and reflection that are central to insturment designers. Likewise, most programmers (even assembly programmers) think in terms of abstract bits moved or transformed from location to location rather than thinking in terms of resistance, capacitance, induction, and heat.
A better analogy would be to say that musicians learn a lot from practicing and composing etudes, compositions that focus on the relationship between musical theory and technique.
invaluable (Score:4, Interesting)
I took the TCP/IP software for an old minicomputer at my old job, licensed to the particular CPU, and figured out how to defeat the licensing so it'll run on any machine... all with no source, just by decoding/hacking the assembler and changing a few BNZ (branch Not Zero) to straight branches. I've played with building my own boards, and writing drivers for them.
From the standpoint of knowing how things work.. having the base knowledge of how the underlying hardware works, I can pretty much pick up any language on the fly.
I had a guy recently who I had to explain why:
status="green";
if (result1 >= 0) status="red";
if (result2 >= 0) status="red";
was better than:
if ((result1 >=0) && (result2 == 0)) status="red";
else if ((result1 == 0) && (result2 >= 0)) status="red";
else if ((result1 >= 0) && (result2 >= 0)) status="red";
else status="green";
no concept of the difference in 6 compares & 3 logical and's, vs two compares. Not that his way wouldn't work.. but *efficiency*. In a lot of ways, in my mind, mastery of assembly language can bring great insight into the *best* way to accomplish something.
Re:don't bother........ (Score:1, Interesting)
You talk about your python code feeling 'instantaious' (ignoring the spelling), which yes may very well be true on your one-user 2.4Ghz linux box at home with nobody else beating on it...
I manage java application servers used *worldwide* by perhaps 100K users/day. Our biggest server has probably 40 applications on it, any *one* of which, if ill-behaved, can affect the others. I've run into apps with poorly coded/planned sql queries that take 8 seconds to execute... throw that in a JVM taking 1000 hits/second with 100 threads.. you figure how long it takes for all the threads to block because they are waiting on DB requests, killing not only that one app but the other 5 in that same JVM. (hint, less than a second). It has *nothing* to do with the application code itself running slow (heck, the user hits return, and it generates that DB request in a fraction of a second), its just *poor design*.
As a sysadmin with 300K+ users using my apps, I've gotten bitten *many* times with new code being pushed to prod after "QA" testing that kills the production environment. I don't *like* being woken up at 2AM for an hour+ of poking around and then rolling back the code that was pushed that night. Exactly the same as what you are doing, the QA people test the application *by itself*, and then when it goes to production *I* have to deal with the effects of it running alongside 39 other apps.
My personal favorite OS is NetBSD. A year or so ago they made changes to the rc-script code, and after pushing to -current, a lot of people on older boxes (ie. vaxen, decstations) complained because it was so much slower. Yes, on your 2.4Ghz x86 box, your startup went from 0.5 seconds to 0.6 seconds... but on slower hardware it was far more dramatic.
People today are spoiled by "ah, it runs slow on my 2.4Ghz box, I'll just buy a 3.2 and it'll be fine". Thats fine if its just you on the box. Put 100 people on the box, and your 1-second runtime (that lets say could be optimized to 0.1 seconds if you wrote efficient code) equates to 100 second response for those 100 users. Optimize it to that 0.1 seconds, they get 10 second response. Which would *you* prefer?
Re:Development time is king. (Score:1, Interesting)
You're right. According to Bagley's famous Great Shootout, perl is only twice as slow as C - for operations for which perl is optimised, such as accessing elements in associative arrays. For numerical operations, like matrix multiplication, the sort of thing where runtime optimisations have been shown to let Java perform as well as C, perl runs... 500 times slower than C.
If you want to champion high-level languages, pick a high-level language like Lisp or ML which can be compiled to native code. Ocaml programs regularly perform as well as C, despite being written in a language that's nearly as quick to program in as perl.
Re:Debugging (Score:2, Interesting)
To debug a piece of code on your development machine, just press F5 to start the program, run to a breakpoint, step through, etc.. And if you have a program that consists of 10
If you've got a feature that you can only test by having the code running on 4 machines talking to each other, then it becomes that much more difficult to use debuggers without really confusing yourself.
However, if a program crashes in a function, you can just put a MessageBox() after each block of code, compile it, and run it normally. The last messagebox displayed tells you where the crash is, and you can then narrow your search. It's very useful for finding crashes (which in Windows are normally null pointers).
For debugging networking-type code you can dump "events" (i.e. logging, which we probably should do even when not debugging) into a file. This is useful when there're lots of threads or processes communicating, and you want to know who sent what, and who received it. "Thread x on computer y received message z" and you can get all the messages in order. fprintf can also handle loads of different data types quite easily, so you can send strings to the file without having to allocate new memory to create a debug message in.
I still find the visual studio debugger quite good for looking at linked-lists and stuff, but it seems to get overwhelmed quite easily when you've got more than one program running at once.
Re:To some extent you are missing the point (Score:3, Interesting)
The discussion that "knowing assembly makes you a better coder" pops up here at slashdot every once in a while.
I'd go out on a limb saying that a large part of the reason, for the popular belief that knowing assembly makes you a better coder, is that many people that have learned machine code are really dedicated coders and did it because it was fun. These people have a really good understanding of programming for many reasons, not only the fact that they know assembly.
Those are the people that have their voices heard on this subject here at Slashdot.
And those people are not necessarily the people I would trust to make a curriculum.
Modern processors and FFT algorithms (Score:3, Interesting)
When the FFT came out, a lot of effort went into cutting down the number of arithmetic operations -- eliminating "trivial" operations like multiply by 1, multiply by 0 and add, as well as they higher radix butterflies (radix 4, 8, 16). The simple radix 2 FFT given in many DSP texts was offered as a "teaching example", but "production" FFT programs were complex masses of FORTRAN code that attempted to identify all the optimizations.
In my own experience, the simple radix 2 FFT is best for the modern x86 where as you say x86 is just an API to a RISC core. The minute you start putting in the optimizations, you need additional loops, branches, and tests, which trip up the pipeline. Arithmetic ops are fast compared to extra loops, branches, and tests, so the old mainframe FFT subroutines were optimizing the wrong thin.
Re:Debugging (Score:3, Interesting)
Yeh, silly me, forgetting about all those lisp applications I'm running. xemacs is probably the only one, I personally run, and it's slow, ugly and has more than a few annoying bugs (mainly with the UI). In fact it's so bad I keep looking for ways to migrate from it, but keep whimping out.
I actually like the parens, but I still don't write any real lisp apps. ... and have no intention of starting. Here's a free clue, I didn't learn python because I thought appending commas to the end of print statements was a great idea ... I learnt it because of pygtk.
When there's a free (as in perl and python) lisp language that's useful for doing things in ... those things will start to be done in lisp (I had hopes for rep, but that turned out not to be ... again).
C++ Options (Score:2, Interesting)
What I generally do is overwrite new to place a 64 bytes marker before and after the memory block, which is then checked during delete, and will exit with a stack dump (and a hex dump of the block) if corrupted.
At exit I dump all blocks not deleted (to catch leaks), and I litter my code with asserts (which also do stack dumps) plus have a printf-kind of system, where the level of output can be toggled (often at run-time, if the application i am working on has a user interface (I have a debug-menu component which I just link on my application)).
Due to all the run-time checks, I generally catch mistakes the minute I make them -- I have debugged/resourced lots of other programs and have also programmed in assembler, so it's not a skill I lack, but I honestly never have a need to debug my own programs (except when the compiler produce the wrong instructions, but this is mainly just looking at the assembler output, rather than using the debugger).
My memory system doesn't watch for stack-corruption. This however never really happens, because I only place objects on the stack or const arrays -- if I need a mutable array I use std::vector
I also define _GLIBCXX_DEBUG, which turns on all sorts of sanity checks in the standard library.
Re:Debugging (Score:3, Interesting)
BTW, it's not the case. Segfaulting was an easy clue, and what you needed to understand is how your program was allocating memory. People need to start managing their data or the language needs to start doing it for them.
Whoah, less caffeine for this man! ;-)
Seriously, I know, and knew back then, that the segfault indicated my process was overwriting someone else's memory. What I didn't know was whether it was a) a function in a library I was using, or b) my own code (which I seem to recall was something written recursively for added spice). If the latter, then I needed to know /where/ I was over-running an array, and peppering the source code with printf()s was no use (which was the original point of my post and its parent) as it made the program run "correctly".
--