Re: I'd like to learn asm...

"randyhyde@xxxxxxxxxxxxx" wrote:
Herbert Kleebauer wrote:

I don't have the time to answer in detail, so only a few remarks:

While we're at it, remove all the system (protected-mode) instructions,
too.

That would be a very bad idea, because this is an important part of
the processor architecture. That's also a reason why you should learn
assembly programming in real mode DOS, so you are able to use these
instructions.


But that's exactly what trade books do. And on top of it, those trade
books explain how to actually *use* the machine instructions to
accomplish useful work. Something the manufacturers documentation does
not.

If someone wants to learn how his car works, for what all the buttons and
switches are and he is taught, how he best drive from Washington to New York,
then this is as sad as when somebody wants to understand the processor
architecture and he is told how to implement an algorithm using a subset
of the CPU 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.

Okay. So read a couple hundred pages and then 1,500 pages more?

Our whole life is nothing but learning. But it is essential to do
it in the right order.


What is "*far* too much information"? Either it is information

Well, let's consider the most often-used machine instruction: MOV.

Here's some of the information included in the Intel documentation for
MOV:
(and continuing on and on)

You won't tell me, that you teach them that a "mov" instructions copies
some information from one location to an other location? That already says
the name. The interesting part is all this additional information. And
even if the don't understand most of it when reading it the first time,
they are aware that there is so much additional information which
maybe is essential at later time.


instruction? Most people don't care at all until an exception occurs.
THEN they look it up in the manual.

To look it up, you must be aware that there is something to look up.
And therefore it is important to read first through the complete
manual even if you understand nothing at all.


Better teach 100% of the integer instructions and ignore the
rest for the moment (i.e. start with the 386 instruction set).

Really? What good are instructions like LAR and LSL going to do the
beginner who is first learning assembly language?

That's the same as with a spoken language. In your mother language
you have a very big vocabulary because you hear all the words from
the beginning, even if you don't understand them first. In a foreign
language you start with a very limited vocabulary and you always try to
express yourself with this limited vocabulary and will add new words
only if there is no way to express it with the already known words.


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

Really? It's essential for someone to read about the LAR or INVLPG
instructions before they use the MOV instruction?

Read yes, understand no.


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.

This completely contradicts what you've just said.

No. If you learn your mother language as a small child, it is
essential that you here all the words commonly used (the 386
instruction set). It is not necessary that you also here
all the words of special fields, like the language of lawyers,
medic doctors or chemists (FP, MMX, SSE).


That has nothing to do with assembly programming.

Neither does the OS API. But you keep bringing that up. The OS API is
just an abstraction of the underlying hardware. So why not abstract the
OS API while we're at it?

This is generating
a sequence of library calls using the CPU "call" instruction.

So? What do you think an OS API *CALL* is?

Exactly this is, what they should learn: an OS call is not just
a simple call like a call of a library function. If you "call"
a function, then the instructions of the called function are executed
in the same context as the calling function which means, that
a user mode program will never be able to do some IO (read a
file or keyboard) by just "calling" a subroutine (somewhere
in this subroutine there has to be a "real" OS call, which isn't
a "call" instruction).



But
learning assembly programming (understanding the processor architecture)
will never be obsolete.

Of course, this is why most Universities and Colleges still require
students to take an assembly language programming course.

So as long as you're learning, why not learn it with a tool that makes
your knowledge practical, in case you really *need* to use assembly
once in a while? This is a major student complaint: why should I be
learning this "obsolete" information involving DOS? OTOH, teach them
the same exact material under Windows or Linux and they're much more
motivated.

Why do you learn how to add and multiply numbers when you later
only use a pocket calculator? In the days of the slide rulers, students
had a feeling for numbers, but in these days they only enter numbers
into the pocket calculator and get some results on the display. And
they don't even notice if the displayed result is many magnitudes away
from the correct result.
.