On Thu, Dec 04, 2003 at 09:10:10AM -0500, Raymond Toy wrote: > > >>>>> "Edi" == Edi Weitz <[EMAIL PROTECTED]> writes: > > Edi> One of the things on my to-do list is learning enough assembly > Edi> language to understand the output of DISASSEMBLE and maybe later > Edi> fiddle with the compiler. I've written a couple of 6502 assembler > Edi> programs on my Apple II a long time ago but that's it. Obviously, > Edi> microprocessors have changed a lot since. I went to two computer book > Edi> stores here in Hamburg, checked what they had about assembly language > Edi> and was a bit disappointed. I even bought one of the books but I don't > > If the goal is to understand disassemble output and you're already > familiar with 6502 assembly, then I think any book would be adequate. > Or even the Intel programmers' manuals.
Possibly not. When I was a teenager, I understood 6800 assembly language very well, but encountered considerable difficulty understanding the docs for PDP-11 assembly language. There was enough of a jump in complexity of what the machine did that I had a lot of trouble getting my mind around it. I think much of the problem was that I had been maintaining a mental sketch of how I would wire up gates to execute 6800-like instructions, and it was much less practical to maintain that sketch for PDP-11 instructions; it's not so easy to just write down gates to do things like the PDP-11's arbitrary addressing modes on two arguments. (It's not impossibly hard, either, but it's a lot more mental overhead than the corresponding process for the 6800.) It wasn't a deep problem, I think, since I got to take a mini-class on it and almost immediately started figuring it out. But it was one of my most memorable mental blocks in my learning to understand computers, and one of the few times I can remember when just going straight for the shortest published treatment (K&R C or Landau and Lifschitz Mechanics or whatever) wasn't the high road to learning something. Today I would try to deal with my mental block by reading a lot of example code and/or looking for another book on the subject. But in 1980 there weren't too many PDP-11 assembly programs or books of PDP-11 assembly language floating around where a high school student could easily find them:-) so the alternative explanation from the course was very valuable. (And my mental sketch of what was going on inside? It ended up becoming something like the cartoon of scientists standing at a blackboard full of equations with "then a miracle occurs" in the middle, except my handwaving in the middle was "here be microcode or something vaguely similar" so "I could wire this up" became "I could more-or-less-microcode this.") Something similar happened much later when I tried to understand lexical closures. For other HLL constructs it hadn't been much of an effort to maintain a mental sketch of an algorithm to recognize and compile the constructs into assembler, but it wasn't so obvious how to handle lexical closures that way. -- William Harold Newman <[EMAIL PROTECTED]> In examining the tasks of software development versus software maintenance, most of the tasks are the same -- except for the additional maintenance task of "understanding the existing product". -- Robert L. Glass, _Facts and Fallacies of Software Engineering_ PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
