In no particular order.

* Software development can ONLY be done on a Unix-related OS

* It is impossible to develop any software, let alone C, on pure Windows

* You can spend decades developing and implementing systems languages at
the level of C, but you still apparently know nothing of the subject

* You can spend a decade developing whole-program compilers and a
suitably matched language, and somebody can still lecture you on exactly
what a whole-language compiler is, because you've got it wrong

* No matter how crazy the interface or behaviour of some Linux utility,
no one is ever going to admit there's anything wrong with it

* Every single tool I've written, is a toy.

* Every single project I've worked on, is a toy (even if it made my
company millions)

* No one should post or link code here, unless it passes '-std=c99
-pedantic-errors'

* Discussing build systems for C, is off-topic

* Discussing my C compiler, is off-topic, but discussing gcc is fine

* Nobody here apparently knows how to build a program consisting purely
of C source files, using only a C compiler.

* Simply enumerating the N files and submitting them to the compiler in
any of several easy methods seems to be out of the question. Nobody has
explained why.

* Nearly everyone here is working on massively huge and complex
projects, which all take from minutes to hours for a full build.

* Hardly anybody here has a project which can be built simply by
compiling and linking all the modules. Even Tim Rentsch's simplest
project has a dizzying set of special requirements.

* Funnily enough, every project I /have/ managed to build with my
compilers after eventually getting through the complexity, /has/ reduced
down to a simple list of .c files.

* The Tiny C compiler, is a toy. Even though you'd have trouble telling,
from the behaviour of a binary, whether or not it was built with tcc.

* Actually, any C compiler that is not gcc, clang, or possibly MSVC, is
a toy. Unless you have to buy it.

* There's is nothing wrong with AT&T assembly syntax

* There's especially nothing wrong with AT&T syntax written as a series
of string literals, with extra % symbols, together with \n and \t escapes.

* There is not a single feature of my alternate systems language that is
superior to the C equivalent

* There is not even a single feature that is worth discussing as a
possible feature of C

* There is nothing in my decades of implementing such languages (even
implementing C), that makes my views on such possible features have any
weight at all

* Having fast compilation speed of C is of no use to anyone and
impresses nobody.

* Having code where you naughtily cast a function pointer to or from a
function pointer is a no-no. No matter that the whole of C is widely
regarded as unsafe.

* Nobody here is interested in a simple build system for C. Not even my
idea of a README simply listing the files needed, and any special steps,
to accompany the usual makefiles.

* There is no benefit at all in having a tool like a compiler, be a
small, self-contained executable.

* Generated C code is not real C code.

* I should use makefiles myself for my own language, even though the
build-process is always one, simple, indivisable command that usually
completes in 1/10th of a second.

* Makefiles should be for everything.

* There's no problem in having to specify those pesky .c extensions to
compiler input files, or adding that -o option

* But it's too much work to specify a filename to 'make', or to even
remember what your project is called

* Linux /does/ use .c and .s extensions to distinguish between file contents

* But Linux also uses a.out to mean both an executable and an object
file. Huh.

* C added a 'text' mode to to convert \n to/from CRLF when Windows came
along.

* Somebody who's only developed under Unix, and using a plethora of
ready-made tools and utilities, is not in a bubble.

* But somebody who's developed under a range of other environments
spanning eras, is the one who's been in their own bubble.

* I was crazy to write '1M' lines of code (I've no idea how much) in my
private language

* I am apparently ignorant, a moron and might even be a BOT.

* I am allowed to have strong opinions, but I will always be wrong.

Shall I post this pile of crap or not?

I really need to get back to some of those pointless, worthless toy
projects of mine.

So here goes....

On 2024-02-05, bart <bc@freeuk.com> wrote:
>
> In no particular order.
>
> * Software development can ONLY be done on a Unix-related OS
>
> * It is impossible to develop any software, let alone C, on pure Windows

I've developed on DOS, Windows as well as for DSP chips and some
microcontrollers. I find most of the crap that you say is simply wrong.

Speaking of Windows, the CL.EXE compiler does not know where its
include files are. You literally cannot do "cl program.c".
You have to give it options which tell it where the SDK is installed:
where the headers and libraries are.

The Visual Studio project-file-driven build build system passes all
those details to every invocation of CL.EXE. Your project file (called
a "solution" nowadays) includes information like the path where your SDK
is installed. In the GUI there is some panel where you specify it.

If I'm going to be doing programming on Windows today, it's either going
be some version of that CL.EXE compiler from Microsoft, or GCC.

> * You can spend decades developing and implementing systems languages at
> the level of C, but you still apparently know nothing of the subject

There is forty years of experience and then there is 8 years, five times
over again.

> * You can spend a decade developing whole-program compilers and a
> suitably matched language, and somebody can still lecture you on exactly
> what a whole-language compiler is, because you've got it wrong

Writing a compiler is pretty easy, because the bar can be set very low
while still calling it a compiler.

Whole-program compilers are easier because there are fewer requirements.
You have only one kind of deliverable to produce: the executable.
You don't have to deal with linkage and produce a linkable format.

> * No matter how crazy the interface or behaviour of some Linux utility,
> no one is ever going to admit there's anything wrong with it

That is false; the stuff has a lot of critics, mostly from the inside
now. (Linux outsiders are mostly a lunatic fringe nowadays. The tables
have turned.)

You don't seem to understand that the interfaces tools that are not
directly invoked by people don't matter, as long as they are reliable.

And then, interfaces that are exposed to user are hard to change, even
if we don't like them, because changes break things. Everyone hates
breaking changes more than they hate the particular syntax of a tool.

The environment is infinitely customizeable. Users have their private
environments which works they way they want. At the command line,
you can use aliases and shell functions to give yourself the ideal
commands you want.

You only have to use the standard commands when writing scripts to be
used by others. And even then, you can include functions which work
the way you want, and then use your functions.

> * Discussing my C compiler, is off-topic, but discussing gcc is fine

GCC is maintained by people who know what a C compiler is, and GCC can
be asked to be one.

You've chosen not to read the C standard, which leaves you unqualified
to even write test cases to validate that something is a C compiler.

Your idea of writing a C compiler seems to be to pick some random
examples of code believed to be C and make them work. (Where "work"
means that they compile and show a few behaviors that look like
the expected ones.)

Basically, you don't present a very credible case that you've actually
written a C compiler.

> * Nobody here apparently knows how to build a program consisting purely
> of C source files, using only a C compiler.
>
> * Simply enumerating the N files and submitting them to the compiler in
> any of several easy methods seems to be out of the question. Nobody has
> explained why.
>
> * Nearly everyone here is working on massively huge and complex
> projects, which all take from minutes to hours for a full build.

That's the landscape. Nobody is going to pay you for writing small
utilities in C. That sort of thing all went to scripting languages.
(It happens from time to time as a side task.)

I currently work on a a firmware application that compiles to a 100
megabyte (stripped!) executable.

> * There is not a single feature of my alternate systems language that is
> superior to the C equivalent

The worst curve ball someone could throw you would be to
be eagerly interested in your language, and ask for guidance
in how to get it installed and start working in it.

Then you're screwed.

As long as you just post to comp.lang.c, you're safe from that.

> * Having fast compilation speed of C is of no use to anyone and
> impresses nobody.

Not as much as fast executable code, unfortunately.

If it takes 10 extra seconds of compilation to shave off a 100
milliseconds off a program, it's worth if it millions of copies of that
program are used.

Most of GCC's run time is spent in optimizing. It's a lot faster
with -O0.

I just measured a 3.38X difference compiling a project with -O0 versus
its usual -O2. This means it's spending over 70% of its time on
optimizing.

The remaining 30% is still kind of slow.

But it's not due to scanning lots of header files.

If I run it with the "-fsyntax-only" option so that it parses all
the syntax, but doesn't produce output, it gets almost 4X faster
(versus -O0, and thus about 13.5X faster compared to -O2).

Mode: | -fsyntax-only | -O0 | -O2 |
Time: | 1.0 | 4.0 | 13.5 |

Thus, about 7.5% is spent on scanning, preprocessing and parsing.
22.2% is spent on the intermediate code processing and target
generation activities, and 70.4 on optimization.

Is it due to decades of legacy code in GCC? Clang is a newer
implementatation, so you might think it's faster than GCC. But it
manages only to be about the same.

Compilers that blaze through large amounts of code in the blink of an
eye are almost certainly dodging on the optimization. And because they
don't need the internal /architecture/ to support the kinds
optimizations they are not doing, they can speed up the code generation
also. There is no need to generate an intermediate representation like
SSA; you can pretty much just parse the syntax and emit assembly code in
the same pass. Particularly if you only target one architecture.

A poorly optimizing retargetable compiler that emits an abstract
intermediate code will never be as blazingly fast as something equally
poorly optimizing that goes straight to code in one pass.

> * Having code where you naughtily cast a function pointer to or from a
> function pointer is a no-no.

Nobody said that, but it was pointed out that this isn't a feature of
the ISO C standard dialect. It's actually a common extension, widely
exploited by programs. There is nothing wrong with using it, but people
who know C understand that it's not "maximally portable". Most code
does not have to anywhere near "maximally portable".

> * There is no benefit at all in having a tool like a compiler, be a
> small, self-contained executable.

Not as much as there used to, decades ago.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2/4/2024 9:58 PM, Kaz Kylheku wrote:
> On 2024-02-05, bart <bc@freeuk.com> wrote:
>>
>> In no particular order.
>>
>> * Software development can ONLY be done on a Unix-related OS
>>
>> * It is impossible to develop any software, let alone C, on pure Windows
>
> I've developed on DOS,

TSR's?

> Windows as well as for DSP chips and some
> microcontrollers. I find most of the crap that you say is simply wrong.
[...]

On 2024-02-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 2/4/2024 9:58 PM, Kaz Kylheku wrote:
>> On 2024-02-05, bart <bc@freeuk.com> wrote:
>>>
>>> In no particular order.
>>>
>>> * Software development can ONLY be done on a Unix-related OS
>>>
>>> * It is impossible to develop any software, let alone C, on pure Windows
>>
>> I've developed on DOS,
>
> TSR's?

I did make a couple of TSRs back in the day, but only as a hobby.

Not in C.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

bart <bc@freeuk.com> writes:

> [...]
>
> * Hardly anybody here has a project which can be built simply by
> compiling and linking all the modules.

Not everyone is working on a project where the deliverable is a
single executable. It's much more difficult to work on a project
where the deliverables form a set of related files that make up a
third-party library, and target multiple platforms.

> Even Tim Rentsch's simplest project has a dizzying set of special
> requirements.

This statement is a misrepresentation, and undoubtedly a deliberate
one. Furthermore how it is expressed is petty and childish.

On 2/4/2024 11:03 PM, Kaz Kylheku wrote:
> On 2024-02-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 2/4/2024 9:58 PM, Kaz Kylheku wrote:
>>> On 2024-02-05, bart <bc@freeuk.com> wrote:
>>>>
>>>> In no particular order.
>>>>
>>>> * Software development can ONLY be done on a Unix-related OS
>>>>
>>>> * It is impossible to develop any software, let alone C, on pure Windows
>>>
>>> I've developed on DOS,
>>
>> TSR's?
>
> I did make a couple of TSRs back in the day, but only as a hobby.
>
> Not in C.
>

Nice. I only messed around with them a couple of times. There was a cool
one, iirc, called key correspondence (KEYCOR), iirc. It was
programmable, and could be used with any program. I used it for a
reporting system and to control WordPerfect 5.1. I still have it! lol.
For legacy purposes.

On 2/4/2024 11:51 PM, Chris M. Thomasson wrote:
> On 2/4/2024 11:03 PM, Kaz Kylheku wrote:
>> On 2024-02-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 2/4/2024 9:58 PM, Kaz Kylheku wrote:
>>>> On 2024-02-05, bart <bc@freeuk.com> wrote:
>>>>>
>>>>> In no particular order.
>>>>>
>>>>> * Software development can ONLY be done on a Unix-related OS
>>>>>
>>>>> * It is impossible to develop any software, let alone C, on pure
>>>>> Windows
>>>>
>>>> I've developed on DOS,
>>>
>>> TSR's?
>>
>> I did make a couple of TSRs back in the day, but only as a hobby.
>>
>> Not in C.
>>
>
> Nice. I only messed around with them a couple of times. There was a cool
> one, iirc, called key correspondence (KEYCOR), iirc. It was
> programmable, and could be used with any program. I used it for a
> reporting system and to control WordPerfect 5.1. I still have it! lol.
> For legacy purposes.

Writing WordPerfect 5.1 macros was a fun time.... ;^o

On 05/02/2024 01:09, bart wrote:
>
> In no particular order.
>
> * Software development can ONLY be done on a Unix-related OS
>
> * It is impossible to develop any software, let alone C, on pure Windows
>
> * You can spend decades developing and implementing systems languages at
> the level of C, but you still apparently know nothing of the subject
>

The tone's currently rather bad, and somehow it has developed that you
and I are on one side and pretty much everyone else on the other. We
both have open source projects which are or at least attempt to be
actually useful to other people, whilst I don't think many of the others
can say that, and maybe that's the underlying reason. But who knows.

I'm trying to improve the tone. It's hard because people have got lots
of motivations for posting, and some of them aren't very compatible with
a good humoured, civilised group. And we've got a lot of bad behaviour,
not all of it directed at us by any means. However whilst you're very
critical of other people's design decisions, I've rarely if ever heard
to say that therefore you criticise someone's general character. But
finally tolerance has snapped.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

2024-02-05, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> schrieb:
> On 2/4/2024 11:51 PM, Chris M. Thomasson wrote:

[Schnipp]

>> Nice. I only messed around with them a couple of times. There was a cool
>> one, iirc, called key correspondence (KEYCOR), iirc. It was
>> programmable, and could be used with any program. I used it for a
>> reporting system and to control WordPerfect 5.1. I still have it! lol.
>> For legacy purposes.
>
> Writing WordPerfect 5.1 macros was a fun time.... ;^o

Writing my own macro-compiler was also fun.
--
Jan v/d Broek
balglaas@dds.nl
Look out, here he comes again
The kid with the replaceable head

On 2024-02-05, bart wrote:
> [...]
> * Nobody here apparently knows how to build a program consisting purely
> of C source files, using only a C compiler.

What does this one mean, exactly? I thought the "compiler" and "linker"
were separate tools used under the umbrella term "compiling".

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 05/02/2024 02:09, bart wrote:
>
> In no particular order.
>

<snip>

>
> Shall I post this pile of crap or not?

No. It is, after all, a pile of crap.

What we have learned about Bart in c.l.c. :

* Bart generally does not read what other people post.

* Bart exaggerates /everything/ - including things no one ever wrote.

* Bart extrapolates /everything/ to get a binary black-or-white
all-or-nothing straw man that he can complain about. If one person says
they do X and not Y, Bart takes that to mean /everyone/ does X and /no
one/ does Y.

* Bart prefers tilting at windmills to learning about C, or indeed
anything in the real world.

* Bart has no interest in what anyone else does, wants or needs.

>
> I really need to get back to some of those pointless, worthless toy
> projects of mine.
>

No, you should go back to doing something you actually /like/. Stop
fighting imaginary battles about problems that don't exist. Stop
winding yourself into a frenzy over nothing.

You don't like C. Find something else that you /do/ like, and use that
instead.

I can't speak for anyone else, but I'd rather you were happily doing
something you are comfortable with, instead of endless gripes and rants
here.

David Brown <david.brown@hesbynett.no> writes:

> On 05/02/2024 02:09, bart wrote:
>> In no particular order.
>>
>
> <snip>
>
>> Shall I post this pile of crap or not?
>
> No. It is, after all, a pile of crap.

Why do you reply so much? I get why Bart posts, but not why you reply
so much? It's not as if gcc (to take one but one example) needs to be
defended from people saying it does it all wrong!

He sometimes posts things that, in my opinion, benefit from a reply.
His "C is so mysterious, how can any one use it posts", for example,
benefit from a reply or two that explains what C's rules really are so
that people coming along later will know what the facts of the matter
are. But there have been none of those lately.

--
Ben.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>bart <bc@freeuk.com> writes:
>
>> [...]
>>
>> * Hardly anybody here has a project which can be built simply by
>> compiling and linking all the modules.
>
>Not everyone is working on a project where the deliverable is a
>single executable. It's much more difficult to work on a project
>where the deliverables form a set of related files that make up a
>third-party library, and target multiple platforms.
>
>> Even Tim Rentsch's simplest project has a dizzying set of special
>> requirements.
>
>This statement is a misrepresentation, and undoubtedly a deliberate
>one. Furthermore how it is expressed is petty and childish.

I have reached the point where it's not worth my time to respond
to bart, even to correct his misrepresentations of what I and
other have said.

On Mon, 5 Feb 2024 05:58:55 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:

> On 2024-02-05, bart <bc@freeuk.com> wrote:
> >
> > In no particular order.
> >
> > * Software development can ONLY be done on a Unix-related OS
> >
> > * It is impossible to develop any software, let alone C, on pure
> > Windows
>
> I've developed on DOS, Windows as well as for DSP chips and some
> microcontrollers. I find most of the crap that you say is simply
> wrong.
>
> Speaking of Windows, the CL.EXE compiler does not know where its
> include files are. You literally cannot do "cl program.c".
> You have to give it options which tell it where the SDK is installed:
> where the headers and libraries are.
>

It depends on definitions.
cl.exe called from random command prompt, either cmd.exe or powershell,
does not know.
cl.exe called from "x64 Native Tools Command Prompt for VS 2019" that I
have installed on the computer that I'm writing this message, knows
very well where they are, because when I clicked on the shortcut it was
written into environment variables, respectively named Include and Lib.
So, from this prompt I can do "cl program.c".
In practice, I d likely prefer "cl -W4 -O1 -MD program.c", but that's
because I am more than most people concerned about unimportant details.
Call it a defect of character.

> The Visual Studio project-file-driven build build system passes all
> those details to every invocation of CL.EXE. Your project file (called
> a "solution" nowadays) includes information like the path where your
> SDK is installed. In the GUI there is some panel where you specify
> it.
>
> If I'm going to be doing programming on Windows today, it's either
> going be some version of that CL.EXE compiler from Microsoft, or GCC.
>

Native C language gcc programming under MSYS2 and native C language
clang programming under MSYS2 have extremely similar look and feel. I
can't think about any technical reasons to prefer one over the other.

On Mon, 5 Feb 2024 05:58:55 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:
>
> Is it due to decades of legacy code in GCC? Clang is a newer
> implementatation, so you might think it's faster than GCC. But it
> manages only to be about the same.
>

I still believe that "decades of legacy" are the main reason.
clang *was* much faster than gcc 10-12 years ago. Since then it
accumulated a decade of legacy. And this particular decade mostly
consisted of code that was written by people that (a) less experienced
than gcc maintainers (b) care about speed of compilation even less than
gcc maintainers. Well, for the later, I don't really believe that it is
possible, but I need to bring a plausible explanation, don't I?

On Mon, 5 Feb 2024 05:58:55 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:
> > * Nearly everyone here is working on massively huge and complex
> > projects, which all take from minutes to hours for a full build.
>
> That's the landscape. Nobody is going to pay you for writing small
> utilities in C. That sort of thing all went to scripting languages.
> (It happens from time to time as a side task.)
>
> I currently work on a a firmware application that compiles to a 100
> megabyte (stripped!) executable.
>

My before last firmware project compiles from scratch in 0m1.623s
despite using bloated STmicro libraries and headers.
On Windows, with antivirus running, using 10 y.o. PC.
With brand new CPU, bare metal Linux and modern NVMe SSD it will likely
finish 3 times faster.
Windows by itself is not a measurable slowdown, but antivirus is, and
until now I didn't find a way to get antivirus-free Windows at work.

Projects that small are not typical in my embedded development
practice practice. But embedded projects that on somewhat beefier 5 y.o.
hardware compile from scratch in less than 5 sec are typical.

As to PC development, project that I am trying to fix right now uses
link-time code generation, so it takes ~8 seconds (VS 2019, msbuild,
command line tools) to rebuild when just one file changed. I accept it
because it's not my own project. If it was mine, I'd probably want to
improve it. Besides, today I grew older, less intolerable of delays
than 25-30 years ago.

On 2024-02-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> bart <bc@freeuk.com> writes:
>
>> [...]
>>
>> * Hardly anybody here has a project which can be built simply by
>> compiling and linking all the modules.
>
> Not everyone is working on a project where the deliverable is a
> single executable. It's much more difficult to work on a project
> where the deliverables form a set of related files that make up a
> third-party library, and target multiple platforms.
>
>> Even Tim Rentsch's simplest project has a dizzying set of special
>> requirements.
>
> This statement is a misrepresentation, and undoubtedly a deliberate
> one. Furthermore how it is expressed is petty and childish.

Did you expect anything else?

On 05/02/2024 17:32, Michael S wrote:
> On Mon, 5 Feb 2024 05:58:55 -0000 (UTC)
> Kaz Kylheku <433-929-6894@kylheku.com> wrote:
>>
>> Is it due to decades of legacy code in GCC? Clang is a newer
>> implementatation, so you might think it's faster than GCC. But it
>> manages only to be about the same.
>>
>
> I still believe that "decades of legacy" are the main reason.
> clang *was* much faster than gcc 10-12 years ago. Since then it
> accumulated a decade of legacy. And this particular decade mostly
> consisted of code that was written by people that (a) less experienced
> than gcc maintainers (b) care about speed of compilation even less than
> gcc maintainers. Well, for the later, I don't really believe that it is
> possible, but I need to bring a plausible explanation, don't I?
>

Early clang was faster than C at compilation and static error checking.
And it had much nicer formats and outputs for its warnings. But it
wasn't close to gcc for optimisation and generated code efficiency, and
had less powerful checking.

Over time, clang has gained a lot more optimisation and is now similar
to gcc in code generation (each is better at some things), while gcc has
sped up some aspects and greatly improved the warning formats.

clang is now a similar speed to gcc because it does a similar job. It
turns out that doing a lot of analysis and code optimisation takes effort.

On 2024-02-05, David Brown <david.brown@hesbynett.no> wrote:
> On 05/02/2024 17:32, Michael S wrote:
>> On Mon, 5 Feb 2024 05:58:55 -0000 (UTC)
>> Kaz Kylheku <433-929-6894@kylheku.com> wrote:
>>>
>>> Is it due to decades of legacy code in GCC? Clang is a newer
>>> implementatation, so you might think it's faster than GCC. But it
>>> manages only to be about the same.
>>>
>>
>> I still believe that "decades of legacy" are the main reason.
>> clang *was* much faster than gcc 10-12 years ago. Since then it
>> accumulated a decade of legacy. And this particular decade mostly
>> consisted of code that was written by people that (a) less experienced
>> than gcc maintainers (b) care about speed of compilation even less than
>> gcc maintainers. Well, for the later, I don't really believe that it is
>> possible, but I need to bring a plausible explanation, don't I?
>>
>
> Early clang was faster than C at compilation and static error checking.
> And it had much nicer formats and outputs for its warnings. But it
> wasn't close to gcc for optimisation and generated code efficiency, and
> had less powerful checking.
>
> Over time, clang has gained a lot more optimisation and is now similar
> to gcc in code generation (each is better at some things), while gcc has
> sped up some aspects and greatly improved the warning formats.
>
> clang is now a similar speed to gcc because it does a similar job. It
> turns out that doing a lot of analysis and code optimisation takes effort.

It takes more and more effort for diminishing results.

A compiler can spend a lot of time just searching for the conditions
that allow a certain optimization, where those conditions turn out to be
false most of the time. So that in a large code base, there will be just
a couple of "hits" (the conditions are met, and the optimization can
take place). Yet all the instruction sequences in every basic block in
every file had to be looked at to determine that.

Mnay of these conditions are specific to the optimization. Another
kind of optimization has its own conditions that don't reuse anything
from that one. So the more optimizations you add, the more work it takes
just to determine applicability.

The optimizer may have to iterate on the program graph. After certain
optimizations are applied, the program graph changes. And that may
"unlock" more opportunities to do optimizations that were not possible
before. But because the program graph changed, its properties have to be
recalculated, like liveness of variables/temporaries and whatnot.
More time.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

In article <XC6wN.397626$p%Mb.396054@fx15.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
....
>I have reached the point where it's not worth my time to respond
>to bart, even to correct his misrepresentations of what I and
>other have said.

Being killfiled by Scotty is almost as good a thing as being kf'd by
Keith. Keep it up!

--
Life's big questions are big in the sense that they are momentous. However, contrary to
appearances, they are not big in the sense of being unanswerable. It is only that the answers
are generally unpalatable. There is no great mystery, but there is plenty of horror.
(https://en.wikiquote.org/wiki/David_Benatar)

On Mon, 5 Feb 2024 19:02:09 +0200, Michael S wrote:

> Windows by itself is not a measurable slowdown, but antivirus is, and
> until now I didn't find a way to get antivirus-free Windows at work.

But if you don’t have antivirus on your build machine, the sad fact of
development on Windows is that there are viruses that will insinuate
themselves into the build products.

On Mon, 5 Feb 2024 01:09:10 +0000, bart wrote:

> * Software development can ONLY be done on a Unix-related OS

Does the term “butthurt” mean anything to you?

On 05/02/2024 23:28, Lawrence D'Oliveiro wrote:
> On Mon, 5 Feb 2024 19:02:09 +0200, Michael S wrote:
>
>> Windows by itself is not a measurable slowdown, but antivirus is, and
>> until now I didn't find a way to get antivirus-free Windows at work.
>
> But if you don’t have antivirus on your build machine, the sad fact of
> development on Windows is that there are viruses that will insinuate
> themselves into the build products.

Reflections on Trusting Trust?

On Mon, 5 Feb 2024 23:28:04 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Mon, 5 Feb 2024 19:02:09 +0200, Michael S wrote:
>
> > Windows by itself is not a measurable slowdown, but antivirus is,
> > and until now I didn't find a way to get antivirus-free Windows at
> > work.
>
> But if you don’t have antivirus on your build machine, the sad fact
> of development on Windows is that there are viruses that will
> insinuate themselves into the build products.

No, if I use Windpws there are no danger of viruses like these.
Besides, it's not like antivirus could have helped against viruses if
I was stupid enough to catch them. To the opposite, I suspect that
presence of antivirus increases attak surface.

On 2/5/2024 3:28 PM, Lawrence D'Oliveiro wrote:
> On Mon, 5 Feb 2024 19:02:09 +0200, Michael S wrote:
>
>> Windows by itself is not a measurable slowdown, but antivirus is, and
>> until now I didn't find a way to get antivirus-free Windows at work.
>
> But if you don’t have antivirus on your build machine, the sad fact of
> development on Windows is that there are viruses that will insinuate
> themselves into the build products.

There can be viruses hidden in source code for public domain code...
Build it and they will come! ;^o