Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #168514

Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?)

From scott@slp53.sl.home (Scott Lurndal)
Subject Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?)
Newsgroups comp.lang.c
References (2 earlier) <8807121629.AA07169@explorer.dgp.toronto.edu> <2807@ttrdc.UUCP> <853b5253-ab29-4e38-9e81-a1d9312e5e2dn@googlegroups.com> <tn5dik$1duv$1@gioia.aioe.org> <tn836b$29sga$5@dont-email.me>
Message-ID <ePMlL.4001$jiuc.583@fx44.iad> (permalink)
Organization UsenetServer - www.usenetserver.com
Date 2022-12-12 21:12 +0000

Show all headers | View raw


Lynn McGuire <lynnmcguire5@gmail.com> writes:
>On 12/11/2022 2:12 PM, antispam@math.uni.wroc.pl wrote:
>> KP2 KP2 <jungletrain@outlook.com> wrote:
>>> On Sunday, July 17, 1988 at 11:40:08 AM UTC-7, Daniel R. Levy wrote:
>>>> In article <880712162...@explorer.dgp.toronto.edu>, fl...@dgp.toronto.edu (Alan J Rosenthal) writes:
>>>>> [a certain MS-DOS C compiler can't compile an array larger than a segment]
>>>>> MS-DOS C compilers seem only to accept a subset
>>>>> of the C language because it allows them to compile certain benchmarks
>>>>> into faster code.
>>>> Accepting a "subset of the C language," as you put it, might make it EASIER
>>>> to write a PC compiler in order to compiler "certain benchmarks" faster, etc.,
>>>> but it's not NECESSARY. In the example you cited, there's nothing that would
>>>> theoretically keep the compiler from having the smarts to generate fast code to
>>>> do well by the small arrays in benchmarks and slower but working code for
>>>> larger, multi-segment arrays. Now the COMPILER might then be slower, but
>>>> that's another story.
>>>> -- 
>>>> |------------Dan Levy------------| THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
>>>> | AT&T Data Systems Group | AND ARE NOT TO BE IMPUTED TO AT&T.
>>>> | Skokie, Illinois |
>>>> |-----Path: att!ttbcad!levy-----|
>>> How is it today?
>> 
>> a) Dan Levy was wrong.  In C arrays are closely tied to pointers
>>     and typically supported separate compilation.  Given that it
>>     is impossible to enlarge some arrays without giving the same
>>     treatment to all non-local arrays, that is slowing down most
>>     (or all) array operations.  One could try better handling
>>     whole program at once, essentially rewriting program into
>>     more efficient one.  IIUC there were several attempts to
>>     do things in this spirit (not limited to DOS array problem),
>>     but nothing working come out.
>> b) DOS compilers had "memory models". "Huge" memory model allowed
>>     arrays bigger than segment.  I am not sure when huge memory model
>>     was available first, but I suspect that before 1988.
>> c) We have standard now.  Standard allows limit on size of "objects".
>>     IIUC if only "trouble" with compiler is limit on size of arrays,
>>     then it is standard compiliant now (so no talk about "subset").
>> d) DOS segments is now history/computer archeology.
>> e) There are small machines (MCU-s) and C compilers targeting them.
>>     If machine has 64kB memory you can make compiler that meets
>>     standard requirements on size of "objects" (it is likely that
>>     you will have to run compiler on different, bigger machine).
>
>Are 16 bit segments totally out of usage now for 8086 and 80286 chips ? 
>I am not sure what MCU-s and IIUC are.

8086/80286 chips have been obsolete for almost 40 years now.

There is no useful software using segments on the x86 family of chips.

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) KP2 KP2 <jungletrain@outlook.com> - 2022-12-10 13:06 -0800
  Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Lynn McGuire <lynnmcguire5@gmail.com> - 2022-12-10 20:57 -0600
    Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Lynn McGuire <lynnmcguire5@gmail.com> - 2022-12-10 22:57 -0600
    Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) antispam@math.uni.wroc.pl - 2022-12-11 20:31 +0000
      Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Robert Latest <boblatest@yahoo.com> - 2022-12-12 14:39 +0000
        Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) antispam@math.uni.wroc.pl - 2022-12-13 12:15 +0000
        Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 16:23 +0000
      Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-26 05:20 -0800
        Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-26 14:37 +0000
          Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-26 10:30 -0800
            Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-27 16:45 +0000
              Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-27 19:38 -0800
                Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-29 02:09 +0000
                Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-29 19:56 -0800
  Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) antispam@math.uni.wroc.pl - 2022-12-11 20:12 +0000
    Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Lynn McGuire <lynnmcguire5@gmail.com> - 2022-12-12 14:33 -0600
      Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) scott@slp53.sl.home (Scott Lurndal) - 2022-12-12 21:12 +0000
        Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-12 16:09 -0800
  Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Jack Lemmon <invalid@invalid.net> - 2022-12-12 20:30 +0000
    Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Lynn McGuire <lynnmcguire5@gmail.com> - 2022-12-12 15:20 -0600
    Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-12 21:28 +0000
      Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) scott@slp53.sl.home (Scott Lurndal) - 2022-12-12 22:39 +0000
        Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-12 22:49 +0000
          Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) "minf...@arcor.de" <minforth@arcor.de> - 2022-12-31 04:01 -0800
        Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-12 15:56 -0800
          Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) scott@slp53.sl.home (Scott Lurndal) - 2022-12-13 14:55 +0000
            Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) David Brown <david.brown@hesbynett.no> - 2022-12-13 16:26 +0100
        Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) David Brown <david.brown@hesbynett.no> - 2022-12-13 14:50 +0100
        Re: Limitation of MS-DOS C compiler? (was Re: Should I convert FORTRAN code to C?) Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-12-13 18:56 +0300

csiph-web