From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Newsgroups: alt.folklore.computers,comp.unix.misc
Subject: Re: The need for an assembler (was: Favorite CPU)
Date: 3 Sep 92 09:19:28 GMT
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University

In article <id.7MVS.5EK@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <1992Aug31.162630.23913@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>> This is patently wrong.  I write for the 8086/8088 model as do most people.
>
>I see. You give up about a decimal order of magnitude in performance when
>dealing with objects larger than 64K in a protected mode O/S so you can save
>a factor of *maybe* 2 over C, for the compute-bound portion of your code only,
>on MS-DOS.
>
>> It runs on 8088, 8086, 80186, 80188, 80286, 80386SX, 80386DX, 80486SX,
>> 80486DX, 80486DX2, and about 20 non-Intel clones from AMD, NEC, ULSI, TI,
>> and a few other cpu clone maker's cpu's.
>
>I can guarantee you it won't run on *any* of my 80286 or 80386 or 80486 systems.
>
>But Ckermit will.

Totally incorrect; just setup the descriptor tables and change the directives
and a tiny amount of code and it does run in less time than it takes to
recompile C-Kermit.  BTW, you are apparently ignorant of the dual .EXE files
that implement the hack of dynamically making the changes so programs like
this run under either real or protect mode.  PKZIP, which is largely written
in assembler, and perhaps one of the 10 most popular PC programs there is, 
comes in this format.  The larger model programs have to be changed more,
but there aren't too many of those.  Of course huge programs are written
in protect mode, so what?  At the source-code level this is a non-issue.
Programs will be assembled in the intended mode; you seem to be implying
that there's something beyond the totally mundate in this, which there isn't.
Should a program want to dabble in memory management beyond the confines of
its own space, that's another matter entirely, and there are system calls
to implement that for the hardy few who can't live within a 16 MEgabyte
linear space :-).

In any case, this is again out of context.  There is merely routine model
evolution going on here, not the drastic upheaval the poster was claiming.

As to your claim of an order of magnitude loss of performance, the answer is
that doing it as you would claim can actually cause *loss* of performance.

BTW, OS/2 supports what is known euphimistically as the "High-Performance
File System" option, wherebe the file system is laid out in a way incompatible
with MS-DOS.  Operative word is "option".  It turns out that except for some
potentially troublesome system configurations, the HPFS is actually *slower*
than the DOS structure.

Some early reports of NT are in: it needs much more memory and much more
disk space to run much more slowly what you could do on a lesser machine
with less resources and OS/2.  For many things it's apparently slower than
DOS by a major percentage.  If all of this pans out, then Microsoft may
capture most of the NT market: probabably as much as 99% of the 1/4 of 1% of
the 1% of the PC market that would ever switch from either MS-DOS or DR-DOS.
For the rest, IBM's OS/2 V2 will be fine, and that runs DOS applications fine.

cjl
Newsgroups: alt.folklore.computers,comp.unix.misc