Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ecsvax.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!ecsvax!hes
From: hes@ecsvax.UUCP (Henry Schaffer)
Newsgroups: net.micro
Subject: Re: Re: 386 Family Products (8086 sucks
Message-ID: <879@ecsvax.UUCP>
Date: Mon, 9-Dec-85 10:30:20 EST
Article-I.D.: ecsvax.879
Posted: Mon Dec  9 10:30:20 1985
Date-Received: Wed, 11-Dec-85 04:13:08 EST
References: <133@daisy.UUCP> <97800013@ima.UUCP> <464@looking.UUCP>
Organization: NC State Univ.
Lines: 40

> In article <97800013@ima.UUCP> johnl@ima.UUCP writes:
> >
> >/* Written  1:44 pm  Dec  3, 1985 by 5@utzoo@ecn-pc in ima:net.micro */
> >Oh, stop it.  It's just not true that existing compilers can hide the 
> >808x's segmentation.
> >...
> >John Levine, ima!johnl
> >
> 
> I'll correct you, because you are wrong.  Our product (A syntax-directed
> programming environment for Pascal) is a 30,000 line program.  Using both
> the Mark Williams C compilers and Microsoft C compilers, this program
> required almost no segment funnies to compile and run in large model.
> ...
> 
> ...  Clean C programs, the kind
> that run properly through LINT, will have no trouble running under the
> 8086 "Large" model if they don't use single objects larger than 64K in
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^    
> size.  Since very few programs do that, your anxiety is excessive.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> -----
> Brad Templeton, Looking Glass Software Ltd. - Waterloo, Ontario 519/884-7473

   I would say that many programs use single objects larger than 64k.  (How big
a double precision floating point matrix fits in 64k?)  Most programs are
(or should be) sufficiently modular that 64k code segments are not much of a
penalty, but in scientific/statistical/simulation computations it is quite
common to have data objects >64k.  (On an 8088/8086 allowing the transparent-
to-the-user use of data objects>64k appears to have an unavoidable and 
significant performance degradation.)
   There may be some language bias here.  Traditionally C has not seen heavy
use in the number-crunching community and so large data objects may not have
been common.  The number-crunching community has primarily used FORTRAN, and
that's where you might see things like:
REAL*8  XPY(2500), XPX(31375)
(which is a quote from one of my programs - where we sometimes have to
increase the dimensions to handle a larger than usual data set!)

--henry schaffer