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

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

One works, the other doesn't?

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

Contents

  One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-03 17:39 -0500
    Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-04 00:20 +0000
    Re: One works, the other doesn't? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-04 06:53 +0000
    Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-04 09:45 -0500
      Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 10:34 -0500
        Re: One works, the other doesn't? mark.bluemel@gmail.com - 2019-11-05 07:45 -0800
          Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 10:53 -0500
            Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 08:04 -0800
              Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 11:29 -0500
                Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-05 23:24 +0100
                  Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-05 23:06 +0000
                    Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 12:31 +1300
                      Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-05 23:43 +0000
                        Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 12:54 +1300
                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 01:35 +0000
                            Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-06 15:16 +1300
                              Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 11:11 +0000
                          Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 01:59 -0800
                            Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 11:35 +0100
                              Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 08:57 -0800
                                Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:24 +1300
                                Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 22:59 +0100
                                  Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 14:37 -0800
                                    Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 00:58 +0100
                                      Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 02:08 -0800
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 15:43 +0100
                                          Re: One works, the other doesn't? Robert Wessel <robertwessel2@yahoo.com> - 2019-11-07 16:15 -0600
                                    Re: One works, the other doesn't? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-10 20:01 +0000
                                      Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-11 15:26 +1300
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-11 12:37 +0100
                            Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:21 +1300
                              Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 10:39 -0800
                                Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 07:47 +1300
                                Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-07 08:14 +1300
                                  Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-06 12:30 -0800
                                  Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 21:04 -0800
                                    Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 01:37 -0800
                                      Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 01:38 -0800
                                    Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-10 08:32 +1300
                                      Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:09 -0800
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-29 11:33 +0100
                                          Re: One works, the other doesn't? Öö Tiib <ootiib@hot.ee> - 2019-11-30 14:20 -0800
                                        Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-12-01 12:15 +1300
                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 10:07 +0100
                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 10:58 +0000
                            Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 10:05 +0100
                    Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 09:52 +0100
                      Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-06 00:56 -0800
                        Re: One works, the other doesn't? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-06 01:00 -0800
                      Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 11:32 +0000
                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-06 23:11 +0100
                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-06 23:22 +0000
                            Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 01:04 +0100
                              Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 01:13 +0000
                                Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 10:22 +0100
                                  Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 11:51 +0000
                                    Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 15:58 +0100
                                      Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 16:34 +0000
                                        Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-07 12:40 -0500
                                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 17:57 +0000
                                            Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-07 21:14 -0800
                                              Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-08 09:45 +0000
                                                Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-08 09:56 -0800
                                                  Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-08 19:47 +0000
                                                    Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:14 +1300
                                                    Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-08 19:10 -0800
                                                      Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-09 12:24 +0000
                                                  Like an old married couple... (Was: One works, the other doesn't?) gazelle@shell.xmission.com (Kenny McCormack) - 2019-11-08 20:25 +0000
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 19:58 +0100
                                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 19:31 +0000
                                        Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 08:56 +1300
                                          Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 20:06 +0000
                                            Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 09:21 +1300
                                              Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 21:20 +0000
                                                Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-08 10:28 +1300
                                                  Re: One works, the other doesn't? Bart <bc@freeuk.com> - 2019-11-07 22:35 +0000
                                                    Re: One works, the other doesn't? Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:22 +1300
                                      Re: One works, the other doesn't? jadill33@gmail.com - 2019-11-07 08:37 -0800
                                        Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 08:52 -0800
                                          Re: One works, the other doesn't? jadill33@gmail.com - 2019-11-07 09:52 -0800
                                        Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-07 20:04 +0100
                                        Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 19:50 -0800
              Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 18:05 +0100
                Re: One works, the other doesn't? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 09:28 -0800
                  Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 19:02 +0100
                    Re: One works, the other doesn't? David Brown <david.brown@hesbynett.no> - 2019-11-05 23:21 +0100
                      Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 18:36 +0100
        Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-05 12:51 -0500
          Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 18:35 -0500
            Re: One works, the other doesn't? Barry Schwarz <schwarzb@delq.com> - 2019-11-05 17:53 -0800
            Re: One works, the other doesn't? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-06 09:33 -0500
        Re: One works, the other doesn't? Barry Schwarz <schwarzb@delq.com> - 2019-11-05 13:36 -0800
        Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-07 10:17 +0100
          Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 12:19 +0000
            Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-07 18:59 +0100
              Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 00:02 +0000
                Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-20 10:54 +0100
                  Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-20 11:14 +0000
                    Re: One works, the other doesn't? jak <nospam@please.ty> - 2019-11-20 13:22 +0100
                      Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:54 -0800
                    Re: One works, the other doesn't? Keith Thompson <kst-u@mib.org> - 2019-11-20 08:42 -0800
                      Re: One works, the other doesn't? Manfred <noname@add.invalid> - 2019-11-21 18:56 +0100
                        Re: One works, the other doesn't? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-22 01:07 +0000
                          Re: One works, the other doesn't? Manfred <noname@add.invalid> - 2019-11-22 15:27 +0100
                  Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 15:47 -0800
          Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-07 18:41 -0500
      Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 17:39 +0100
        Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-05 11:47 -0500
          Re: One works, the other doesn't? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 17:54 +0100
            Re: One works, the other doesn't? luser droog <luser.droog@gmail.com> - 2019-11-05 09:00 -0800
          Re: One works, the other doesn't? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 21:02 -0800
            Re: One works, the other doesn't? DFS <nospam@dfs.com> - 2019-11-09 02:09 -0500

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

#147758

Bart <bc@freeuk.com> writes:
[...]
> Tcc's treatment is a bit of a cheat, as its windows.h file is one header 
> of 26K lines, while gcc's windows.h file involves nearly 100 headers, 
> hundreds of nested #includes, and 200K lines (all IIRC).

gcc has no windows.h file.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#147761

On 08/11/2019 05:14, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Tcc's treatment is a bit of a cheat, as its windows.h file is one header
>> of 26K lines, while gcc's windows.h file involves nearly 100 headers,
>> hundreds of nested #includes, and 200K lines (all IIRC).
> 
> gcc has no windows.h file.
> 

Then how the hell does it manage to compile this program:

    #include <windows.h>

By magic? Stop being so bloody pedantic.

--------------------------------------------
C:\tdm\x86_64-w64-mingw32\include>dir windows.h

  Directory of C:\tdm\x86_64-w64-mingw32\include

12/05/2018  02:50             2,529 windows.h

---------------------------------------------
C:\mingw0\mingw64\x86_64-w64-mingw32\include>dir windows.h

  Directory of C:\mingw0\mingw64\x86_64-w64-mingw32\include

12/05/2018  02:50             2,529 windows.h


Technically no bare C compiler for Windows need come with windows.h, but 
they all do otherwise they're going to be pretty useless.

This particular one looks tiny, but it just includes a bunch of others, 
which in turn include more (some 500 to 650 total #includes IIRC from 
past experiments, but number of unique headers is under 100).

The number of non-conditional lines processed, if using -E, is only 87K 
lines. The output from that includes lines like this:

  typedef __builtin_va_list __gnuc_va_list;

  void __attribute__((__cdecl__)) __debugbreak(void);
  extern __inline__ __attribute__((__always_inline__,__gnu_inline__))
    void __attribute__((__cdecl__)) __debugbreak(void)
  {
    __asm__ __volatile__("int {$}3":);
  }

which of course is perfectly standard C not aimed at gcc at all.

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

#147789

Bart <bc@freeuk.com> writes:
> On 08/11/2019 05:14, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Tcc's treatment is a bit of a cheat, as its windows.h file is one header
>>> of 26K lines, while gcc's windows.h file involves nearly 100 headers,
>>> hundreds of nested #includes, and 200K lines (all IIRC).
>> 
>> gcc has no windows.h file.
>
> Then how the hell does it manage to compile this program:
>
>     #include <windows.h>
>
> By magic? Stop being so bloody pedantic.

By using a windows.h header provided by something other than gcc.
That's why your "program" failed to compile on my Ubuntu system with
"fatal error: windows.h: No such file or directory".

Stop pretending not to know things you obviously do know.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#147795

On 08/11/2019 17:56, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 08/11/2019 05:14, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> Tcc's treatment is a bit of a cheat, as its windows.h file is one header
>>>> of 26K lines, while gcc's windows.h file involves nearly 100 headers,
>>>> hundreds of nested #includes, and 200K lines (all IIRC).
>>>
>>> gcc has no windows.h file.
>>
>> Then how the hell does it manage to compile this program:
>>
>>      #include <windows.h>
>>
>> By magic? Stop being so bloody pedantic.
> 
> By using a windows.h header provided by something other than gcc.
> That's why your "program" failed to compile on my Ubuntu system with
> "fatal error: windows.h: No such file or directory".

The person I was replying to has acknowledged that adding windows.h to a 
program slows down gcc.

The probability is that anyone running gcc on Windows and using 
windows.h will be compiling the rather elaborate version that is 
normally used with that compiler.

I was pointing out that other compilers can come with more lightweight 
versions of windows.h, which coupled with a brisker compiler anyway, 
gives them a bit of misleading advantage.

That windows.h doesn't normally compile on Linux with either tcc or gcc 
is not adding anything useful.


> Stop pretending not to know things you obviously do know.

No, just stop with the pedantics.

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

#147797

On 09/11/2019 08:47, Bart wrote:
> On 08/11/2019 17:56, Keith Thompson wrote:
> 
>> Stop pretending not to know things you obviously do know.
> 
> No, just stop with the pedantics.

Ah, so you admit to pretending not to know things you obviously do know 
and are simply unwilling to stop!

:)

-- 
Ian.

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

#147805

Bart <bc@freeuk.com> writes:
> On 08/11/2019 17:56, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 08/11/2019 05:14, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> Tcc's treatment is a bit of a cheat, as its windows.h file is one header
>>>>> of 26K lines, while gcc's windows.h file involves nearly 100 headers,
>>>>> hundreds of nested #includes, and 200K lines (all IIRC).
>>>>
>>>> gcc has no windows.h file.
>>>
>>> Then how the hell does it manage to compile this program:
>>>
>>>      #include <windows.h>
>>>
>>> By magic? Stop being so bloody pedantic.
>>
>> By using a windows.h header provided by something other than gcc.
>> That's why your "program" failed to compile on my Ubuntu system with
>> "fatal error: windows.h: No such file or directory".
>
> The person I was replying to has acknowledged that adding windows.h to
> a program slows down gcc.

I don't doubt that.  What does it have to do with the point I was making?

> The probability is that anyone running gcc on Windows and using
> windows.h will be compiling the rather elaborate version that is
> normally used with that compiler.

Which version?

I have a Windows 10 laptop with Cygwin.  I have several different gcc
compilers installed under Cygwin:

    i586-pc-msdosdjgpp-gcc.exe
    i686-w64-mingw32-gcc.exe
    x86_64-pc-cygwin-gcc.exe (the default)
    x86_64-w64-mingw32-gcc.exe

If I run
    gcc -E c.c | wc
where c.c contains a single line:
    #include <windows.h>
I can see how much code the <windows.h> header expands to.
i586-pc-msdosdjgpp-gcc.exe can't find a <windows.h> header.  The others
all show different sizes.  These compilers are all gcc.  In all cases,
the <windows.h> header is not provided by gcc; it's provided by a
different Cygwin package.

If I run
    clang -E c.c | wc
it shows yet another different size.  It uses the same <windows.h>
header used with gcc -- which, again, is not provided by gcc (or
by clang).

Presumably I'd get similar results if I looked at C implementations
installed on Windows outside of Cygwin.

> I was pointing out that other compilers can come with more lightweight
> versions of windows.h, which coupled with a brisker compiler anyway,
> gives them a bit of misleading advantage.

Sure, some compilers are packaged with a windows.h header, among
other things.  gcc is not.  There are packages that include both
a version of gcc and a windows.h header.  There are also packages
that include just one or the other.

gcc does not provide <windows.h>.  It's likely that whatever package
you're using provides both gcc and <windows.h>.  That package is
not gcc.

> That windows.h doesn't normally compile on Linux with either tcc or
> gcc is not adding anything useful.

>> Stop pretending not to know things you obviously do know.
>
> No, just stop with the pedantics.

No, just stop trying to mislead people.

gcc has no windows.h file.  Someone who only read your posts wouldn't
know that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#147825

On 09/11/2019 03:10, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

> 
>> The probability is that anyone running gcc on Windows and using
>> windows.h will be compiling the rather elaborate version that is
>> normally used with that compiler.
> 
> Which version?
> 
> I have a Windows 10 laptop with Cygwin.  I have several different gcc
> compilers installed under Cygwin:
> 
>      i586-pc-msdosdjgpp-gcc.exe
>      i686-w64-mingw32-gcc.exe
>      x86_64-pc-cygwin-gcc.exe (the default)
>      x86_64-w64-mingw32-gcc.exe
> 
> If I run
>      gcc -E c.c | wc
> where c.c contains a single line:
>      #include <windows.h>
> I can see how much code the <windows.h> header expands to.
> i586-pc-msdosdjgpp-gcc.exe can't find a <windows.h> header.  The others
> all show different sizes.  These compilers are all gcc.  In all cases,
> the <windows.h> header is not provided by gcc; it's provided by a
> different Cygwin package.
> 
> If I run
>      clang -E c.c | wc
> it shows yet another different size.  It uses the same <windows.h>
> header used with gcc -- which, again, is not provided by gcc (or
> by clang).
> 
> Presumably I'd get similar results if I looked at C implementations
> installed on Windows outside of Cygwin.

OK, I was wrong.

It is not possible to say that a fast compiler plus small windows.h has 
an extra advantage compared with a slow compiler plus large windows.h.

Because sometimes, that slow compiler could conceivably also have a 
small windows.h, or might not have one at all.

Sorry for the noise.

(I also see now that I wasted my time creating windows.h for my own 
compiler, as no one expects it to be provided.)

What I might suggest to the OP, if they still want to use windows.h with 
gcc and it is still slow, is:

* Locate where windows.h is on their gcc installation

* Create a precompiled header windows.h.pch using:

     gcc -c windows.h

* Use gcc as normal; the compilation of windows.h should be much faster

(Although on my system, tcc is still three times the speed even compared 
with gcc plus precompiled header.)

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

#147799 — Like an old married couple... (Was: One works, the other doesn't?)

In article <lneeyi45hh.fsf@kst-u.example.com>,
Keith Thompson  <kst-u@mib.org> wrote:
...
>>> gcc has no windows.h file.
>>
>> Then how the hell does it manage to compile this program:
>>
>>     #include <windows.h>
>>
>> By magic? Stop being so bloody pedantic.

Indeed.  Quite so.

But he's been like this for decades.  It's not likely to change.

>By using a windows.h header provided by something other than gcc.
>That's why your "program" failed to compile on my Ubuntu system with
>"fatal error: windows.h: No such file or directory".
>
>Stop pretending not to know things you obviously do know.

You two are so adorable.  Don't stop on my accord.

Or for any other reason!

-- 
It's possible that leasing office space to a Starbucks is a greater liability
in today's GOP than is hitting your mother on the head with a hammer.

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

#147738

On 07/11/2019 17:34, Bart wrote:
> On 07/11/2019 14:58, David Brown wrote:
>> On 07/11/2019 12:51, Bart wrote:
> 
>>> Makefiles are not the only fruit.
>>
>> We are talking about C, not your private language.
> 
> My second example was for C.
> 
>> Non-negligible
>> projects need some kind of build process.  Makefiles are one way to
>> express these - there are other ways.  The point is that "the compiler
>> is so fast you don't need a Makefile" is a complete misunderstanding on
>> the purpose of Makefiles - they are not just about the efficiency of
>> incremental builds.
>>
>> If I want fast compilation for incremental builds, I can use ccache - it
>> will tear through C files in a fraction of the time tcc takes, when
>> re-compiling the same code (and the same options).  I still need a
>> Makefile, because build procedures are important.
> 
> I believe the point of that feature is that it is so fast, that you 
> don't need to bother with makefiles which specify dependencies so that 
> it can work out what needs compiling and what doesn't. And neither do 
> you need a tool like 'ccache', which I understand gets its speed by 
> avoiding doing any work as much as possible.

I use make to get the build procedure I need - building the right parts 
of the code in the right way and the right order.  It is a place to 
specify and document compiler switches (as you know, I use many - 
regardless of the compiler), along with other tools in the process. 
That can include support for "make test", "make release", "make sim", or 
whatever else you need for the kind of project you are working on.  I 
think good dependency management is very useful, but I'd use make (or a 
similar tool) even if it didn't avoid unnecessary re-compilation - a 
correct, documented and repeatable build process is more important than 
a fast one.

And avoiding doing unnecessary work is better than doing unnecessary 
work quickly.

> 
> With build-from-scratch times of a fraction of a second, depending on 
> project size and machine speed, there's no point.
> 

I thought you were in favour of being as fast as possible, and that 
"even faster" is better than "fast enough" in your book?

>> Yes, it is impressive.  I used to be able to juggle 5 balls - that's
>> impressive too.  Neither is a useful trick for programming work.
> 
> In my work which is based around whole-project compilation, it /is/ useful.

What is the point of whole-project compilation?  (I appreciate your 
preference for single source code distribution - I don't agree that it 
is important, but I understand why you want it.)  For most people, 
whole-program compilation is about optimisation and/or cross-unit static 
analysis.  There is a point in using LTO or "-fwhole-program" in tools 
like gcc and clang.  But no point for a compiler that doesn't do 
inter-procedural optimisations and analysis.

> 
>>> Imagine that every time you wanted to run gcc, you had to build gcc from
>>> scratch first.
>>>
>>
>> Imagine if you had to rebuild your car's engine every time you filled up
>> with petrol.  What is your point here, other than giving our
>> imaginations a little exercise?
> 
> That's pretty much what happens with every scripting language. Why are 
> /they/ rebuilding their engines every time?

They are not.  I thought you knew how scripting languages work.

> 
>>> tcc is a good match for my compiler, because they are both very fast. If
>>> using gcc, it's like hitting a brick wall as soon as it starts gcc, even
>>> using -O0. Eg (mu.ma is a 25Kloc compiler in my language):
>>
>> The requirements for a compiler handling generated code are very
>> different from what you want from a compiler as a development tool.
> 
> You're getting close to acknowledging that small, fast compilers may 
> possibly be of utility after all.
> 
> 

I think you'll find I have often said there was a place for them.  But 
that place is not for normal software development.  Your selective 
memory is playing tricks on you again.

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

#147740

On 07/11/2019 18:58, David Brown wrote:
> On 07/11/2019 17:34, Bart wrote:


>> In my work which is based around whole-project compilation, it /is/ 
>> useful.
> 
> What is the point of whole-project compilation?

What is the point of whole-module compilation? Compared with doing a 
function at a time. I'm just changing the granularity of an independent 
compilation unit from a single module, to a single program/library (ie. 
one .exe/.dll file).

This eliminates figuring out dependencies between modules (so as to 
decided what to compile first, or next), simplifies interfacing, makes 
more possible more efficient compilation by creating a global symbol 
table once, and each module and its interface is processed exactly once 
per program build (instead of N times for N independently-compiled 
shared modules as happens in C).

If I was into optimisation, then this also provides innumerable extra 
opportunities, as the entire source of the program is visible.

It also eliminates the need for extra information (ie. via makefiles) 
that specify the modules that comprise a project. You just specify the 
lead module, and everything else is derived from that.

In short, there are lots of good reasons.

There are still external interfaces to define and maintain, but those 
are now moved to inter-program interfaces (between .exe and .dlls for 
example), which are more stable, tend not to be circular, and are 
usually binaries not source code. And, often, those libraries are 
someone else's responsibility, and may be provided by the OS.

>> That's pretty much what happens with every scripting language. Why are 
>> /they/ rebuilding their engines every time?
> 
> They are not.  I thought you knew how scripting languages work.

They are usually run-from-source. So you will start with a lead module 
(like my whole-project compilers) and that will import others as needed. 
Some interpreters may implement caching of byte-code files, but that's 
an optional feature.

I don't mean compile the source code of the interpreter as well as the 
source code of the programs into byte-code.

But now that that has been brought up, if I try that on my interpreter, 
it adds 0.2 seconds to the overall time of compiling/running a dynamic 
program from source.

So compiling the interpreter from scratch (56Kloc) adds 0.2 seconds (I 
suspect it will be a little longer with CPython).

> I think you'll find I have often said there was a place for them.  But 
> that place is not for normal software development.

Well, I say it CAN be for normal development. Obviously not yours.

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

#147742

On 08/11/2019 05:34, Bart wrote:
> 
> In my work which is based around whole-project compilation, it /is/ useful.
> 
Most of us work in teams. One hundred people working on one source file 
would certainly be interesting..

-- 
Ian.

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

#147743

On 07/11/2019 19:56, Ian Collins wrote:
> On 08/11/2019 05:34, Bart wrote:
>>
>> In my work which is based around whole-project compilation, it /is/ 
>> useful.
>>
> Most of us work in teams. One hundred people working on one source file 
> would certainly be interesting..
> 

Then you entirely misunderstand what whole-project compilation means.

A program (this means one program unit like .exe) can still comprise 100 
modules (and those can be developed by different people).

But when you submit the lead module to the compiler (the only module 
that can be submitted to build the entire program rather than a subset), 
then it will always pick up those other 99.

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

#147744

On 08/11/2019 09:06, Bart wrote:
> On 07/11/2019 19:56, Ian Collins wrote:
>> On 08/11/2019 05:34, Bart wrote:
>>>
>>> In my work which is based around whole-project compilation, it /is/
>>> useful.
>>>
>> Most of us work in teams. One hundred people working on one source file
>> would certainly be interesting..
>>
> 
> Then you entirely misunderstand what whole-project compilation means.
> 
> A program (this means one program unit like .exe) can still comprise 100
> modules (and those can be developed by different people).
> 
> But when you submit the lead module to the compiler (the only module
> that can be submitted to build the entire program rather than a subset),
> then it will always pick up those other 99.

That wouldn't scale very well to a large project, would it?  A clean 
build of ours builds around 3000 source files three times (three target 
platforms).

-- 
Ian.

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

#147748

On 07/11/2019 20:21, Ian Collins wrote:

>> But when you submit the lead module to the compiler (the only module
>> that can be submitted to build the entire program rather than a subset),
>> then it will always pick up those other 99.
> 
> That wouldn't scale very well to a large project, would it?

Probably not to 3000 files, although I don't know how big they are, 
maybe they're only 10 lines each.

But plenty of programs are smaller. Should we forget about simple 
solutions to building most software because a few projects are huge?

> A clean 
> build of ours builds around 3000 source files three times (three target 
> platforms).

Also I'm not in charge of your project. I probably wouldn't have 3000 
normal-sized modules forming one monolithic executable. I'd split it 
into into independent libraries, and use as much scripting as possible.

(And if I was in charge, it likely wouldn't be that big in the first place.)

My scheme probably has an upper limit for one program of 100K to 500Kloc 
depending on the speed of the machine, before clean-build-time becomes 
too annoying (ie. exceeds 0.5 to 1 second, depending on the individual).

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

#147749

On 08/11/2019 10:20, Bart wrote:
> On 07/11/2019 20:21, Ian Collins wrote:
> 
>>> But when you submit the lead module to the compiler (the only module
>>> that can be submitted to build the entire program rather than a subset),
>>> then it will always pick up those other 99.
>>
>> That wouldn't scale very well to a large project, would it?
> 
> Probably not to 3000 files, although I don't know how big they are,
> maybe they're only 10 lines each.
> 
> But plenty of programs are smaller. Should we forget about simple
> solutions to building most software because a few projects are huge?

For many, a simple makefile is a simple solution!

>> A clean
>> build of ours builds around 3000 source files three times (three target
>> platforms).
> 
> Also I'm not in charge of your project. I probably wouldn't have 3000
> normal-sized modules forming one monolithic executable. I'd split it
> into into independent libraries, and use as much scripting as possible.

For an embedded system?  Yeah right!  We do use independent libraries, 
lots of them but doesn't that go against your whole-project compilation?

> (And if I was in charge, it likely wouldn't be that big in the first place.)

The size and complexity of the code is governed by the size and 
complexity of the problem it is solving.

-- 
Ian.

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

#147753

On 07/11/2019 21:28, Ian Collins wrote:
> On 08/11/2019 10:20, Bart wrote:
>> On 07/11/2019 20:21, Ian Collins wrote:

>>> That wouldn't scale very well to a large project, would it?
>>
>> Probably not to 3000 files, although I don't know how big they are,
>> maybe they're only 10 lines each.
>>
>> But plenty of programs are smaller. Should we forget about simple
>> solutions to building most software because a few projects are huge?
> 
> For many, a simple makefile is a simple solution!

If I type 'make', it says "'make' is not recognised as an internal or 
external command". That's a good start! No, it hardly ever works me and 
something always seems to go wrong.

So even if it is simple, it's not much use when it's unreliable.

>> Also I'm not in charge of your project. I probably wouldn't have 3000
>> normal-sized modules forming one monolithic executable. I'd split it
>> into into independent libraries, and use as much scripting as possible.
> 
> For an embedded system?  Yeah right!

If it's powerful enough to run programs with 3000 modules (although I 
still don't know the total line count), then why not? I started adding 
scripting to my applications around 1985 I think. Is your device less 
powerful than a mid-80s PC?

   We do use independent libraries,
> lots of them but doesn't that go against your whole-project compilation?

Whole-project is rather a misnomer, it's just that my projects now are 
single executables. As I said in an earlier post, I use a compilation 
unit of one .exe or .dll (or one byte-code file for dynamic code), 
rather than one module.

> The size and complexity of the code is governed by the size and 
> complexity of the problem it is solving.

It seems to me that a lot of software expands to fit the resources 
available. But when the resources are extensive, it can mean not only 
some pretty big programs, but plenty of layers of software too. That 
might explain why a smartphone can take a couple of minutes to start 
from cold, my virtual Linux takes 6 minutes, and my Windows can take 
5-10 minutes from cold to get stable.

When I had VS2017 installed, if I inadvertently started it (clicking on 
a file with VS-aware extension), it would take a minute and a half 
before I could shut it down again.

(VS I understand is a project with files measured in the millions. The 
last figure I read was 1.5 million, and that was a decade ago.)

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

#147798

On 08/11/2019 11:35, Bart wrote:
> On 07/11/2019 21:28, Ian Collins wrote:
>> On 08/11/2019 10:20, Bart wrote:
>>> On 07/11/2019 20:21, Ian Collins wrote:
> 
>>>> That wouldn't scale very well to a large project, would it?
>>>
>>> Probably not to 3000 files, although I don't know how big they are,
>>> maybe they're only 10 lines each.
>>>
>>> But plenty of programs are smaller. Should we forget about simple
>>> solutions to building most software because a few projects are huge?
>>
>> For many, a simple makefile is a simple solution!
> 
> If I type 'make', it says "'make' is not recognised as an internal or
> external command". That's a good start! No, it hardly ever works me and
> something always seems to go wrong.

Ah the joys of Windows...

>>> Also I'm not in charge of your project. I probably wouldn't have 3000
>>> normal-sized modules forming one monolithic executable. I'd split it
>>> into into independent libraries, and use as much scripting as possible.
>>
>> For an embedded system?  Yeah right!
> 
> If it's powerful enough to run programs with 3000 modules (although I
> still don't know the total line count), then why not? I started adding
> scripting to my applications around 1985 I think. Is your device less
> powerful than a mid-80s PC?

No, but it runs ever more complex real-time machine controls for ever 
more complex machines...

>     We do use independent libraries,
>> lots of them but doesn't that go against your whole-project compilation?
> 
> Whole-project is rather a misnomer, it's just that my projects now are
> single executables. As I said in an earlier post, I use a compilation
> unit of one .exe or .dll (or one byte-code file for dynamic code),
> rather than one module.

That's more manageable if your libraries are small enough.  It's still 
more time efficient to compile individual sources files, especially if 
you are optimising.

>> The size and complexity of the code is governed by the size and
>> complexity of the problem it is solving.
> 
> It seems to me that a lot of software expands to fit the resources
> available. 

Ours expands to meet ever changing and growing market expectations.

-- 
Ian.

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

#147721

On Thursday, November 7, 2019 at 9:58:31 AM UTC-5, David Brown wrote:
> On 07/11/2019 12:51, Bart wrote:
> > On 07/11/2019 09:22, David Brown wrote:
> >> On 07/11/2019 02:13, Bart wrote:
> > 
> >>> So why was it made fast?
> >>
> >> It doesn't do much (in comparison to bigger compilers), so it can be
> >> small and fast.  In particular, as far as I know it doesn't do any kind
> >> of inter-procedural analysis, which is something that takes a lot of
> >> time and resources in a compiler but is very important for both
> >> optimisation and static analysis.  It does not handle multiple
> >> languages, multiple targets and multiple devices within a family - so it
> >> does not need the layers of abstraction in between stages.
> > 
> > So if using TCC to develop C programs for x86, x64, ARM and ARM64, it's
> > no good because it doesn't support 996 other processors, and it isn't
> > part of a product chain that can also compile C++, Ada and Fortran?
> 
> I said the limited features are one of the reasons tcc can be small and
> fast.
> 
> > 
> > It sounds to me like, if that is how you can streamline a compiler, then
> > what's the problem?
> > 
> >> As I have said before, I think it is impressive how much TCC can do in
> >> such a small code space and run time.
> > 
> > (For 'impressive', look at LuaJIT, which is a 225KB executable that
> > appears to be a complete Lua implementation with a tracing JIT compiler.
> > C source is a nightmare though...)
> > 
> >> But it is not the tool to use for
> >> development.
> > 
> > Yes you keep saying that. But not everyone is you with your very
> > exacting requirements.
> > 
> >>> TCC compiles so fast that even for big projects Makefiles may not be
> >>> necessary.
> >>
> >> That only applies if you don't know what Makefiles are for, and how
> >> project management works.  Or if you only write "hello, world" programs.
> > 
> > My projects aren't that big, but they're a long way from being hello,
> > world programs. Yet they don't need makefiles. The biggest one is built
> > like this:
> > 
> >    C:\qcc>mm qq
> >    Compiling qq.m to qq.exe
> > 
> > Which processes 56 files totalling 56,000 lines. 'mm.exe' is a bare
> > compiler. While, getting back to C, I can build Seed7 like this:
> > 
> >    C:\seed79\src>bcc @s7
> >    ....
> > 
> > where s7 is simply a list of the modules that are needed. This will also
> > work with gcc and lcc (depending on whether compiler-specific options
> > are inside that @ file).
> > 
> > Makefiles are not the only fruit.
> 
> We are talking about C, not your private language.  Non-negligible
> projects need some kind of build process.  Makefiles are one way to
> express these - there are other ways.  The point is that "the compiler
> is so fast you don't need a Makefile" is a complete misunderstanding on
> the purpose of Makefiles - they are not just about the efficiency of
> incremental builds.

You can go even further, non-negligible projects need some kind of
*repeatable* build process, independent of the whims of individual
developers.  Bart's perspective appears to be one completely insulated
from the problems that come with multi-staff driven development.  In
my work, developers are not the final builders of the end-product,
it's configuration management, and they know nothing of picking
compiler options or IDE configuration, nor do they want to know.

When I came on, the old procedures were a badly formatted document
with a laundry list of manually written commands for source control
and building an application whose components were written in multiple
languages using multiple IDEs.  Through a combination of Makefiles and
batch scripts, I was able to reduce the human error component of people
who are not developers to mis-specifying the version number and target
platform.  The amount of baby-sitting I have to do now is practically
zero.  It typically only breaks when a new version of a compiler or tool
is introduced.

It wasn't free though, the batch script is about 2000 lines and the
Makefile/Ant configs are couple 100 and it took me about 2-3 months
to create from scratch.  Now you rotate in a new configuration
management person, and the time savings are much more real.

[snip]

Best regards,
John D.

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

#147723

On Thursday, 7 November 2019 16:37:32 UTC, jadi...@gmail.com  wrote:
> 
> You can go even further, non-negligible projects need some kind of
> *repeatable* build process, independent of the whims of individual
> developers.  Bart's perspective appears to be one completely insulated
> from the problems that come with multi-staff driven development.  In
> my work, developers are not the final builders of the end-product,
> it's configuration management, and they know nothing of picking
> compiler options or IDE configuration, nor do they want to know.
> 
> When I came on, the old procedures were a badly formatted document
> with a laundry list of manually written commands for source control
> and building an application whose components were written in multiple
> languages using multiple IDEs.  Through a combination of Makefiles and
> batch scripts, I was able to reduce the human error component of people
> who are not developers to mis-specifying the version number and target
> platform.  The amount of baby-sitting I have to do now is practically
> zero.  It typically only breaks when a new version of a compiler or tool
> is introduced.
> 
> It wasn't free though, the batch script is about 2000 lines and the
> Makefile/Ant configs are couple 100 and it took me about 2-3 months
> to create from scratch.  Now you rotate in a new configuration
> management person, and the time savings are much more real.
> 
The build system breaks, so you add another layer to patch it up, and
it works with maybe a few simple commandline flags.

However this approach has a limit. As you add more and more layers,
there are more and more things to go wrong, and it gets more and
more difficult to find a trouble shooter who can fix things when
they do go wrong. 

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

#147729

On Thursday, November 7, 2019 at 11:52:42 AM UTC-5, Malcolm McLean wrote:
> On Thursday, 7 November 2019 16:37:32 UTC, jadi...@gmail.com  wrote:
> > 
> > You can go even further, non-negligible projects need some kind of
> > *repeatable* build process, independent of the whims of individual
> > developers.  Bart's perspective appears to be one completely insulated
> > from the problems that come with multi-staff driven development.  In
> > my work, developers are not the final builders of the end-product,
> > it's configuration management, and they know nothing of picking
> > compiler options or IDE configuration, nor do they want to know.
> > 
> > When I came on, the old procedures were a badly formatted document
> > with a laundry list of manually written commands for source control
> > and building an application whose components were written in multiple
> > languages using multiple IDEs.  Through a combination of Makefiles and
> > batch scripts, I was able to reduce the human error component of people
> > who are not developers to mis-specifying the version number and target
> > platform.  The amount of baby-sitting I have to do now is practically
> > zero.  It typically only breaks when a new version of a compiler or tool
> > is introduced.
> > 
> > It wasn't free though, the batch script is about 2000 lines and the
> > Makefile/Ant configs are couple 100 and it took me about 2-3 months
> > to create from scratch.  Now you rotate in a new configuration
> > management person, and the time savings are much more real.
> > 
> The build system breaks, so you add another layer to patch it up, and
> it works with maybe a few simple commandline flags.
> 
> However this approach has a limit. As you add more and more layers,
> there are more and more things to go wrong, and it gets more and
> more difficult to find a trouble shooter who can fix things when
> they do go wrong.

The limit is when you have no one willing to learn the tools needed
to maintain the functionality of the build system in place.  Where
you earn your marbles is whether your code and documentation provides
for someone else to take the mantle with as few headaches as
possible.  I'm actually no longer maintaining the build scripts and
Makefiles, it's been passed on to someone else.  Hopefully you pass
it on to someone who is passionate about learning new things.

It's also a matter of scope.  If your development team is small and
localized, then the scope of your configuration control and build
system can scale back to whatever is convenient.

Best regards,
John D.

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

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

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

csiph-web