Path: utzoo!attcan!uunet!super!udel!gatech!ukma!rutgers!apple!bionet!agate!ucbvax!hplabs!hplabsz!dleigh From: dleigh@hplabsz.HPL.HP.COM (Darren Leigh) Newsgroups: comp.sys.amiga Subject: Re: 286 features (was: really was about os/2, not 286) Summary: "not a counterflame" in response to "not a flame" Keywords: OS/2 sucks OS/2 sucks OS/2 sucks OS/2 sucks Message-ID: <2410@hplabsz.HPL.HP.COM> Date: 4 Oct 88 00:00:26 GMT References: <5384@fluke.COM> <2401@hplabsz.HPL.HP.COM> <71136@sun.uucp> Reply-To: dleigh@hplabsz.UUCP (Darren Leigh) Organization: National Cholesterol Board Lines: 89 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