From mboxrd@z Thu Jan 1 00:00:00 1970 From: b klein Subject: Re: confused asm newbie Date: Thu, 20 Nov 2003 13:52:01 -0800 (PST) Sender: linux-assembly-owner@vger.kernel.org Message-ID: <20031120215201.81030.qmail@web41306.mail.yahoo.com> References: Mime-Version: 1.0 Return-path: In-Reply-To: List-Id: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-assembly@vger.kernel.org thank you for your answers, philip and fred. they were both insightful and practical. --- Philip Jacob Smith wrote: > >> I know what you mean about those assembly > language > >> books. They try to teach assembly like it's a > >> language, when it's not (despite the "assembly > >> language" name), and so they actually end up > >> teaching how to use one particular assembler > (which > >> is really what you would want to call a language) > >> with one particular operating system, and usually > >> just do a lot of "here's how you do it" stuff and > >> not enough "here's how this works" type stuff. > > To expand on this, I think there are four areas to > assembly language: the instruction set itself, the > operating system, the hardware, and the assembler. > > Every book I've read had an instruction set > reference which gave brief descriptions of the > instructions. However, I think these should include > a bit more than they usually do. Like the > description for the add instruction should explain > how it manages to work correctly on both signed and > unsigned numbers. The jump instructions should > explain that jb/ja are for use with unsigned numbers > and jg/jl are for signed numbers. Yet every time I > see such a listing, it just says "jumps on the > condition that the such and such flags are set." I > don't even know what flags they are, because that > isn't really important. What's important is what > the instruction is useful for, and the jg > instruction is useful for jumping on the condition > that the previous add, sub, or cmp instruction > resulted in a number between 1 and 127 (for bytes, > that is, and I can't say that I know that is > correct, but rather that's just what I always use it > for, rather than check for overflow errors I always > just m! > ake > sure they won't occour in the first place). Telling > me what flags it sets doesn't really tell me > anything. > > Every book I've read deals with just one operating > system. I don't think this is bad, I couldn't > honestly expect anything else. What bothers me is > that they both claim to be about general assembly > langauge (I never saw a book titled "DOS Assembly > Language", always just "Assembly Language") and yet > concentrate heavily on how to get things done under > their one specific operating system. 95% of what > someone reads in a DOS assembly langauge book is > going to be useless for someone in Linux, and so I > think it's rather deceptive to claim that the book > is about assembly langauge when mostly it isn't. My > other complaint here is that pretty much every book > is like this. They'll spend 90% of the book > explaining how to use every DOS interrupt > imaginable, yet they can't squeeze in important > things like how to use the SCASB/CMPSB instructions, > which leads to people brewing up their own wickedly > horrible functions that try to do the same things. > Some books don't even bother with simp! > le ones > like LODSB/STOSB. > > Most books I've read don't deal with hardware much > at all. It's interrupt this and interrupt that. > Now hardware programming is difficult, but it's > exactly that reason that it needs to be in a book. > The books I have seen it in did quite poorly. I > read one book that had a section on VGA and even an > example on using 640x480 16-color mode, and although > the example worked, the textual explanation was so > lacking I had no idea how they did it. I could have > just copied their code and had something that > worked, but that's not why I bought the book. I > bought the book so I could learn to do this stuff > myself, and just using someone else's code isn't > learning. While I'm on this topic, I'll recommend > "The Indispensable PC Hardware Book." This is the > only programming book I've ever bought that I've > kept. All others have either been given away, or if > they were really bad, went into the trash. > > Every book I've read treats the assembler as if it > is assembly language. In my opinion it's just the > opcodes that are assembly language, all of the > directives and the general syntax of the assember > are something else. Books tend not to make any > distinction between the two. The result is that > people read a book on MASM, then switch to NASM, and > wonder why NASM doesn't have "assume", "word ptr", > or why code like "mov eax, data[14]" causes errors, > and in particular wonder why "mov eax, data" doesn't > do what they expect. I've seen people say that the > opcodes are "machine langauge" and that the > mnemonics are "assembly langauge" but that's just > silly. The opcodes are the langauge, it's just that > all those numbers are hard to remember so we gave > them little names, known as mnemonics. Most > assemblers use the same mnemonics, and differ > slightly on their syntax for operands. A good > assembly book would explain this, and would draw a > good line between instructions and directives ! > so that > people understand what gets turned into code and > what's there just to help the assembler out. Most > importantly, it should be understood that the > assembler is a tool, not a programming language. > The assembler translates our mnemonics for us, and > also allows us to use labels instead of hard coded > addresses which would be hard to work with. > > In general, I got into assembly language because I > wanted to deal with all the little details and the > hard stuff, and assembly books all try to generalize > as much as possible and make things as easy as > possible, the end result being that I was always > disappointed. It's as if they didn't actually want > to teach me anything, but rather get me to the point > where I could write _something_ that worked, at > which point they could declare their job complete. > That's not what I like to spend my money on. > > > - > To unsubscribe from this list: send the line > "unsubscribe linux-assembly" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/