Re: I'd like to learn asm...
- From: Herbert Kleebauer <klee@xxxxxxxxx>
- Date: Mon, 01 May 2006 22:39:21 +0200
"randyhyde@xxxxxxxxxxxxx" wrote:
Herbert Kleebauer wrote:
Intel software developer's manual vol 2a: 744 pages
Intel software developer's manual vol 2b: 548 pages
That's a bit more than "a few hundred pages" mind you.
Remove the documentation for FP, MMX, SSE and then recount.
Yes, I know that you recommend using the obsolete 386 version as a
guide. But why should someone give up the 486+ instructions?
Where did I say that you "should give up the 486+ instructions"?
What I say is, that the 386 instruction set is a good start for
learning x86 assembly programming. And once you are familiar with the
386, you can look at the extensions in the newer processors.
The bottom line is that the manufacturer's documentation, while
invaluable, usually contains *far* too much information of a highly
detailed nature.
What is "*far* too much information"? Either it is information
about the behavior of an instruction (then you need this information
for assembly programming) or it is just some text which has nothing
to do with the instruction (then I wouldn't it call "information"
in the context of an instruction description).
This is why trade books on assembly language
programming sell so well -- they skip discussing unimportant
instructions and concentrate on explaining how to use common
instructions to actually *accomplish* something.
It doesn't make any sense to teach 10% of the integer instruction,
10% of FP instructions, 10% of the MMX instructions ....
Better teach 100% of the integer instructions and ignore the
rest for the moment (i.e. start with the 386 instruction set).
This is like reading a manual. It doesn't make any sense to
read only the first chapters until you know enough to use
the tool for simple tasks and only read further chapters if
you are unable to solve a problem with your current
knowledge. You always should read the complete manual (from
the first to the last page) before you even start the tool.
And it doesn't matter if you only understand 20% of what you
are reading. It is essential that you have on overview of all
the features even if you don't understand any details at that
time. But it is unnecessary to read the manuals about all the
existing plug-ins for the tool as long as you don't use them.
So, anyone who wants to learn x86 assembly programming should
read the complete processor manuals (ignoring the FP, MMX, SSE
extensions for the moment) before writing the first line of
assembler code.
2. A book about the OS interface.
most of the information in Petzold's book (or MSDN on-line, if you prefer)
is of little interest to someone learning assembly language.
Yes, it "is of little interest", but still necessary. Assembly programming
means YOU, the PROCESSOR and the OS INTERFACE and nothing else. There
must be no hidden information. This means, you need to understand
each byte the exe file, how the exe file is loaded into memory and
how the API calls works. And all this is much easier with the DOS
interface (or BIOS interface and direct hardware access).
After all, learning the comparable Windows or Linux API calls that do
the same thing as the DOS API is no more work than learning DOS. And in
the end, you've learned something that you can continue to use rather
than wasting your time learning an obsolete OS' API.
It is much better to LEARN and UNDERSTAND something which is
obsolete than just to USE something (without really understanding
it) which is not obsolete. We don't need programmer who are
able to somehow generate working code, we need people who exactly
understand how the code is working.
Of course, you can also bypass the OS's native interface completely and
make calls to a standardized library. This could be the C standard
library (e.g., portable across OSes) or something like the HLA standard
library (portable across Windows and Linux).
That has nothing to do with assembly programming. This is generating
a sequence of library calls using the CPU "call" instruction.
3. A book about the assembler you use (a few dozen of pages)
If the assembler's documentation is only a few dozen pages, then it is
either grossly underdocumented or has so few features that people
should run, not walk, away from the product.
An assembler is a tool which converts a symbolic representation
of CPU instructions, memory addresses and constants into a binary
form and nothing more. Anything else is a programming language which
allows you to include CPU instructions but is inappropriate for
understanding the processor architecture (learning assembly
programing). And for an assembler a few dozen of pages documentation
should be more than enough.
In opposite to the DOS interface, writing applications in assembler
is really obsolete (in the desktop, not in the embedded market). But
learning assembly programming (understanding the processor architecture)
will never be obsolete. So people should run, not walk, away from a
product which tries to promote HL constructs for an assembler. Either
use an optimizing HL languages or pure CPU instructions and then combine
the results (using inline assembly or a linker) but never use a mixture
in one language ("High Level Assembler").
.
- Follow-Ups:
- Re: I'd like to learn asm...
- From: randyhyde@xxxxxxxxxxxxx
- Re: I'd like to learn asm...
- From: Betov
- Re: I'd like to learn asm...
- From: Betov
- Re: I'd like to learn asm...
- References:
- Re: I'd like to learn asm...
- From: randyhyde@xxxxxxxxxxxxx
- Re: I'd like to learn asm...
- Prev by Date: Re: I'm having trouble finding opcodes
- Next by Date: Re: HLA vs ???
- Previous by thread: Re: I'd like to learn asm...
- Next by thread: Re: I'd like to learn asm...
- Index(es):
Relevant Pages
|
