On 2024-02-05, bart <
b...@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: @
Kazi...@mstdn.ca