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

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

Most important aspect of any compiler (C or otherwise)

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

Contents

  Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 11:02 -0700
    Re: Most important aspect of any compiler (C or otherwise) John Gordon <gordon@panix.com> - 2016-10-04 19:00 +0000
      Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 12:08 -0700
        Re: Most important aspect of any compiler (C or otherwise) jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-04 21:56 +0200
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 13:06 -0700
        Re: Most important aspect of any compiler (C or otherwise) BartC <bc@freeuk.com> - 2016-10-04 21:29 +0100
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 13:46 -0700
            Re: Most important aspect of any compiler (C or otherwise) BartC <bc@freeuk.com> - 2016-10-05 00:30 +0100
              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-04 16:58 -0700
                Re: Most important aspect of any compiler (C or otherwise) gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-05 01:07 +0000
              Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-05 08:07 -0700
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 11:51 -0700
                  Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-05 14:08 -0700
                    Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 14:25 -0700
                      Re: Most important aspect of any compiler (C or otherwise) "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-05 18:03 -0700
                        Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 18:13 -0700
                          Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:08 -0700
                            Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 19:18 -0700
                              Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:31 -0700
                                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 19:43 -0700
                        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-05 22:22 -0400
                        Re: Most important aspect of any compiler (C or otherwise) jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-06 09:56 +0200
                          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 04:54 -0700
                            Re: Most important aspect of any compiler (C or otherwise) mark.bluemel@gmail.com - 2016-10-06 05:06 -0700
                              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 05:27 -0700
                                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-06 05:32 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 19:12 -0700
        Re: Most important aspect of any compiler (C or otherwise) Ian Collins <ian-news@hotmail.com> - 2016-10-05 13:42 +1300
          Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 04:53 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 05:04 -0700
              Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-05 05:12 -0700
    Re: Most important aspect of any compiler (C or otherwise) Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-10-07 15:02 -0700
      Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-07 16:17 -0700
        Re: Most important aspect of any compiler (C or otherwise) luser droog <luser.droog@gmail.com> - 2016-10-07 18:11 -0700
          Re: Most important aspect of any compiler (C or otherwise) James Kuyper <jameskuyper@verizon.net> - 2016-10-07 23:53 -0400
            Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 01:12 -0700
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 08:05 -0700
                Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 10:15 -0700
            Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 02:17 -0700
              Re: Most important aspect of any compiler (C or otherwise) gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-08 11:02 +0000
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-08 05:14 -0700
                Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 12:20 -0700
                  Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 15:31 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 15:58 -0700
                      Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 17:46 -0700
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 08:09 -0700
            Re: Most important aspect of any compiler (C or otherwise) Keith Thompson <kst-u@mib.org> - 2016-10-08 14:49 -0700
              Re: Most important aspect of any compiler (C or otherwise) "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-09 11:12 -0400
        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-07 21:15 -0400
          Re: Most important aspect of any compiler (C or otherwise) supercat@casperkitty.com - 2016-10-08 01:02 -0700
            Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 06:04 -0400
              Re: Most important aspect of any compiler (C or otherwise) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 11:45 +0100
                Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 16:57 -0400
                  Re: Most important aspect of any compiler (C or otherwise) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 01:25 +0100
                    Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 21:29 -0400
              Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 07:49 -0700
                Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-08 08:04 -0700
                Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 16:58 -0400
                  Re: Most important aspect of any compiler (C or otherwise) jameskuyper@verizon.net - 2016-10-08 14:42 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Keith Thompson <kst-u@mib.org> - 2016-10-08 15:08 -0700
                    Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 19:27 -0400
                      Re: Most important aspect of any compiler (C or otherwise) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-08 16:37 -0700
                        Re: Most important aspect of any compiler (C or otherwise) Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-08 21:30 -0400
      Re: Most important aspect of any compiler (C or otherwise) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-07 18:31 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#94509

On 10/5/2016 9:03 PM, Chris M. Thomasson wrote:
> On 10/5/2016 2:25 PM, Rick C. Hodgin wrote:
>> Supercat wrote:
>>> What should happen if a pointer to bar.y is passed to a function,
>>> code is stopped within that function, and array "arr" is changed to 5
>>> elements?
>>
>> The location of all data is known.  Pointers can be examined to see
>> what they point into in ABI_stale, to see how things are translated
>> into ABI_new, and a series of data change ops are created, including
>> updating pointer values.
>>
>> Everything in the ABI is known.  It's a natural and resolvable projection
>> from the logical image into the physical.
> 
> When do you think your compiler might be is a state that can allow for a
> beta test?
> 

In the year twenty-five twenty-five, if man is still alive...

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#94525

Le 06/10/2016 à 03:03, Chris M. Thomasson a écrit :
> When do you think your compiler might be is a state that can allow for a
> beta test?

There isn't even a parser ready. We are discussing his vaporware because 
if somebody behaves badly and spams this group with religious nonsense 
he can only be given full attention: he is a religious nut, and should 
not be misclassified like navia, that horrible guy that tried to promote 
a compiler that wasn't vaporware at all.

I will do this and will do that. CAlive will do everytging better than 
msvc/gcc with their teams of hundreds of people.

In this newsgroup C programmers are scarce. The containers library is 
ignored.

Well, *obviously* since it is not vaporware

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

#94526

jacobnavia wrote:
> I will do this and will do that. CAlive will do everytging better
> than msvc/gcc with their teams of hundreds of people.

Two things:  (1) I think lcc-win is awesome.  You have justifiable
bragging rights.  (2) I pray to have thousands of developers contributing
to the Village Freedom Project, not just on the compiler, but in all
apps.

I want LibSF to be a God-fearing hardware and software base for
a completely new top-down, bottom-up computer-related
offering unto God and mankind.

Best regards,
Rick C. Hodgin

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

#94527

On Thursday, 6 October 2016 12:54:26 UTC+1, Rick C. Hodgin  wrote:

> I want LibSF to be a God-fearing hardware and software base for
> a completely new top-down, bottom-up computer-related
> offering unto God and mankind.

I look forward to hearing of the first user to host porn on site powered by it...

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

#94529

On Thursday, October 6, 2016 at 8:07:07 AM UTC-4, mark.b...@gmail.com wrote:
> On Thursday, 6 October 2016 12:54:26 UTC+1, Rick C. Hodgin  wrote:
> 
> > I want LibSF to be a God-fearing hardware and software base for
> > a completely new top-down, bottom-up computer-related
> > offering unto God and mankind.
> 
> I look forward to hearing of the first user to host porn on site powered by it...

Other people have said similar things in the past.  Here is my reply to
that line of thinking (updated to reflect the broader form I am now in
pursuit of):

    https://groups.google.com/d/msg/publicesvfoxpro/ZVzZIcjQrY0/cKOlL1opcRwJ3

    "I will do my best with [the Liberty Software Foundation].  [As our
     software products are] completed, you will be free to use [all of] it.
     And since I am offering the [products] in source code form under a
     [type of Public Domain] license, you will also be free to take the
     source code and modify it to suit [personal or] proprietary needs.
     But it will not be [the] gift that is [being] used in that way, only
     the perversion of the gift I am offering.

    "And this is exactly what has happened here on this Earth with the gift
     God gave unto mankind, and the perversion of that gift through sin by
     the enemy [such that the great gifts of God given unto mankind, even
     of the whole Earth and everything in and on it, are no longer being
     used as they were created to be used or intended, but are now being
     used for sinful purposes against God.  God lets man continue on for a
     time in that way, all the while warning about the dangers of doing so.

    "He is patient such that He gives each person time to realize for
     themselves that what they're doing is wrong.  But the day is coming,
     which is then THE LAST day.  And on that day, all continuation of the
     former sinful ways will no longer be tolerated, and the accounting
     required by God for living that way under sin will be demanded]."

-----
It is right to pursue God and God's goals in one's life ... even if nobody
else will.  God's ways will exist for eternity.  And He calls for us to
follow Him even here upon the Earth ("Thy will be done, on Earth as it is
in Heaven").

Best regards,
Rick C. Hodgin

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

#94530

On Thursday, October 6, 2016 at 8:28:45 AM UTC-4, Rick C. Hodgin wrote:
> Other people have said similar things in the past.  Here is my reply to
> that line of thinking (updated to reflect the broader form I am now in
> pursuit of):
> 
>     https://groups.google.com/d/msg/publicesvfoxpro/ZVzZIcjQrY0/cKOlL1opcRwJ3

Corrected link:

    https://groups.google.com/d/msg/publicesvfoxpro/ZVzZIcjQrY0/cKOlL1opcRwJ

>     "I will do my best with [the Liberty Software Foundation].  [As our
>      software products are] completed, you will be free to use [all of] it.
>      And since I am offering the [products] in source code form under a
>      [type of Public Domain] license, you will also be free to take the
>      source code and modify it to suit [personal or] proprietary needs.
>      But it will not be [the] gift that is [being] used in that way, only
>      the perversion of the gift I am offering.
> 
>     "And this is exactly what has happened here on this Earth with the gift
>      God gave unto mankind, and the perversion of that gift through sin by
>      the enemy [such that the great gifts of God given unto mankind, even
>      of the whole Earth and everything in and on it, are no longer being
>      used as they were created to be used or intended, but are now being
>      used for sinful purposes against God.  God lets man continue on for a
>      time in that way, all the while warning about the dangers of doing so.
> 
>     "He is patient such that He gives each person time to realize for
>      themselves that what they're doing is wrong.  But the day is coming,
>      which is then THE LAST day.  And on that day, all continuation of the
>      former sinful ways will no longer be tolerated, and the accounting
>      required by God for living that way under sin will be demanded]."
> 
> -----
> It is right to pursue God and God's goals in one's life ... even if nobody
> else will.  God's ways will exist for eternity.  And He calls for us to
> follow Him even here upon the Earth ("Thy will be done, on Earth as it is
> in Heaven").

Best regards,
Rick C. Hodgin

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

#94464

On Tuesday, October 4, 2016 at 9:46:21 PM UTC+1, Rick C. Hodgin wrote:
>
> It's a comprehensive project.  Everyone I've shown the details to in person
> so far tell me I'm crazy.  But, it's the goal I have and it's what's upon
> my heart.  It's been there since the early 90s. 
>
You need micro-goals. plan something which gives a real benefit to a
user, and you know you can achieve within a few weeks. Then implement
that and release it.
Don't underestimate the time things take. I made about 20 commits
to Baby X, and all I did was essentially move codes about in folders
and set paths in IDEs. Then documenting my binary image library has
taken a long time. I've been floating B64 for quite some time now,
and whilst it's a far simpler project than C alive, I've yet to
write the first line of the first prototype interpreter.

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

#94462

On 10/ 5/16 08:08 AM, Rick C. Hodgin wrote:
> On Tuesday, October 4, 2016 at 3:00:45 PM UTC-4, John Gordon wrote:
>> In <20aae408-4b77-483a-bb84-d05f5240f415@googlegroups.com> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> For me?  Barring the obvious things like functionality and error-free binary
>>> code, it would have to be edit-and-continue.  And without equal.
>>
>> So when the compiler encounters an error, it retains the compilation
>> artifacts (parse tree, symbol table, etc.) up to that point, and when the
>> user corrects the error it continues compiling where it left off?
>>
>> What if the correction changed something that has already been compiled?
>>
>> How much time can it possibly save?  Compilation is pretty fast, no?
>
> There are two approaches to the design.  Microsoft uses the top-down
> recompilation which then looks for the deltas or diffs between the
> generated binary images, and then updates things accordingly.  It often
> breaks data or functions on the stack, or fails to compile completely
> if you stray away.
>
> The model I'm using for CAlive takes the approach of saving the full
> compilation state.  Compilation is carried out continuously as things
> are changed.  But in general, dependency trees are maintained and if
> things which were dependent upon something that's changed has changed,
> the entire related lines of source code are stricken and recompiled.

All well and good for a single file or trivial application, but things 
would get horribly complex (and memory consuming) if you were working on 
one part of a large and complex application.

Most popular IDEs use some form of background compilation which 
highlights errors as you type.  This will take care of most of your 
brain to finger problems.  Unit tests will catch the rest!

-- 
Ian

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

#94476

Ian Collins wrote:
> All well and good for a single file or trivial application, but
> things would get horribly complex (and memory consuming)
> if you were working on one part of a large and complex application.

CAlive still supports traditional stand alone compile + link for
all apps.  LiveCode is a build option, a feature that must be turned
on by switch, otherwise it generates an object file, or auto-links to
final output.

Memory is cheap.  Storage is cheap.  My language goals today look
to the future, not the past.  Certain features should exist, and I
target them.

Best regards,
Rick C. Hodgin

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

#94477

On Wednesday, October 5, 2016 at 12:53:15 PM UTC+1, Rick C. Hodgin wrote:
> Ian Collins wrote:
> > All well and good for a single file or trivial application, but
> > things would get horribly complex (and memory consuming)
> > if you were working on one part of a large and complex application.
> 
> CAlive still supports traditional stand alone compile + link for
> all apps.  LiveCode is a build option, a feature that must be turned
> on by switch, otherwise it generates an object file, or auto-links to
> final output.
> 
> Memory is cheap.  Storage is cheap.  My language goals today look
> to the future, not the past.  Certain features should exist, and I
> target them.
> 
However if a resource like memory becomes cheap, often that means that
it is more rather than less important to use it efficiently. A very constrained
machine can't hold much in memory anyway, so it has to parse files line
by line. With a machine with a decent memory, you naturally load up the
entire code base. But that might include automatically generated files
such as those created by the Baby X resource compiler. As programs get
bigger and display more images, the rgba dumps get larger and larger,
and memory can start to be an issue in a way that it wasn't on the line-
based parser.

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

#94478

On Wednesday, October 5, 2016 at 8:04:51 AM UTC-4, Malcolm McLean wrote:
> On Wednesday, October 5, 2016 at 12:53:15 PM UTC+1, Rick C. Hodgin wrote:
> > Ian Collins wrote:
> > > All well and good for a single file or trivial application, but
> > > things would get horribly complex (and memory consuming)
> > > if you were working on one part of a large and complex application.
> > 
> > CAlive still supports traditional stand alone compile + link for
> > all apps.  LiveCode is a build option, a feature that must be turned
> > on by switch, otherwise it generates an object file, or auto-links to
> > final output.
> > 
> > Memory is cheap.  Storage is cheap.  My language goals today look
> > to the future, not the past.  Certain features should exist, and I
> > target them.
> > 
> However if a resource like memory becomes cheap, often that means that
> it is more rather than less important to use it efficiently. A very constrained
> machine can't hold much in memory anyway, so it has to parse files line
> by line. With a machine with a decent memory, you naturally load up the
> entire code base. But that might include automatically generated files
> such as those created by the Baby X resource compiler. As programs get
> bigger and display more images, the rgba dumps get larger and larger,
> and memory can start to be an issue in a way that it wasn't on the line-
> based parser.

Exactly.  My goals are for the hardware that will exist in the 2020s and
beyond.  I do not imagine constrained general purpose machines in that
timeframe, except for explicit purposes (wristwatches may use inexpensive
general purpose hardware, but with fixed resources because they don't
need more).

In addition, the build machine does not need to be the target machine.
Build and test it on the large desktop, then deploy it on the smaller
device.

Best regards,
Rick C. Hodgin

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

#94573

On Tuesday, October 4, 2016 at 1:03:00 PM UTC-5, Rick C. Hodgin wrote:
> For me?  Barring the obvious things like functionality and error-free binary
> code, it would have to be edit-and-continue.  And without equal.
> 
(...)
> 
> -----
> As such, I view edit-and-continue as the single most desirable asset of
> any software developer.  It is a fully primary area of focus for my CAlive
> compiler and IDE.
> 

The thread has veered off into CAlive and other matters, but I think the subject of this thread viz., "Most important aspect of any compiler (C or otherwise)" is interesting.

What do folks consider as *Most* important feature of a compiler? (my emphasis)

I suppose standard conformance would come out top in this group?

Others might look at compilation times, link times (for C++, this is significant), performance of generated binaries, interop with binaries from other compilers, ...

To me, arguably the most important feature would be quality of diagnostics.  Mundane errors such as an unmatched paren/squiggly, or a missing semi-colon in a header file make for the most interesting error messages.  There are folks I admire (e.g., Leor Zolman) who write tools to parse and decrypt error messages from C++ compilers!

I consider features such as Edit-and-Continue to be among the feature-set of an IDE / debugger rather than a compiler.  I suppose 'tool-support' would make it a compiler feature?

Thoughts?

- Anand

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

#94575

On Friday, October 7, 2016 at 5:02:34 PM UTC-5, Anand Hariharan wrote:
> What do folks consider as *Most* important feature of a compiler? (my emphasis)
> 
> I suppose standard conformance would come out top in this group?

Predictable and logical support for features of the target platform.

Since it's possible for an implementation to be conforming and yet
incapable of running any useful programs, and since limited platforms
may be better served by a compiler that deviates from the Standard than
one which adheres to it perfectly, I don't see rigid standards conformance
as being particularly valuable in and of itself.

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

#94579

On Friday, October 7, 2016 at 6:17:41 PM UTC-5, supe...@casperkitty.com wrote:
> On Friday, October 7, 2016 at 5:02:34 PM UTC-5, Anand Hariharan wrote:
> > What do folks consider as *Most* important feature of a compiler? (my emphasis)
> > 
> > I suppose standard conformance would come out top in this group?
> 
> Predictable and logical support for features of the target platform.
> 
> Since it's possible for an implementation to be conforming and yet
> incapable of running any useful programs, and since limited platforms
> may be better served by a compiler that deviates from the Standard than
> one which adheres to it perfectly, I don't see rigid standards conformance
> as being particularly valuable in and of itself.

It is possible, but that'd be stupid. So I doubt 
anyone would set out to write a useless[1] compiler.

[1] not to be confused with the esolang entitled "useless". Here, the normal English word.

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

#94584

On 10/07/2016 09:11 PM, luser droog wrote:
> On Friday, October 7, 2016 at 6:17:41 PM UTC-5, supe...@casperkitty.com wrote:
>> On Friday, October 7, 2016 at 5:02:34 PM UTC-5, Anand Hariharan wrote:
>>> What do folks consider as *Most* important feature of a compiler? (my emphasis)
>>>
>>> I suppose standard conformance would come out top in this group?
>>
>> Predictable and logical support for features of the target platform.
>>
>> Since it's possible for an implementation to be conforming and yet
>> incapable of running any useful programs, and since limited platforms
>> may be better served by a compiler that deviates from the Standard than
>> one which adheres to it perfectly, I don't see rigid standards conformance
>> as being particularly valuable in and of itself.
> 
> It is possible, but that'd be stupid. So I doubt 
> anyone would set out to write a useless[1] compiler.

I've sometimes considered the idea of writing a fully conforming but
completely useless implementation of C, primarily for making the point
that the requirements for full conformance are a lot weaker than many
people think (including some of the people who had a role in creating
those requirements).
Creating a useless implementation would be a lot simpler than writing a
useful implementation, but (because #error directives have to be handled
correctly) it requires correctly implementing all of translation phases
1-4, which is sufficiently complicated to make the project interesting.

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

#94587

On Friday, October 7, 2016 at 10:53:53 PM UTC-5, James Kuyper wrote:
> Creating a useless implementation would be a lot simpler than writing a
> useful implementation, but (because #error directives have to be handled
> correctly) it requires correctly implementing all of translation phases
> 1-4, which is sufficiently complicated to make the project interesting.

Probably the simplest way to produce a useful implementation is to find a
program whose behavior could be achieved by a strictly-conforming program
that exercised all implementation limits, write such a strictly-performing
program that behaves likewise, and then hack a compiler so that no matter
what code it's given it always outputs the first program mentioned above.

Feed the One Program into the compiler and it will produce an executable
which behaves as the Standard requires.  Feed anything else into the
compiler and--oops--it exceeded an implementation limit in a fashion over
which the Standard imposes no requirements, so anything the program might
do (including behaving just like the first program) would be conforming.

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

#94601

On Saturday, October 8, 2016 at 4:12:45 AM UTC-4, supe...@casperkitty.com wrote:
> On Friday, October 7, 2016 at 10:53:53 PM UTC-5, James Kuyper wrote:
> > Creating a useless implementation would be a lot simpler than writing a
> > useful implementation, but (because #error directives have to be handled
> > correctly) it requires correctly implementing all of translation phases
> > 1-4, which is sufficiently complicated to make the project interesting.
> 
> Probably the simplest way to produce a useful implementation is to find a
> program whose behavior could be achieved by a strictly-conforming program
> that exercised all implementation limits, write such a strictly-performing

Note: the "one program" is NOT required to be strictly conforming. If it exceeds any of those limits (which is permitted), it won't be strictly conforming. It can also fail to be strictly conforming for any other reason.

> program that behaves likewise, and then hack a compiler so that no matter
> what code it's given it always outputs the first program mentioned above.
> 
> Feed the One Program into the compiler and it will produce an executable
> which behaves as the Standard requires.  Feed anything else into the
> compiler and--oops--it exceeded an implementation limit in a fashion over
> which the Standard imposes no requirements, so anything the program might
> do (including behaving just like the first program) would be conforming.

That doesn't sound like a "useful" implementation to me - I was talking about a "useless" implementation - did you accidentally reverse the term? The "one program" could be functionally equivalent to "int main(void) {}", which would somewhat simplify the implementation compared to the one you describe above, if the objective is to create a useless one.

I was specifically talking about a fully conforming but useless implementation. A conforming implementation must not successfully complete translation of a program containing a #error directive that survives conditional compilation - yours does.
"A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined." (5.1.1.3p1). It would be trivial to meet this requirement by always issuing exactly one diagnostic message: "Your program may contain errors". Your implementation does not meet this requirement.

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

#94609

On Saturday, October 8, 2016 at 10:05:41 AM UTC-5, james...@verizon.net wrote:
> On Saturday, October 8, 2016 at 4:12:45 AM UTC-4, supe...@casperkitty.com wrote:
> > Probably the simplest way to produce a useful implementation is to find a
> > program whose behavior could be achieved by a strictly-conforming program
> > that exercised all implementation limits, write such a strictly-performing
> 
> Note: the "one program" is NOT required to be strictly conforming. If it exceeds any of those limits (which is permitted), it won't be strictly conforming. It can also fail to be strictly conforming for any other reason.

I shouldn't have said "simplest", since one could simplify things further by
taking advantage of the fact that the Standard says even less than I've
implied.

On the other hand, if a program isn't strictly conforming, it might be
ambiguous whether it tests all the implementation limits.  For example, a
source text containing two underscores, a linefeed, and nothing else, could
be regarded as a conforming C program which does anything whatsoever.  One
could thus declare by fiat that an such a source text exercises all the
implementation limits, but that would render the limits even more meaningless
than they otherwise would be.  On the other hand, such a reading would let
one get around the #error requirement by saying that, with a few specific
exceptions, inputs are limited to six characters per line, and the exceeding
that limit will invoke UB.

> > Feed the One Program into the compiler and it will produce an executable
> > which behaves as the Standard requires.  Feed anything else into the
> > compiler and--oops--it exceeded an implementation limit in a fashion over
> > which the Standard imposes no requirements, so anything the program might
> > do (including behaving just like the first program) would be conforming.
> 
> That doesn't sound like a "useful" implementation to me - I was talking about a "useless" implementation - did you accidentally reverse the term? The "one program" could be functionally equivalent to "int main(void) {}", which would somewhat simplify the implementation compared to the one you describe above, if the objective is to create a useless one.

Knowing that a program *won't* do anything is sometimes a useful guarantee.
My point is that the Standard doesn't say anything meaningful about what any
particular program might or might not do.

> I was specifically talking about a fully conforming but useless implementation. A conforming implementation must not successfully complete translation of a program containing a #error directive that survives conditional compilation - yours does.

My original intention was for the simplest "cross-compiler" for a
particular target system, using any program produces any predictable
output on the target and hacking any compiler for any system so it
would output the target system's One Program regardless of what else
happened.  I then thought cross-compilation issues made things too
complicated, and edited them out, but that blurred the point that one
would start with an existing implementation (or at least preprocessor)
for some system but wouldn't need a useful code generator.

If one were trying to make a minimal preprocessor it might be useful to
keep for every macro a list of all the definitions it's ever been given,
and have any #error directive expand as the Cartesian product of all macros
contained therein.  Doing that would eliminate the need to process any
#if directives or expressions contained therein.  I don't think there's any
requirement that #include work with anything other than standard library
headers, since there is no requirement that an implementation include any
sort of file system.

> "A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined." (5.1.1.3p1). It would be trivial to meet this requirement by always issuing exactly one diagnostic message: "Your program may contain errors". Your implementation does not meet this requirement.

My intention was that one hack an existing implementation, using the existing
implementation for the #error directive.  Were it not for that requirement,
a program that blindly output "This is a diagnostic." would suffice.

IMHO, the Standard would be much more useful if most tasks could be coded
in such a way (I'd call it "selectively conforming") such that that
conforming implementations would be required to either process them without
UB or indicate, in an implementation-defined fashion, a refusal to do so.
To be useful, most programs which use recursion would need to indicate for
at least some recursive functions the maximum number of times they would be
nested (a compiler could then determine an upper bound on stack utilization
or indicate that it cannot guarantee UB-free operation).

Even if a particular program be rejected by 98% of implementations, a
guarantee that it will work correctly on the 2% that do accept it may be
more useful than a vague statement that it will likely work on 98% of
implementations, but without any guarantees that it will be reliable on
any particular implementation.

Further, an implementations that can't meet all the Implementation Limits
could be useful for running programs which have smaller requirements, if
implementations could promise to reject without UB any programs that
exceeded their abilities.  I've found almost-standard C to be a useful
language when programming a variety of machines with 256 bytes or less of
RAM (typically with a non-volatile code store in the 2K-8K range); while
such an devices could not comply with the Implementation Limits section in
the fashion the authors intended, many useful programs will in fact fit in
such devices and a program which successfully builds can be guaranteed not
to run out of memory during execution.

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

#94588

On Saturday, October 8, 2016 at 4:53:53 AM UTC+1, James Kuyper wrote:
> On 10/07/2016 09:11 PM, luser droog wrote:
> 
> I've sometimes considered the idea of writing a fully conforming but
> completely useless implementation of C, primarily for making the point
> that the requirements for full conformance are a lot weaker than many
> people think (including some of the people who had a role in creating
> those requirements).
> Creating a useless implementation would be a lot simpler than writing a
> useful implementation, but (because #error directives have to be handled
> correctly) it requires correctly implementing all of translation phases
> 1-4, which is sufficiently complicated to make the project interesting.
>
Very geeky thing to do, in the bad sense of the term.

Whilst the project isn't entirely trivial, it's not really "interesting",
the standard is just a human construct, it's subject to fairly regular
revision, and it's not designed for the purpose of preventing useless
but conforming implementations. 

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

#94594

In article <09e74b5b-93b0-411e-a752-97e64bd42734@googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>On Saturday, October 8, 2016 at 4:53:53 AM UTC+1, James Kuyper wrote:
>> On 10/07/2016 09:11 PM, luser droog wrote:
>> 
>> I've sometimes considered the idea of writing a fully conforming but
>> completely useless implementation of C, primarily for making the point
>> that the requirements for full conformance are a lot weaker than many
>> people think (including some of the people who had a role in creating
>> those requirements).
>> Creating a useless implementation would be a lot simpler than writing a
>> useful implementation, but (because #error directives have to be handled
>> correctly) it requires correctly implementing all of translation phases
>> 1-4, which is sufficiently complicated to make the project interesting.
>>
>Very geeky thing to do, in the bad sense of the term.
>
>Whilst the project isn't entirely trivial, it's not really "interesting",
>the standard is just a human construct, it's subject to fairly regular
>revision, and it's not designed for the purpose of preventing useless
>but conforming implementations. 

Which is kinda the same thing as when people insist that the Bible is
literally true, exact in all its particulars, except, of course, when it
isn't, and/or when it either says something that is manifestly silly or
something that is inconvenient to the speaker's agenda.

This all true, given the high regard and worshipful stance the regs here
have taken towards the standard.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain in
compliance with said RFCs, the actual sig can be found at the following web address:
	http://www.xmission.com/~gazelle/Sigs/Seneca

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web