[comp.sys.amiga] 286 features

cmcmanis%pepper@Sun.COM (Chuck McManis) (10/01/88)

In article <2401@hplabsz.HPL.HP.COM> dleigh@hplabsz.UUCP (Darren Leigh) writes:
-> OS/2 will run on any AT class machine (ATs, PS/2s and 386 boxes
-> running in emulation mode) that has enough memory (about 2 MBytes just
-> for the system if I recall -- I wouldn't try running with less than
-> 4).  The 80286 operating in protected mode does have hardware
-> protected memory (thus the name) on a segment by segment basis.
-> Segments may be up to 64K bytes long (ha ha ha ha ha ha . . . ) but
-> can be smaller.  This allows you to have somewhat finely grained
-> protection until you run out of segment descriptors.  The protection
-> works OK for runaway programs, but not for security as I understand it
-> is easy to get around.  Oh, and Jerry's gonna love all those
-> protection violation errors he gets when he trys to write a simple
-> program in C, especially when the the OS spits them out for many
-> reasons.

I can only assume you have never programmed an 80286 or you wouldn't be
quite so smug. True, a segment can be at most 64K bytes long, and true
you can have at most 64K segments, but things are not nearly as gloomy
as you paint them. The protections works exceptionally well for programs
and can be built extremely securely. It is always a question of going
for speed or going for protection. Some OS's such as Microsoft's Xenix
map the kernel in the same address space as the user code, although at
a higher protection level. The only way to call the OS is thru a call
gate and the gate can check for valid parameters on all calls. As for 
running out of descriptors, you may for large programs (large >10Meg)
but I doubt you will hit this limit in practice. With several 10Meg 
programs running you will begin to wonder about how much virtual memory
you will need. Of course this is the upper limit for the '286, but only
midway into the operating range of the '386. 

-> By swapping segments to disk, OS/2 has "virtual memory" (derisive
-> laughter fills the background).  There are some problems though.
-> Since segments are normally 64K bytes in length (way too large) the OS
-> thrashes like mad, and since segments can be less than 64K bytes long,
-> the memory gets fragmented and the OS wastes time copying big chunks
-> of memory around.
-> Darren Leigh -- I speak for myself, not the company.

You do a disservice to yourself when you laugh derisively at segment
swapping. Paged virtual memory is not God's gift to computers, ask a
Cray programmer sometime. And segments aren't "normally" 64K either,
they are often simply the size of the load module. So while it doesn't
give you the granularity of page swapping, it is better than checkpointing
and a damn site better than nothing at all. Secondly, when the 
memory gets fragmented and space needs to be reclaimed, all the CPU
does is a MOVS followed by a change in the Local Descriptor table. Poof!
And your program is never the wiser. 

This is not meant to start a flame war, simply to point out that there
is never any reason to maintain such a negative attitude against any
CPU architecture. They are built different for different reasons, mostly
because they do different things better. They aren't intrinsicly bad or
"funny." One of the more interesting projects one can do on a computer
is to simulate new and different architectures to see what they do well.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

cmcmanis%pepper@UDEL.EDU (10/04/88)

From: Chuck McManis <cmcmanis%pepper@sun.com>
Subject: 286 features
Keywords: OS/2 sucks OS/2 sucks OS/2 sucks OS/2 sucks
Message-ID: <71136@sun.uucp>
Date: 30 Sep 88 21:21:36 GMT
Organization: Sun Microsystems, Mountain View
To:       amiga-relay@UDEL.EDU
Sender:   amiga-relay-request@UDEL.EDU

In article <2401@hplabsz.HPL.HP.COM> dleigh@hplabsz.UUCP (Darren Leigh) writes:
-> OS/2 will run on any AT class machine (ATs, PS/2s and 386 boxes
-> running in emulation mode) that has enough memory (about 2 MBytes just
-> for the system if I recall -- I wouldn't try running with less than
-> 4).  The 80286 operating in protected mode does have hardware
-> protected memory (thus the name) on a segment by segment basis.
-> Segments may be up to 64K bytes long (ha ha ha ha ha ha . . . ) but
-> can be smaller.  This allows you to have somewhat finely grained
-> protection until you run out of segment descriptors.  The protection
-> works OK for runaway programs, but not for security as I understand it
-> is easy to get around.  Oh, and Jerry's gonna love all those
-> protection violation errors he gets when he trys to write a simple
-> program in C, especially when the the OS spits them out for many
-> reasons.

I can only assume you have never programmed an 80286 or you wouldn't be
quite so smug. True, a segment can be at most 64K bytes long, and true
you can have at most 64K segments, but things are not nearly as gloomy
as you paint them. The protections works exceptionally well for programs
and can be built extremely securely. It is always a question of going
for speed or going for protection. Some OS's such as Microsoft's Xenix
map the kernel in the same address space as the user code, although at
a higher protection level. The only way to call the OS is thru a call
gate and the gate can check for valid parameters on all calls. As for
running out of descriptors, you may for large programs (large >10Meg)
but I doubt you will hit this limit in practice. With several 10Meg
programs running you will begin to wonder about how much virtual memory
you will need. Of course this is the upper limit for the '286, but only
midway into the operating range of the '386.

-> By swapping segments to disk, OS/2 has "virtual memory" (derisive
-> laughter fills the background).  There are some problems though.
-> Since segments are normally 64K bytes in length (way too large) the OS
-> thrashes like mad, and since segments can be less than 64K bytes long,
-> the memory gets fragmented and the OS wastes time copying big chunks
-> of memory around.
-> Darren Leigh -- I speak for myself, not the company.

You do a disservice to yourself when you laugh derisively at segment
swapping. Paged virtual memory is not God's gift to computers, ask a
Cray programmer sometime. And segments aren't "normally" 64K either,
they are often simply the size of the load module. So while it doesn't
give you the granularity of page swapping, it is better than checkpointing
and a damn site better than nothing at all. Secondly, when the
memory gets fragmented and space needs to be reclaimed, all the CPU
does is a MOVS followed by a change in the Local Descriptor table. Poof!
And your program is never the wiser.

This is not meant to start a flame war, simply to point out that there

dleigh@hplabsz.HPL.HP.COM (Darren Leigh) (10/04/88)

In article <71136@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <2401@hplabsz.HPL.HP.COM> dleigh@hplabsz.UUCP (Darren Leigh) writes:
>-> [ my ranting and raving on the evils of os/2]

>I can only assume you have never programmed an 80286 or you wouldn't be
>quite so smug. True, a segment can be at most 64K bytes long, and true
>you can have at most 64K segments, but things are not nearly as gloomy
>as you paint them. The protections works exceptionally well for programs
>and can be built extremely securely. It is always a question of going
     ^^^ [note the keyword]
>for speed or going for protection. Some OS's such as Microsoft's Xenix
>map the kernel in the same address space as the user code, although at
>a higher protection level. The only way to call the OS is thru a call
>gate and the gate can check for valid parameters on all calls. As for 
>running out of descriptors, you may for large programs (large >10Meg)
>but I doubt you will hit this limit in practice. With several 10Meg 
>programs running you will begin to wonder about how much virtual memory
>you will need. Of course this is the upper limit for the '286, but only
>midway into the operating range of the '386. 

Chuck, please notice that I wasn't flaming the 80286; my target was
the OS/2 operating system, though some of the flames do rub off on the
286 because the operating system doesn't make such things transparent.
While I have no doubt that the 286 can be properly programmed to avoid
security holes, OS/2 cannot.  That's why OS/2 has been billed as a
multi-tasking but not a multi-user sytem.

>-> By swapping segments to disk, OS/2 has "virtual memory" (derisive
>-> laughter fills the background).  There are some problems though.
>-> Since segments are normally 64K bytes in length (way too large) the OS
>-> thrashes like mad, and since segments can be less than 64K bytes long,
>-> the memory gets fragmented and the OS wastes time copying big chunks
>-> of memory around.
>-> Darren Leigh -- I speak for myself, not the company.
>
>You do a disservice to yourself when you laugh derisively at segment
>swapping. Paged virtual memory is not God's gift to computers, ask a
>Cray programmer sometime. And segments aren't "normally" 64K either,
>they are often simply the size of the load module. So while it doesn't
>give you the granularity of page swapping, it is better than checkpointing
>and a damn site better than nothing at all. Secondly, when the 
>memory gets fragmented and space needs to be reclaimed, all the CPU
>does is a MOVS followed by a change in the Local Descriptor table. Poof!
 ^^^^^^^^^^^^^^ [i.e. wastes time copying chunks of memory around]     
>And your program is never the wiser.

The laughter was over the OS/2 system and not the idea of segment
swapping itself.  I did tests and I have to face reality: virtual
memory under OS/2 is horribly slow and I have reason to believe it is
because of the poor manner in which the segment swapping is
implemented.  I was working on image processing software and had to
deal with large chunks of memory.  As long as we could keep everything
in RAM, the OS/2 version of our software (on a 20 MHz 386 box) ran in
more or less comparable time to the Unix version (on a ~16 MHz 68020).
However, as soon as the virtual memory came into play, the OS/2
version slowed down by over a factor of 40!  The Unix version barely
noticed the change.  When huge blocks of memory are allocated under
OS/2, the segments are always 64K bytes long, except for the last one.
If the 2 Meg OS stays resident that gives us about 32 swappable chunks
of memory on a 4 Meg machine.  Thrashing, anyone?  If we'd really
wanted to go to the trouble, we could have written in assembly and
made the segments very small so that this would have been less of a
problem.  In other words, if we spent a zillion man hours we could
have fine tuned the program to the machine so that it would work in a
usable fashion.  That doesn't say much for portability and
maintainability.  And why should the developer have to go to such
lengths to correct what is obviously a problem with the OS?  OS/2
might be OK running tiny DOS-type programs but a real operating system
it ain't!

>This is not meant to start a flame war, simply to point out that there
>is never any reason to maintain such a negative attitude against any
>CPU architecture. They are built different for different reasons, mostly
>because they do different things better. They aren't intrinsicly bad or
>"funny." One of the more interesting projects one can do on a computer
>is to simulate new and different architectures to see what they do well.

I agree with you, Chuck, but that doesn't mean I'll forgive less than
competent, greed filled companies for the damage they're causing to
the industry.  Yes, the 80286 can be used effectively, but not with
OS/2.  BTW, my big negative attitudes are not maintained against
architectures, they're against managers.  ;-)  But that's another
posting for another group for another time.

========
Darren Leigh -- I speak for myself, not the company.
                (Especially in this posting!)
Internet:  dleigh@hplabs.hp.com
UUCP:      hplabs!dleigh