From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Tue, 15 Sep 1992 10:49:38 GMT

In article <id.E_2T.V5B@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Sep8.081729.2877@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> In article <id.VSXS.W68@ferranti.com> peter@ferranti.com (peter da silva) writes:
>> >Except for the problem caused by the inability to make any substantial
>> >improvements to DOS because it'd break all the critical applications. Microsoft
>> >eventually had to invent not one but *three* new operating systems, and they
>> >*still* have to retain very low level DOS emulation to get any market share.
>> 
>> There are no such systems accepted in the Real World (tm).  Microsoft has
>> been attempting to get OS/2 down the throats of users for years.
>
>That's my POINT.

Then why did you use MY point?

>
>> BTW, much
>> runs on it *slower*, although there are certain applications that are DOS
>> pigs that run better by brute force.
>
>You mean much DOS software runs slower in the DOS emulation box. Yes, I would
>expect that. If the software had been competantly written in an HLL it'd be
>shipping in OS/2 versions with nominal upgrades and this wouldn't be a problem.

No, I mean that there is much commercially successful, yet awfully coded
applications that have OS/2 versions that run better there because it's a
"brute force" kind of improvement for them.  It was never necessary, just
that OS/2 "tolerates" certain kinds of sloppy design better, especially
memory hogs.  (Definition: a memory hog is program that could have been
written to run in substantially less memory, but in fact needs a ton of
memory.  Little is gained if anything by the exorbitant memory space in the 
process.)

>
>> >If your programs were written in high level code, and you'd recompiled them
>> >with a 32-bit compiler, you'd have seen substantial performance improvements.
>> >Native 386 code is so much faster then 8086 or 80286 code that insisting you're
>> >sticking with 8086 because assembler is more *efficient* is insane!
>
>> As has been stated before, the 32-bit mode runs *slower*, not faster.
>
>You stated it. I've measured it. Any substantial program (over 64K of code
>or data) runs many times faster in 32-bit mode than in 16-bit juggle-the-
>registers mode.

Wrong, in that model you use the 286 mode which is faster.  The 386 mode
*always* loses everywhere that *counts*.  Your unix code is an aberration.

>
>If your program is small enough to run in a single segment, you get a win
>for sticking with 16-bit mode. When I worked on DOS I took heroic measures
>to keep my code small enough to do that. But I got tired of playing silly
>games instead of doing productive work.

Any DOS program runs that way.

>
>> All it
>> buys you is a larger, albeit clunkier, address space you may not need.
>> Furthermore, the '286 mode is large enough for any sane program for this
>> class of machine.
>
>286 mode is not one atom better than 86 mode. In fact, because the cost
>of reloading a segment register is higher, it's worse.

And since it runs faster, you just succeed in proving how infrequently it
is doing this "higher speed cost" operation, since you admit there is no
degradation.  Either the bulk of the mode is faster so it at least "is not
one atom better" or the reloading is insignificently performed.  Either way
you lose your point.

>
>Or is "any sane program" under 64K?
>
>> Your colorful language is amusing, but hardly either accurate or relevant.
>> For your info, OS/2 and followons are *compatible* with DOS file structures
>> totally.
>
>Yes, it uses the same file system. But a file system is the smallest part
>of an operating system. OS/2 adds the missing parts: device management,
>scheduling, memory management, and so on. OS/2 is an operating system. It
>doesn't force applications to embed their own operating systems inside just
>to do the job. There is no reason one should have to include the interrupt
>handler for the serial port in a terminal program. But you do under DOS.

Yes, performance-oriented programs under DOS bring in their own interrupt
handlers for the ports, but most of the rest of OS/2 is too gaudy for its
own good.

>
>> None of this has anything whatsoever to do with alleged ease of moving
>> applications from MS-DOS to OS/2 or whatever regardless of what it's
>> written in.
>
>Sure. You can write DOS assembly code that will *run* under OS/2, in some
>16-bit compatibility mode. But it will be (in your words) a dog. OS/2 isn't
>a dog because it's inherently doggy (though I won't debate that: it's a pig),
>but because it's got to support all that old 16-bit-only software.

Wrong, OS/2 v2 from IBM does it a lot better.  Besides, its a task, if you
don't use it, it degrades not at all.

>
>Let me put it this way: my Amiga 1000, with a 7 MHz CPU roughly equivalent
>to an 80286 in CPU power, beats the pants off any DOS-derived OS on any x86
>family processor I've tried them on when it comes to responsiveness. Why?
>
>	1. It doesn't have to retain compatibility with as much old
>	   software.
>
>	2. It doesn't have to retain compatibility with as much old
>	   software.
>
>	3. You get the point.
>
>	4. Oh yeh, a single register can address the whole screen.

Burning bridges always is an attempt to prevent the townspeople from coming
after you as a lynch mob.

Can you address a 1280x1024x256 color screen with one register?

>
>The operating system was designed, first, as a platform for modern multitasking
>applications. Not as something to load code and get out of the way. So all the
>applications expect that environment and behave well.
>
>Oh, by the way... the kernel is in assembly and C, and most of the utilities
>are in C. The shared libraries are mixed.
>
>> In any case, tempest in a teapot arguments aside, you are
>> attempting to characterize something you apparently have no first-hand
>> information on.
>
>Not guilty. I've spent too many years programming DOS. I got out of that.
>
>Now most of my programs run under UNIX and AmigaOS and it just takes a
>recompile. I've ported substantial C software from UNIX to the Amiga. It's
>a whole different world... one where things just work.
>
>> There is more trouble in bringing some hll applications written for older
>> versions of VMS up to newer ones than anything you allude to here.
>
>Possibly true. I'm certainly no fan of VMS.
>
>> As to
>> the size of this so-called prison, there is something wrong if you can't
>> write useful code to run in 1/2 Meg or so.
>
>You mean 64K. Lots of little 64K cells. I'm totally blown away by Microsoft
>Windows... it's a tour-de-force, considering they can't use a pointer that's
>big enough to address a whole screen at once. And it actually ran on the 8088
>(I've done that, too).

.COM files aren't .EXE files, so don't try to make this into an 8085-type
argument.

>
>> If I need to go to OS/2, I'll
>> opt to avoid the overhead of '386 mode, and stick to the "prison" you
>> describe of program space of 16 Megabytes.
>
>64K.

No, 16 Megs in '286 protect mode.  386 mode sucks, even on 486's.

>
>> Your point of recompiling ease really wears thin:  If the program could've
>> fit in the original environment, then it will run in either.  Anyone who
>> uses recent Microsoft or Borland Languages gets for free the ability to
>> not even have to recompile for OS/2.
>
>If they don't mind their programs running like dogs, yes.

Wrong, the alternate entry point fixes up and it runs ok.

>
>> In any case, if I have to make
>> trivial changes, I will.  You have presented literally nothing to convince
>> anyone that the changes are anything but trivial.
>
>64K.

Wrong, 16 Megs

>
>I've been there. It's not worth the pain.
>
>Segments are for worms.
>-- 
>Peter da Silva                                               `-_-'
>Ferranti Intl. Ctls. Corp.                                    'U` 
>Sugar Land, TX  77487-5012
>+1 713 274 5180                                   Har du kramat din varg idag?

You like to "mix and match" arguments from the land of unix-386 code and
then switch to Amiga-love.  Please stay in one box at a time.

cjl

Newsgroups: alt.folklore.computers,comp.windows.misc,comp.windows.x,comp.human-factors