Can anyone point me in the direction of an online asm tut.  I have
found many and they just don't explain enough, about the language
anyway.  I already know how a computer works I just need something to
get me started on the language itself.  And don't point me toward
anything dealing with windows or art of assembler (I've already looked
into that) and I hate microsoft (tell me something I don't know).

Thanks any help would be appreciated.

dahrkon@usa.com (Dahrkon) wrote:
>
>Can anyone point me in the direction of an online asm tut.  I have
>found many and they just don't explain enough, about the language
>anyway.  I already know how a computer works I just need something to
>get me started on the language itself.  And don't point me toward
>anything dealing with windows or art of assembler (I've already looked
>into that) and I hate microsoft (tell me something I don't know).

You're going to have to tell us more about what environment you'll be
programming.

There is no one generic thing that is "assembly language".  To write in
assembler, you need to know two things.  The first is the instruction set
for your processor.  Since you posted to comp.lang.asm.x86, I'll assume you
are programming an x86 chip.  You say you "know how a computer works"; does
that mean you understand the registers (eax, ebx, ecx) and the addressing
modes of the x86?  If not, maybe some of those lower-level tutorials would
be good for you.

The second thing is the syntax for the assembler you'll be using.  With a
few trivial exceptions, a program written for MASM or TASM or NASM or FASM
or A386 or GAS will work ONLY in that one assembler.  The "languages" are
different, even though the instruction set is the same.

Tell us what you'll be writing (for example, 16-bit programs for DOS using
TASM, or 32-bit programs for Linux using gas), and we'll give you advice.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

http://linuxassembly.org perhaps :-)

http://asmjournal.freeservers.com - I think that's the url for the
Assembly Programmers Journal (been ages since the last update)

http://www.hugi.de - Not devoted to assembler, but they've got some nice
goodies in their diskzine. :-)

http://latigo.cjb.net - He's got a few Palm OS asm coding tutorials
there (68k assembly here). Ok so maybe not for the total beginner, but
at least they're introductory, he tries to make comparisons between 68k
syntax and Intel syntax and it ain't M$. There's hardly any Palm OS
assembler tutorials out there unfortunately.

Dahrkon wrote:
 > Can anyone point me in the direction of an online asm tut.  I have
 > found many and they just don't explain enough, about the language
 > anyway.  I already know how a computer works I just need something to
 > get me started on the language itself.  And don't point me toward
 > anything dealing with windows or art of assembler (I've already looked
 > into that) and I hate microsoft (tell me something I don't know).
 >
 > Thanks any help would be appreciated.
 >

Dahrkon wrote:

> Can anyone point me in the direction of an online asm tut.  I have
> found many and they just don't explain enough, about the language
> anyway.  I already know how a computer works I just need something to
> get me started on the language itself.  And don't point me toward
> anything dealing with windows or art of assembler (I've already looked
> into that) and I hate microsoft (tell me something I don't know).
> 
> Thanks any help would be appreciated.

I've been reading several tutorials for a while but I found it tricky to
'jump in' and start coding (it is usually the little details, such as
syntax, rather than the concepts which were confusing).

Recently though, I've been using NASM on Linux and I am beginning to write
my own mini-library to interface with Linux system calls. This was from a
tutorial on LinuxAssembly.org.

I've also had some fun writing an interface to the screen memory in text
mode in C and inline assembly. This is with Turbo C++ in DOS. C is a good
language to know if you want to learn assembly because you can draw
parallels between low and high level concepts, and you might even become a
better C programmer.

Macros are really great because they save a lot of typing ;) But every
assembler has their own way of doing things. So my advice is to choose one
assembler (e.g. NASM) and learn with that. I made the mistake early on to
switch between different assemblers - NASM, TASM, FASM - I didn't get
anywhere like this.

Luke

Luke McCarthy <luke@ukonline.co.uk> wrote:

>Dahrkon wrote:
>
>> Can anyone point me in the direction of an online asm tut.  I have
>> found many and they just don't explain enough, about the language
>> anyway.  I already know how a computer works I just need something to
>> get me started on the language itself.  And don't point me toward
>> anything dealing with windows or art of assembler (I've already looked
>> into that) and I hate microsoft (tell me something I don't know).
>> 
>> Thanks any help would be appreciated.

Apologies to Luke.

Stop looking for stuff to teach you..
You've already passed up the BEST stuff.

Learn to use bat files..
Learn to use MASM..
Forget about EXEs (for a while)
here's the bat file I use..
It's named  makecom.bat

@ECHO OFF
masm %1,,,;
REM     Takes: .ASM     Makes:  .OBJ, .LST, .CRF
pause
cref %1;
REM     Takes: .CRF     Makes: .REF
link %1,%1,%1/m;
REM     Takes: .OBJ, CRF  Makes: .MAP, .EXE
exe2bin %1 %1.com
REM     Takes: .EXE     Makes: .COM
REM     Only .OBJ, and .CRF     (From MASM) are needed

PAUSE
del    %1.OBJ
del    %1.LST
del    %1.CRF
del    %1.REF
del    %1.MAP
del    %1.EXE

To use it:
have a text file named  whatever.asm
At the DOS prompt type

makecom whatever

Done deal..
What to see the "crap"?
put REM infront of the  "del"..
They're all text files except the .EXE (of course)
Note: It isn't executable

The %1's show that many of the "utilities"
don't need or want an extension..
They know what the required extension IS..!!!

Is that what you mean by "The language itself".

P.S.
Every one of these pgms used in (by) MASM can be
run from the command line..
I find it confusing so I use the batch file approach.
Learn how to read what it's doing...

Do you REALLY know How a cumputer works?
"A pessimist sees the difficulty in every opportunity;
an optimist sees the opportunity in every difficulty."
Sir Winston Churchill (1874-1965)

This is the best full online manual and assembler tutorial:

http://www.emu8086.com/Help/index.html

included complete 8086 instruction set.

emulizer_x86 wrote:
> This is the best full online manual and assembler tutorial

I see a tiny conflict of interest here. Are you recommending your
work as the best available?

Hi!

I usually use TASM when I fool around with 16-bit DOS-based Asm because I'm
still a newbie, but what I'd really like to know is what you use the .OBJ,
..MAP, .LST, and .CRF files for.

-NiCk


"mchiper" <notnuts@yahoo.com> wrote in message
news:ntfthvod4o6696jg1gjop9s2nn98ha0skq@4ax.com...
> Luke McCarthy <luke@ukonline.co.uk> wrote:
>
> >Dahrkon wrote:
> >
> >> Can anyone point me in the direction of an online asm tut.  I have
> >> found many and they just don't explain enough, about the language
> >> anyway.  I already know how a computer works I just need something to
> >> get me started on the language itself.  And don't point me toward
> >> anything dealing with windows or art of assembler (I've already looked
> >> into that) and I hate microsoft (tell me something I don't know).
> >>
> >> Thanks any help would be appreciated.
>
> Apologies to Luke.
>
> Stop looking for stuff to teach you..
> You've already passed up the BEST stuff.
>
> Learn to use bat files..
> Learn to use MASM..
> Forget about EXEs (for a while)
> here's the bat file I use..
> It's named  makecom.bat
>
> @ECHO OFF
> masm %1,,,;
> REM     Takes: .ASM     Makes:  .OBJ, .LST, .CRF
> pause
> cref %1;
> REM     Takes: .CRF     Makes: .REF
> link %1,%1,%1/m;
> REM     Takes: .OBJ, CRF  Makes: .MAP, .EXE
> exe2bin %1 %1.com
> REM     Takes: .EXE     Makes: .COM
> REM     Only .OBJ, and .CRF     (From MASM) are needed
>
> PAUSE
> del    %1.OBJ
> del    %1.LST
> del    %1.CRF
> del    %1.REF
> del    %1.MAP
> del    %1.EXE
>
> To use it:
> have a text file named  whatever.asm
> At the DOS prompt type
>
> makecom whatever
>
> Done deal..
> What to see the "crap"?
> put REM infront of the  "del"..
> They're all text files except the .EXE (of course)
> Note: It isn't executable
>
> The %1's show that many of the "utilities"
> don't need or want an extension..
> They know what the required extension IS..!!!
>
> Is that what you mean by "The language itself".
>
> P.S.
> Every one of these pgms used in (by) MASM can be
> run from the command line..
> I find it confusing so I use the batch file approach.
> Learn how to read what it's doing...
>
> Do you REALLY know How a cumputer works?
> "A pessimist sees the difficulty in every opportunity;
> an optimist sees the opportunity in every difficulty."
> Sir Winston Churchill (1874-1965)
>

"_.-=<[ { E v E r E a d y } ]>=-._" <nospam@redhat.com> wrote:
>
>I usually use TASM when I fool around with 16-bit DOS-based Asm because I'm
>still a newbie, but what I'd really like to know is what you use the .OBJ,
>.MAP, .LST, and .CRF files for.

..OBJ contains the assembled machine code for this module.  The linker takes
your .OBJ, possibly combines it with some libraries, and produces an
executable.

..MAP is the load map produced by the linker, which tells you whic modules
and symbols are loaded where in memory.

..LST is a pretty listing of your program, usually with the object code
shown as well.

..CRF is a cross-reference listing produced by the assembler.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

Ok it's me again.  I want to learn assembler from the ground up.  I
know how a computer works.  i.e. (bin,hex,blah,blah).  Right now I'm
using NASM for linux i have others but this one seems to be the one i
like.  I've been to all the sights everyone has posted.  I will not
take info for any type of windows.  I am using the 8086 instruction
set. (but once you learn one the others will be easy to learn)..  That
enough info?

dahrkon@usa.com (Dahrkon) wrote:

>Ok it's me again.  I want to learn assembler from the ground up.  I
>know how a computer works.  i.e. (bin,hex,blah,blah).  Right now I'm
>using NASM for linux i have others but this one seems to be the one i
>like.  I've been to all the sights everyone has posted.  I will not
>take info for any type of windows.  I am using the 8086 instruction
>set. (but once you learn one the others will be easy to learn)..  That
>enough info?

If you're writing for Linux, then you're using the 80386 instruction set.
Unless you use a DOS emulator (of which there are several), Linux programs
are always 32-bit.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

Tim Roberts <timr@probo.com> wrote in message news:<bifgkvg1shd4bbknlrq30r5dr8g28e4e2a@4ax.com>...
> dahrkon@usa.com (Dahrkon) wrote:
> 
> >Ok it's me again.  I want to learn assembler from the ground up.  I
> >know how a computer works.  i.e. (bin,hex,blah,blah).  Right now I'm
> >using NASM for linux i have others but this one seems to be the one i
> >like.  I've been to all the sights everyone has posted.  I will not
> >take info for any type of windows.  I am using the 8086 instruction
> >set. (but once you learn one the others will be easy to learn)..  That
> >enough info?
> 
> If you're writing for Linux, then you're using the 80386 instruction set.
> Unless you use a DOS emulator (of which there are several), Linux programs
> are always 32-bit.

"If you're writing for Linux, then you're using the 80386 instruction set."
Sorry I meant 80x86

dahrkon@usa.com (Dahrkon) wrote in message news:<cd1a9339.0308240135.27960c8@posting.google.com>...
> Tim Roberts <timr@probo.com> wrote in message news:<bifgkvg1shd4bbknlrq30r5dr8g28e4e2a@4ax.com>...
> > If you're writing for Linux, then you're using the 80386 instruction set.
> > Unless you use a DOS emulator (of which there are several), Linux programs
> > are always 32-bit.
> 
> "If you're writing for Linux, then you're using the 80386 instruction set."
> Sorry I meant 80x86

I still think you're not quite getting it: Linux requires an 80386 or
better CPU. It cannot run on an 80286, for example, because it
requires the protected mode addressing introduced with the 80386.
Since the 80386 is a 32-bit CPU (as opposed to the 16-bit 80286 and
8088), Linux is written completely in 32-bit code. Granted, most of
that code is C which gets compiled to 32-bit assembly, but the basic
idea is that when you're programming for Linux, you can forget about
segment registers (can't touch them in protected mode) and all of the
restrictions placed on the 16-bit Intel chips that didn't carry over
into the 32-bit generation (like not being able to use eax as an index
into RAM, for example).

Now, a brief message from someone with some experience: Forget about
using the GNU Assembler. It is the backend to the GNU Compiler
Collection's frontends, and is not meant for humans to program
directly. (It lacks a friendly way to point out errors, because it
expects its code to be machine-produced and error-free.) Its AT&T
syntax is ugly and, IMNSHO, barely human-readable, and it requires you
to type line noise just to code an immediate variable. Get NASM, the
open-source assembler for all x86 OSes (from DOS to Linux and the
BSDs), which uses a very no-nonsense, very clean Intel syntax.

1.  Who uses a i286 anymore?
2.  Did I say I even liked the GNU Assembler?
3.  I only use NASM and others that are as good as it.
4.  Forget I asked anything.

"Dahrkon" <dahrkon@usa.com> wrote in message news:cd1a9339.0309031755.71968b1f@posting.google.com...
> 1.  Who uses a i286 anymore?
> 2.  Did I say I even liked the GNU Assembler?
> 3.  I only use NASM and others that are as good as it.
> 4.  Forget I asked anything.
>

This is the second posting of your's that I've read to
which you've responded rather rudely.
Quite frankly, if you're expecting help from people,
a little more civility would be a wise idea.
Cheers,
Randy Hyde

On Fri, 05 Sep 2003 02:36:04 GMT
"Randall Hyde" <randyhyde@earthlink.net> wrote:

:This is the second posting of your's that I've read to
:which you've responded rather rudely.
:Quite frankly, if you're expecting help from people,
:a little more civility would be a wise idea.

Maybe he thinks that we are getting paid to help him. If so, I wish I knew
where to send the bill.

-- Chuck

> :This is the second posting of your's that I've read to
> :which you've responded rather rudely.
> :Quite frankly, if you're expecting help from people,
> :a little more civility would be a wise idea.
>
> Maybe he thinks that we are getting paid to help him. If so, I wish I knew
> where to send the bill.
>

see if he has a paypal account on his posting email address

Alright listen.  I apologize for being rude.  I just want the info I'm
looking for.  I know I may not post all of it the first time, but I do
try to post as much as possible.  I don't care why I should not want
to get into this.  And I don't want anyting dealing with Microsoft
Windows in any way even if its an example because I will not use it. 
I have seen most of the information on this topic on the internet and
I am not satisfied (or maybe its not enough who knows).  I just want
as much info as possible on the topic at hand.  Once again I apologize
for my rudeness.


Dahrkon

August Derleth wrote:

>> "If you're writing for Linux, then you're using the 80386 instruction
>> set." Sorry I meant 80x86
> 
> I still think you're not quite getting it: Linux requires an 80386 or
> better CPU. It cannot run on an 80286, for example, because it
> requires the protected mode addressing introduced with the 80386.

Out of curiosity, I'm wondering if you're talking about virtual memory and
the virtual 8086 emulation aspect of 386 protected mode, since the 286 does
have a protected mode.

I'm actually interested in what exactly about the 386 protected mode early
Linux utilized, since the very first versions of Linux didn't have virtual
memory (I'm talking pre-pre-1.0 :) ).  Linus wrote Linux to experiment with
the 386, but was that because the 386 was the newest chip from Intel, or
because he wanted the 32-bit address/data bus, or what?  He didn't have
virtual memory in the beginning, and I'm not sure why he would need to 8086
mode.  I know that he started off testing the 386's ability to multi-task,
but I'm not sure the 386 could truly multi-task, just as the 286 couldn't
truly multi-task, though both could appear to.  Granted, this still means
that Linux requires 80386 or better because it was written for the 386 (in
fact, Linus didn't think Linux would be portable because it utilized so
much of the 386 instruction set) and it uses 32-bit registers and what not,
but I'm interested in knowing why it had to be 386 protected mode and not
286 protected mode.


thanks...
trey

"trey" <nowhere@foobar.com> wrote in message
news:-tWdncydG-AMG8aiU-KYgw@comcast.com...
> August Derleth wrote:
>
> >> "If you're writing for Linux, then you're using the 80386 instruction
> >> set." Sorry I meant 80x86
> >
> > I still think you're not quite getting it: Linux requires an 80386 or
> > better CPU. It cannot run on an 80286, for example, because it
> > requires the protected mode addressing introduced with the 80386.
>
> Out of curiosity, I'm wondering if you're talking about virtual memory and
> the virtual 8086 emulation aspect of 386 protected mode, since the 286
does
> have a protected mode.
>
> I'm actually interested in what exactly about the 386 protected mode early
> Linux utilized, since the very first versions of Linux didn't have virtual
> memory (I'm talking pre-pre-1.0 :) ).  Linus wrote Linux to experiment
with
> the 386, but was that because the 386 was the newest chip from Intel, or
> because he wanted the 32-bit address/data bus, or what?  He didn't have
> virtual memory in the beginning, and I'm not sure why he would need to
8086
> mode.  I know that he started off testing the 386's ability to multi-task,
> but I'm not sure the 386 could truly multi-task, just as the 286 couldn't
> truly multi-task, though both could appear to.  Granted, this still means

Multi-tasking is a property of the operating system, not the chip; it's
possible to write a multi-tasker for processors that don't support
interrupts, either software or externally generated; but the x86 has always
had both.

> that Linux requires 80386 or better because it was written for the 386 (in
> fact, Linus didn't think Linux would be portable because it utilized so
> much of the 386 instruction set) and it uses 32-bit registers and what
not,
> but I'm interested in knowing why it had to be 386 protected mode and not
> 286 protected mode.
>
>
> thanks...
> trey
>
>

-- 
Regards
Alex McDonald

On Mon, 08 Sep 2003 02:21:00 GMT
"Randall Hyde" <randyhyde@earthlink.net> wrote:

:Or use GDB under Linux.

Or, indeed, any appropriate debugger for the OS of ones choice. However,
using gdb as a hex editor is a somewhat like using a canon to shoot a
mosquito. Under Linux, khexedit would be a lot easier.

-- Chuck
 

 In comp.lang.asm.x86,    Msg ID: <bg8qhc$h1p12@news.emirates.net.ae>
 "_.-=<[ { E v E r E a d y } ]>=-._" <nospam@redhat.com>, wrote:

>Hi!
>
>I usually use TASM when I fool around with 16-bit DOS-based Asm because I'm
>still a newbie, but what I'd really like to know is what you use the .OBJ,
>.MAP, .LST, and .CRF files for.

Read for yourself in ASM.BAT
Takes  Fname (.asm)  Makes Fname.COM

@ECHO OFF
masm %1,,,;
REM     Takes: .ASM     Makes:  .OBJ, .LST, .CRF
pause
cref %1;
REM     Takes: .CRF     Makes: .REF
link %1,%1,%1/m;
REM     Takes: .OBJ, CRF  Makes: .MAP, .EXE
exe2bin %1 %1.com
REM     Takes: .EXE     Makes: .COM
REM     Only .OBJ, and .CRF     (From MASM) are needed

PAUSE
del    %1.OBJ
del    %1.LST
del    %1.CRF
del    %1.REF
del    %1.MAP
del    %1.EXE

--
Ray

 In comp.lang.asm.x86,    Msg ID: <bjgddc$k4b$1@titan.btinternet.com>
 "Alex McDonald" <alex_mcd@btopenworld.com>, wrote:

Alex..
I  believe that every day English can be used to aid understanding.

>Multi-tasking is a property of the operating system, not the chip; it's
>possible to write a multi-tasker for processors that don't support
>interrupts, either software or externally generated; but the x86 has always
>had both.
Re:  the chip. From the Intel 386 microprocessor. 
Does RTFM apply?

- Very Large Address space
  4 Gigabyte physical
  64 Terabyte Virtual
(Not to be confused with distinct I/O Address space)
And 4 Gigabyte Maximum Segment size 
Or one hell of a .COM program (I think)
Integrated Virtual Memory Support
Obj code compatabile with 8086 family.
Software: C,PL/M, Assembler System Generation Tools.
- Debuggers: PScope, ICE-386
The ...architecture includes,..,advanced multitasking hardware
and a protection system to support OSs.
It would appear to be a property of the chip that OSs may choose
to use or ignore.

I think this small distinction makes all the difference.
Mainly because the OS is software, and software CAN
and often DOES foil software, but NOTHING can foil hardware.


So then, contrary to appearances, I can rest assured that a microprocessor
can only execute ONE instuction at a time. 
- Not withstanding pipelined Instruction Execution.
 - Or any any other attempt to predict the result that is yet TBD.

Hardware just doesn't seem to know a thing about "smoke and mirrors".
 ( The efforts of programmers, not withstanding. :)

And that while appearances can be deceiving because they
are just as busy doing nothing, as they are doing something.
(Interrupts not withstanding.)

Which doesn't mean that multiple "tasks" aren't being performed.
It's just that the CPU is only one of several microprocessors in a PC.
A Numeric Co-Processor is only one example.
It would really be in BIG trouble if it needed to keep up with putting
pixels on my video display.

IOW the only task they have is to keep on executing
instructions the program in memory (real memory) 
Unless a hardware interrupt occurs, which the software
had best be prepared to deal with.

It is after all an programmable computer.
Whch is designed to load programs into memory, there to be executed.
Whether from tape, CD, floppy or disk.
Or network.... Who cares!!! It's a program.

>> that Linux requires 80386 or better because it was written for the 386 
That makes sense to me..

>(in fact, Linus didn't think Linux would be portable because it utilized so
>> much of the 386 instruction set) and it uses 32-bit registers and what not,
>> but I'm interested in knowing why it had to be 386 protected mode and not
>> 286 protected mode.

Interesting:
Of the 80x86 CPUs  Inafe info on  ( ), 2, and 3
Only the 80286 Says:
Industry Standard OS Support
IRMX, XENIX, UNIX, and MS-DOS..

I guess with Windoz, it's the other way around.
M$oft now decides which CPUs it supports. :)
--
Ray

"mchiper" <notnuts@yahoo.com> wrote in message
news:qi5snvkfpg9u8gijo5hpapl5unpt94e0rc@4ax.com...
>
>  In comp.lang.asm.x86,    Msg ID: <bjgddc$k4b$1@titan.btinternet.com>
>  "Alex McDonald" <alex_mcd@btopenworld.com>, wrote:
>
> Alex..
> I  believe that every day English can be used to aid understanding.

I will help you.

>
> >Multi-tasking is a property of the operating system, not the chip; it's
> >possible to write a multi-tasker for processors that don't support
> >interrupts, either software or externally generated; but the x86 has
always
> >had both.
> Re:  the chip. From the Intel 386 microprocessor.
> Does RTFM apply?

I have read the manuals. You will find later versions for the 486 and above
at www.intel.com. I suggest you RTFM that is more up to date.

>
> - Very Large Address space
>   4 Gigabyte physical
>   64 Terabyte Virtual
> (Not to be confused with distinct I/O Address space)
> And 4 Gigabyte Maximum Segment size
> Or one hell of a .COM program (I think)

No. COM programs are DOS 16 bit programs; there's a maximum of 1Mb
addressable using a 20 bit address (a 16bit mode segment register:address
combination generates 20 bits).

> Integrated Virtual Memory Support
> Obj code compatabile with 8086 family.
> Software: C,PL/M, Assembler System Generation Tools.
> - Debuggers: PScope, ICE-386
> The ...architecture includes,..,advanced multitasking hardware
> and a protection system to support OSs.
> It would appear to be a property of the chip that OSs may choose
> to use or ignore.

Yes. DOS ignores it, for instance, because it is backward compatible with
the 8086 which had none of these features.

>
> I think this small distinction makes all the difference.
> Mainly because the OS is software, and software CAN
> and often DOES foil software, but NOTHING can foil hardware.

I don't understand the "NOTHING can foil hardware" reference.

It is possible to write multitasking OSes for
hardware that does not have multitasking support. There have been many such
systems, on several hardware types. To repeat my original statement;
"Multitasking is a feature of the operating system (the software), not the
chip."

>
>
> So then, contrary to appearances, I can rest assured that a microprocessor
> can only execute ONE instuction at a time.
> - Not withstanding pipelined Instruction Execution.
>  - Or any any other attempt to predict the result that is yet TBD.

That might be true of the 386; but hyper-threading on the P4 and
multiprocessor systems do execute several instructions in parallel. Other
architectures uses multiple execution units and can do something known as
"branch prediction" or "predictive scheduling". Several instructions can and
will execute in parallel in all these architectures.

>
> Hardware just doesn't seem to know a thing about "smoke and mirrors".
>  ( The efforts of programmers, not withstanding. :)

Sorry, you've lost me.

>
> And that while appearances can be deceiving because they
> are just as busy doing nothing, as they are doing something.
> (Interrupts not withstanding.)

No; processors can and do stop. See the x86 HLT instruction. Not all
operating systems support halting; the chip certainly does.

>
> Which doesn't mean that multiple "tasks" aren't being performed.
> It's just that the CPU is only one of several microprocessors in a PC.
> A Numeric Co-Processor is only one example.
> It would really be in BIG trouble if it needed to keep up with putting
> pixels on my video display.

You are confusing software tasks with dividing hardware tasks between
specialised processors.

>
> IOW the only task they have is to keep on executing
> instructions the program in memory (real memory)
> Unless a hardware interrupt occurs, which the software
> had best be prepared to deal with.
>
> It is after all an programmable computer.
> Whch is designed to load programs into memory, there to be executed.
> Whether from tape, CD, floppy or disk.
> Or network.... Who cares!!! It's a program.

I think you are confused about multi-tasking, perhaps because of a DOS
background. Multi-tasking uses the waits that are a feature of most programs
to run other tasks. Normally, the operating system does this for the user
transparently.

An example. Task A runs until it needs to do I/O; the OS schedules the I/O
(to another chip). Rather than wait and waste time, the OS saves the state
of task A, and runs task B. When the I/O completes, the I/O chip interrupts
the CPU, which signals the OS. The OS then saves the state of task B, and
continues with task A. This is interrupt driven multi-tasking. You are right
that the processor is executing one instruction at a time on most x86 chips,
but the speed with which it works makes it _look_ like task A and task B are
operating simultaneously. To prevent a single task hogging the system (for
instance, it may be doing a long computation with no I/O), the OS normally
gives each task a time-slice, and will switch tasks when the time-slice is
up.

On multi-processor systems, there can be as many tasks running in parallel
as there are processors. Hyperthreading is a special case of parallel
running of tasks on a single processor. The same techniques that are used on
a single processor are used on a multi-processor system; so we can run
several tasks that _look_ like they are simultaneously executing; only 2
(for a 2 processor system) will be in fact truly running together.
Multi-processor multi-tasking operating systems are more complex than
uniprocessor multi-tasking operating systems.

These descriptions assume that the processor is interrupt driven, like the
x86 range. Some chips are not. It is still possible to write a multi-tasking
OS
for these kind of chips. It is sometimes called co-operative multi-tasking
as each task has to relinquish control to the OS on a regular basis to allow
other tasks to run. Again, they only appear to be executing simultaneously
due to the speed of the processor.

I said "it's possible to write a multi-tasker for processors that don't
support interrupts, either software or externally generated". I hope that
this longer description of co-operative multi-tasking clarifies it.

This is a simplified description; there are many sources on the net that
describe this in much more detail.

>
> >> that Linux requires 80386 or better because it was written for the 386
> That makes sense to me..
>
> >(in fact, Linus didn't think Linux would be portable because it utilized
so
> >> much of the 386 instruction set) and it uses 32-bit registers and what
not,
> >> but I'm interested in knowing why it had to be 386 protected mode and
not
> >> 286 protected mode.
>
> Interesting:
> Of the 80x86 CPUs  Inafe info on  ( ), 2, and 3
> Only the 80286 Says:
> Industry Standard OS Support
> IRMX, XENIX, UNIX, and MS-DOS..
>
> I guess with Windoz, it's the other way around.
> M$oft now decides which CPUs it supports. :)

That has always been the case. Writing an operating system is a long, large
and
expensive undertaking, and the investment requires that the chip is popular.
The 80286 and 80386 have been out of production for several years now, and
there is no current Microsoft operating system that will run on them. The
last MS OS for the 80286 was Windows3.1 IIRC.

Incidentally, Windows3.1 was a _co-operative_ multitasking OS built over
DOS.

-- 
Regards
Alex McDonald