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

Groups > comp.lang.c > #168503 > unrolled thread

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

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 1 of 2  [1] 2  Next page →

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

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?

[toc] | [next] | [standalone]

#168505

On 12/10/2022 3:06 PM, KP2 KP2 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?

Wow, that is an old message from 1988. There are multiple concerns in 
the message.

That was a 16 bit C compiler.  Today's C/C++ compilers generate code 
using 32 bit segments or 64 bit segments.  32 bit segments are only 
supported on x86 and x64 operating systems.  64 bit segments are only 
supported on x64 operating systems.

I doubt that any modern C/C++ compilers refuse to take any legal C/C++ 
code.  I would not be surprised that modern C/C++ compilers detect 
certain benchmarks

Lynn

[toc] | [prev] | [next] | [standalone]

#168506

On 12/10/2022 8:57 PM, Lynn McGuire wrote:
> I would not be surprised that modern C/C++ compilers detect certain 
> benchmarks

I would not be surprised that most modern C/C++ compilers detect certain 
benchmarks and generate highly optimized canned code to look really good 
on benchmarks.  After all, one only gets a few chances to look good and 
that is their chance.

Lynn

[toc] | [prev] | [next] | [standalone]

#168510

Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> I doubt that any modern C/C++ compilers refuse to take any legal C/C++ 
> code.  I would not be surprised that modern C/C++ compilers detect 
> certain benchmarks

Some time ago I posted here a simple C program.  It looks legal
(nobody here objected to legality of this program).  In principle
compiler should generate pretty small executable, but it looks
that no existing compiler can handle that program.  One can say
that compiler does not "reject" the program, simply compiler
runs out of memory.  But for the user effect is the same:
compiler will not handle legal program.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#168511

antispam@math.uni.wroc.pl wrote:
> Some time ago I posted here a simple C program.  It looks legal
> (nobody here objected to legality of this program).  In principle
> compiler should generate pretty small executable, but it looks
> that no existing compiler can handle that program.  One can say
> that compiler does not "reject" the program, simply compiler
> runs out of memory.  But for the user effect is the same:
> compiler will not handle legal program.

Sounds interesting. Can you post it again?

[toc] | [prev] | [next] | [standalone]

#168525

Robert Latest <boblatest@yahoo.com> wrote:
> antispam@math.uni.wroc.pl wrote:
> > Some time ago I posted here a simple C program.  It looks legal
> > (nobody here objected to legality of this program).  In principle
> > compiler should generate pretty small executable, but it looks
> > that no existing compiler can handle that program.  One can say
> > that compiler does not "reject" the program, simply compiler
> > runs out of memory.  But for the user effect is the same:
> > compiler will not handle legal program.
> 
> Sounds interesting. Can you post it again?

I could, but you should be able to find it, it is still on aioe.
The post is dated 2022-08-25 and topic line is
'Are there any conformant C compilers?'.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#168534

Robert Latest <boblatest@yahoo.com> writes:

> antispam@math.uni.wroc.pl wrote:
>> Some time ago I posted here a simple C program.  It looks legal
>> (nobody here objected to legality of this program).  In principle
>> compiler should generate pretty small executable, but it looks
>> that no existing compiler can handle that program.  One can say
>> that compiler does not "reject" the program, simply compiler
>> runs out of memory.  But for the user effect is the same:
>> compiler will not handle legal program.
>
> Sounds interesting. Can you post it again?

It was a program that nested macros call to generate a huge expression
with 2^48 terms.  It's unlikely that any implementation can handle
that.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#168635

antispam@math.uni.wroc.pl writes:

> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>
>> I doubt that any modern C/C++ compilers refuse to take any legal
>> C/C++ code.  I would not be surprised that modern C/C++ compilers
>> detect certain benchmarks
>
> Some time ago I posted here a simple C program.  It looks legal
> (nobody here objected to legality of this program).  In principle
> compiler should generate pretty small executable, but it looks
> that no existing compiler can handle that program.  One can say
> that compiler does not "reject" the program, simply compiler runs
> out of memory.  But for the user effect is the same:  compiler
> will not handle legal program.

And the answer is the same as before.  The C language is
infinitely large (and indeed must be if it is to be Turing
complete).  Compilers are programs;  no program can deal with
unboundedly large inputs (not counting the vanishingly small
fraction of programs whose output set is finite rather than
infinite).  No competent person expects a compiler (or indeed any
non-trivial program) to be able to handle unboundedly large
inputs.  A program that is unable to handle a large input simply
because of its size is not "refusing" to handle the input, and
anyone who says otherwise is just being obtuse.

[toc] | [prev] | [next] | [standalone]

#168639

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> antispam@math.uni.wroc.pl writes:
>
>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>
>>> I doubt that any modern C/C++ compilers refuse to take any legal
>>> C/C++ code.  I would not be surprised that modern C/C++ compilers
>>> detect certain benchmarks
>>
>> Some time ago I posted here a simple C program.  It looks legal
>> (nobody here objected to legality of this program).  In principle
>> compiler should generate pretty small executable, but it looks
>> that no existing compiler can handle that program.  One can say
>> that compiler does not "reject" the program, simply compiler runs
>> out of memory.  But for the user effect is the same:  compiler
>> will not handle legal program.
>
> And the answer is the same as before.  The C language is
> infinitely large (and indeed must be if it is to be Turing
> complete).  Compilers are programs;  no program can deal with
> unboundedly large inputs (not counting the vanishingly small
> fraction of programs whose output set is finite rather than
> infinite).  No competent person expects a compiler (or indeed any
> non-trivial program) to be able to handle unboundedly large
> inputs.  A program that is unable to handle a large input simply
> because of its size is not "refusing" to handle the input, and
> anyone who says otherwise is just being obtuse.

But the program was not particularly large.  Instead, the program
required a large amount of compile-time processing which the standard
/could/ have deemed to be not strictly conforming by, say, putting a
limit on the number of tokens permitted in the result of a macro
expansion.  The standard does not do that, so there are small, strictly
conforming programs that one can't reasonably expect to be processed.

Also, I think the reference to C being Turing complete is a red herring.
C could be defined in such as way that valid inputs to the compiler are
always "small" and never require unbounded processing without
compromising the language's completeness.  There need not be any
language feature that can incur exponential (let along unbounded)
compile-time costs for a language to the Turing compete.

C++ has this issue in spades because the template sub-language is Turing
complete.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#168642

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> antispam@math.uni.wroc.pl writes:
>>
>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>
>>>> I doubt that any modern C/C++ compilers refuse to take any legal
>>>> C/C++ code.  I would not be surprised that modern C/C++ compilers
>>>> detect certain benchmarks
>>>
>>> Some time ago I posted here a simple C program.  It looks legal
>>> (nobody here objected to legality of this program).  In principle
>>> compiler should generate pretty small executable, but it looks
>>> that no existing compiler can handle that program.  One can say
>>> that compiler does not "reject" the program, simply compiler runs
>>> out of memory.  But for the user effect is the same:  compiler
>>> will not handle legal program.
>>
>> And the answer is the same as before.  The C language is
>> infinitely large (and indeed must be if it is to be Turing
>> complete).  Compilers are programs;  no program can deal with
>> unboundedly large inputs (not counting the vanishingly small
>> fraction of programs whose output set is finite rather than
>> infinite).  No competent person expects a compiler (or indeed any
>> non-trivial program) to be able to handle unboundedly large
>> inputs.  A program that is unable to handle a large input simply
>> because of its size is not "refusing" to handle the input, and
>> anyone who says otherwise is just being obtuse.
>
> But the program was not particularly large.

It is true that the original input was small.  On the other hand,
the semantics of that input is defined by a textual processing
step, and said step yields a huge output.  It's naive to think
that this pre-processing and subsequent program analysis would
be accomplished in any way that is significantly different than
would the program that corresponds to the output of expanding the
original input in a straightforward manner.  Certainly it is no
stretch to say that antispam@math.uni.wroc.pl is not naive.

> Instead, the program required a large amount of compile-time
> processing which the standard /could/ have deemed to be not
> strictly conforming by, say, putting a limit on the number of
> tokens permitted in the result of a macro expansion.

Sure, that could be done, but there is no point in doing so.  The
translation limits that the C standard does define all have the
property that they might be transgressed accidentally.  What
limit would someone propose for the size of a program after doing
macro expansion?  2**30?  No program is going to exceed such a
limit accidentally.  But if the limit were significantly smaller,
even say on the order of 2**20, there are useful program that
would exceed that.  The purpose of translation limits is to put a
useful lower bound on what compilers must accept (and note, not
what they must successfully /translate/, but what they must
/accept/, which is quite another thing).  Putting an upper bound
on the size of a macro expansion (which, by the way, is not easy
to define, because the expansion might not all be done at once),
serves no useful purpose.

> The standard does not do that, so there are small, strictly
> conforming programs that one can't reasonably expect to be
> processed.

Okay.  So what?  Programming languages that include some kind of
macro processing all have this property.  In practice it doesn't
matter.

Translation limits in the C standard are there so implementations
can use fixed-size tables for certain data structures and not
worry about not being conforming.  It is not purely a coincidence
that the translation limits defined are all small numbers.  But
there is no such small number or data structure for performing
macro expansions, because of how they are processed and how they
have been used historically.  To say this another way, putting a
large upper bound on program size or how big a macro expansion
would be doesn't do anything to help compilers.  Putting one in
would be artificial and not really helpful in any useful way.

> Also, I think the reference to C being Turing complete is a red
> herring.  C could be defined in such as way that valid inputs to
> the compiler are always "small" and never require unbounded
> processing without compromising the language's completeness.
> There need not be any language feature that can incur exponential
> (let along unbounded) compile-time costs for a language to the
> Turing compete.

Either I don't know what you're getting at here or what you're
saying is wrong.  To be Turing complete a language must be
infinite rather than finite.  Restricting a language to "small"
programs, if "small" means some finite bound, will necessarily
exclude an infinite number of computable functions.  Even if we
accept that all "useful" programs will be "small", there is no
reason to impose an artificial limit on program size;  any
particular limit will either be so large that it cannot be
accommodated, or sufficiently small that it might intrude on the
set of programs that people might reasonably want to write.
There is no way to pick a limit that is sufficiently large so
that it certainly includes all useful programs, but no so large
that it isn't just absurd.

Incidentally, the processing time needed is irrelevant.  The
compiler will run out of memory long before it runs out of CPU
cycles.

My guess here is that all this discussion is a consequence of
antispam not understanding the purpose of defining "strictly
conforming" programs.  Being strictly conforming has nothing to
do with whether a compiler will successfully process a program.
Which programs a compiler will successfully process is purely a
quality-of-implementation issue, and the C standard consciously
avoids such questions.

> C++ has this issue in spades because the template sub-language
> is Turing complete.

I don't think of large macro expansions in C as being a problem
with the C language.  Templates in C++ being Turing complete is a
different situation, because it isn't possible to tell if a
template "program" will terminate.  In any case I think it would
be better for my mental health not to think any further about
problems in the C++ language.

[toc] | [prev] | [next] | [standalone]

#168658

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> antispam@math.uni.wroc.pl writes:
>>>
>>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>>
>>>>> I doubt that any modern C/C++ compilers refuse to take any legal
>>>>> C/C++ code.  I would not be surprised that modern C/C++ compilers
>>>>> detect certain benchmarks
>>>>
>>>> Some time ago I posted here a simple C program.  It looks legal
>>>> (nobody here objected to legality of this program).  In principle
>>>> compiler should generate pretty small executable, but it looks
>>>> that no existing compiler can handle that program.  One can say
>>>> that compiler does not "reject" the program, simply compiler runs
>>>> out of memory.  But for the user effect is the same:  compiler
>>>> will not handle legal program.
>>>
>>> And the answer is the same as before.  The C language is
>>> infinitely large (and indeed must be if it is to be Turing
>>> complete).  Compilers are programs;  no program can deal with
>>> unboundedly large inputs (not counting the vanishingly small
>>> fraction of programs whose output set is finite rather than
>>> infinite).  No competent person expects a compiler (or indeed any
>>> non-trivial program) to be able to handle unboundedly large
>>> inputs.  A program that is unable to handle a large input simply
>>> because of its size is not "refusing" to handle the input, and
>>> anyone who says otherwise is just being obtuse.
>>
>> But the program was not particularly large.
>
> It is true that the original input was small.  On the other hand,
> the semantics of that input is defined by a textual processing
> step, and said step yields a huge output.  It's naive to think
> that this pre-processing and subsequent program analysis would
> be accomplished in any way that is significantly different than
> would the program that corresponds to the output of expanding the
> original input in a straightforward manner.  Certainly it is no
> stretch to say that antispam@math.uni.wroc.pl is not naive.
>
>> Instead, the program required a large amount of compile-time
>> processing which the standard /could/ have deemed to be not
>> strictly conforming by, say, putting a limit on the number of
>> tokens permitted in the result of a macro expansion.
>
> Sure, that could be done, but there is no point in doing so.  The
> translation limits that the C standard does define all have the
> property that they might be transgressed accidentally.  What
> limit would someone propose for the size of a program after doing
> macro expansion?  2**30?  No program is going to exceed such a
> limit accidentally.  But if the limit were significantly smaller,
> even say on the order of 2**20, there are useful program that
> would exceed that.  The purpose of translation limits is to put a
> useful lower bound on what compilers must accept (and note, not
> what they must successfully /translate/, but what they must
> /accept/, which is quite another thing).  Putting an upper bound
> on the size of a macro expansion (which, by the way, is not easy
> to define, because the expansion might not all be done at once),
> serves no useful purpose.
>
>> The standard does not do that, so there are small, strictly
>> conforming programs that one can't reasonably expect to be
>> processed.
>
> Okay.  So what?  Programming languages that include some kind of
> macro processing all have this property.  In practice it doesn't
> matter.

Yes, I agree.  I was not suggesting there was a practical problem.

>> Also, I think the reference to C being Turing complete is a red
>> herring.  C could be defined in such as way that valid inputs to
>> the compiler are always "small" and never require unbounded
>> processing without compromising the language's completeness.
>> There need not be any language feature that can incur exponential
>> (let along unbounded) compile-time costs for a language to the
>> Turing compete.
>
> Either I don't know what you're getting at here or what you're
> saying is wrong.  To be Turing complete a language must be
> infinite rather than finite.  Restricting a language to "small"
> programs, if "small" means some finite bound, will necessarily
> exclude an infinite number of computable functions.

I think this is going to get messy because I contend that C (certainly
freestanding C) already excludes an infinite number of computable
functions because it's model is everywhere bounded.  (Yes, I know we
might want to consider IO to be essentially unbounded.)

But that's a side issue!

I meant only that the kind of processing the example indulged in could
be deemed invalid without affecting C's Turing completeness.  You
considered the program "large" in that it generated a huge
post-processing input.  C could have declared such "large" programs
to be invalid.

For the specific issue that was raised issue, Turing completeness is
irrelevant.  You can have a language that is not TC but exhibits the
same problem (unmanageable compiler-time costs) as well as one that is
TC that does not exhibit the problem.

> Incidentally, the processing time needed is irrelevant.  The
> compiler will run out of memory long before it runs out of CPU
> cycles.

Yes.  "Compile-time costs" was supposed to mean costs (in terms of
resources) incurred at compile time.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#168677

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

[..pruning mercilessly..]

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[.. concerning C being Turing complete ..]

> I think this is going to get messy because I contend that C
> (certainly freestanding C) already excludes an infinite number of
> computable functions because it's model is everywhere bounded.
> (Yes, I know we might want to consider IO to be essentially
> unbounded.)
>
> But that's a side issue!

Okay, I will ignore that question.

> I meant only that the kind of processing the example indulged in
> could be deemed invalid without affecting C's Turing completeness.
> You considered the program "large" in that it generated a huge
> post-processing input.  C could have declared such "large" programs
> to be invalid.

What I think you're saying here is C could disallow large
programs when the largeness comes mostly from macro expansion
(and so we don't need to consider the question of the language
being Turing complete).  I think that's right, although I'm not
sure if such a determination could be done cheaply enough;  the
cost of deciding when the limit is exceeded might be too high
to be practical.  Also I'm not sure how to define the property
in a precise way;  no doubt it could be done, but I suspect
making the definition precise would give a result that is
complicated and hard to understand.  (But I'm not asking for a
concrete proposal.)

If you're saying something else then I don't know what it is.


>> Incidentally, the processing time needed is irrelevant.  The
>> compiler will run out of memory long before it runs out of CPU
>> cycles.
>
> Yes.  "Compile-time costs" was supposed to mean costs (in terms
> of resources) incurred at compile time.

Oh, but this matters.  The amount of memory required to see if
the macro-processing-expansion limit is exceeded (even when it is
not) might be too large for a determination to be made.  Oops!

Have we made any progress towards understanding each other?  I
hope we have. :)

[toc] | [prev] | [next] | [standalone]

#168685

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
> [..pruning mercilessly..]
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
> [.. concerning C being Turing complete ..]
>
>> I think this is going to get messy because I contend that C
>> (certainly freestanding C) already excludes an infinite number of
>> computable functions because it's model is everywhere bounded.
>> (Yes, I know we might want to consider IO to be essentially
>> unbounded.)
>>
>> But that's a side issue!
>
> Okay, I will ignore that question.
>
>> I meant only that the kind of processing the example indulged in
>> could be deemed invalid without affecting C's Turing completeness.
>> You considered the program "large" in that it generated a huge
>> post-processing input.  C could have declared such "large" programs
>> to be invalid.
>
> What I think you're saying here is C could disallow large
> programs when the largeness comes mostly from macro expansion
> (and so we don't need to consider the question of the language
> being Turing complete).  I think that's right, although I'm not
> sure if such a determination could be done cheaply enough;  the
> cost of deciding when the limit is exceeded might be too high
> to be practical.  Also I'm not sure how to define the property
> in a precise way;  no doubt it could be done, but I suspect
> making the definition precise would give a result that is
> complicated and hard to understand.  (But I'm not asking for a
> concrete proposal.)
>
> If you're saying something else then I don't know what it is.
>
>
>>> Incidentally, the processing time needed is irrelevant.  The
>>> compiler will run out of memory long before it runs out of CPU
>>> cycles.
>>
>> Yes.  "Compile-time costs" was supposed to mean costs (in terms
>> of resources) incurred at compile time.
>
> Oh, but this matters.  The amount of memory required to see if
> the macro-processing-expansion limit is exceeded (even when it is
> not) might be too large for a determination to be made.  Oops!
>
> Have we made any progress towards understanding each other?  I
> hope we have. :)

I'm not sure.  I don't think you've said anything that I've not
understood.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#168691

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

[...]

>> Have we made any progress towards understanding each other?  I
>> hope we have. :)
>
> I'm not sure.  I don't think you've said anything that I've not
> understood.

Well then I will stop here.  I'm sorry the communication wasn't
more fruitful.

[toc] | [prev] | [next] | [standalone]

#168508

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).

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#168512

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.

Lynn

[toc] | [prev] | [next] | [standalone]

#168514

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.

[toc] | [prev] | [next] | [standalone]

#168520

On 12/12/2022 1:12 PM, Scott Lurndal wrote:
> 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.

Well, I have access to some really old reporting software way back on 
DOS. It actually is still in use. Wow. I still have several old 
computers 386, 486 to run it on. DosBox does not seem to like it.

[toc] | [prev] | [next] | [standalone]

#168513

On 10/12/2022 21:06, KP2 KP2 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?

We are in year 2022 and nobody is using MSDOS on this planet. Are you 
still using it? Where do you get machines that can run msdos?

[toc] | [prev] | [next] | [standalone]

#168515

On 12/12/2022 2:30 PM, Jack Lemmon wrote:
> On 10/12/2022 21:06, KP2 KP2 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?
> 
> We are in year 2022 and nobody is using MSDOS on this planet. Are you
> still using it? Where do you get machines that can run msdos?

That was a reply to a 1988 posting.  It is a long dead thread.

Lynn

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web