On 02/02/2024 09:47, David Brown wrote:
> On 01/02/2024 23:29, bart wrote:

>> As I said, C's uses of .h and .c files are chaotic.
>
> My uses of .h and .c files are not chaotic.

We can't write tools that only work for careful users. Any open-source
project I want to build WILL be chaotic.

We can however write languages where you are forced to be more
disciplined. Mine doesn't have the equivalent of .h files for example.

However this is about C.

>> I first got rid of a formal 'linker' about 40 years ago. I got rid of
>> the notion of combining independently compiled modules into an
>> executable a decade ago.
>
> No, you built a monolithic tool that /included/ the linker.

No, I ELIMINATED the linker.

And in the past, I wrote a program called a Loader, much simpler than a
linker, and very fast (it had to be as I worked with floppies).

>  That's fine
> for niche tools that are not intended to work with anything else.  Most
> people work with many tools - that's why we have standards, defined file
> formats, and flexible tools with wide support.
>
> Other people got rid of monolithic tools forty years ago when they
> realised it was a terrible way to organise things.

>
>>
>> But I suspect you don't understand what a 'whole-program compiler' does:
>>
>
> I know exactly what it does.  I am entirely without doubt that I know
> the point and advantages of them better than you do

You can't create a language devised for whole-program compilation, and
implement a full-stack compiler for it, without learning a lot about the
ins and outs.

So I suspect I know a bit more about it than you do.

Probably you're mixing this up with whole-program optimisation.

- the /real/ points
> and advantages, not some pathetic "it means I don't have to use that
> horrible nasty make program" reason.
>
>> * It means that for each binary, all sources are recompiled at the same
>>    time to create it
>
> No, it does not.

That's not a whole-program compiler then. Not if half the modules were
compiled last week!

>>
>> * It doesn't mean that an application can only comprise one binary
>
> Correct.
>
>>
>> * It moves the compilation unit granularity from a module to a single
>>    EXE or DLL file
>
> No, it does not.

Again, it can't be a whole-program compiler if it can compile modules
independently.

> In real-world whole program compilation systems, the focus is on
> inter-module optimisations.  Total build times are expected to go /up/.
> Build complexity can be much higher, especially for large programs.  It
> is more often used for C++ than C.
>
> The main point of a lot of whole-program compilation is to allow
> cross-module optimisation.  It means you can have "access" functions
> hidden away in implementation files so that you avoid global variables
> or inter-dependencies between modules, but now they can be inline across
> modules so that you have no overhead or costs for this.  It means you
> can write code that is more structured and modular, with different teams
> handling different parts, and with layers of abstractions, but when you
> pull it all together into one whole-program build, the run-time costs
> and overhead for this all disappear.  And it means lots of checks and
> static analysis can be done across the whole program.
>
>
> For such programs, each translation unit is still compiled separately,
> but the "object" files contain internal data structures and analysis
> information, rather than generated code.  Lots of the work is done by
> this point, with inter-procedural optimisations done within the unit.
> These compilations will be done as needed, in parallel, under the
> control of a build system.  Then they are combined for the linking and
> link-time optimisation which fits the parts together.  Doing this in a
> scalable way is hard, and the subject of a lot of research, as you need
> to partition it into chunks that can be handled in parallel on multiple
> cpu cores (or even distributed amongst servers).  Once you have parts of
> code that are ready, they are handed on to backend compilers that do
> more optimisation and generate the object code, and this in turn is
> linked (sometimes incrementally in parts, again aiming at improving
> parallel building and scalability.

You've just described a tremendously complex way to do whole-program
analysis.

There are easier ways. The C transpiler I use takes a project of dozens
of modules in my language, and produces a single C source file which
will form one EXE or one DLL file.

Now any ordinary optimising C compiler has a view of the entire program
and can do wider optimisations (but that view does not span multiple
EXE/DLL files.)

> /You/ can't work it, but you excel at failing to get things working. You
> have a special gift - you just have to look at a computer with tools
> that you didn't write yourself, and it collapses.

Yes, I do. I'm like that kid poking fun at the emperor's new clothes;
I'm just stating what I see. But in one way it is hilarious seeing you
lot defend programs like 'as' to the death.

Why not just admit that it is a POS that you've had to learn to live
with, instead of trying to make out it is somehow superior?

On 02/02/2024 10:13, David Brown wrote:
> On 02/02/2024 01:26, Malcolm McLean wrote:
>> On 01/02/2024 21:34, David Brown wrote:
>>>
>>>> It works for me, and I'm sure could work for others if they didn't
>>>> have makefiles forced down their throats and hardwired into their
>>>> brains.
>>>
>>> /Nobody/ has makefiles forced on them.  People use "make" because it
>>> is convenient, and it works.  If something better comes along, and it
>>> is better enough to overcome the familiarity momentum, people will
>>> use that.
>>>
>> What?
>> You have total control of your programming environment and never have
>> to consider anybody else? For hobby programming you do in a way. Not
>> if you want other people to use your stuff. But can always say that
>> fun of doing things exactly your way outweighs the fun of getting
>> downloads.
>>
>
> Okay, none of the people talking about "make" /here/ had it forced on
> them for the uses they are talking about /here/.
>
> Yes, I have a very large degree of control over my programming
> environment - because I work in a company where employees get to make
> the decisions that they are best qualified to make, and management's job
> is to support them.  One of the important factors I consider is
> interaction with colleagues and customers, for which "make" works well.
>
> And while people may be required to use make, or particular compilers,
> or OS's, no one is forced to /like/ a tool or find it useful.  I believe
> that when people here say they like make, or find it works well for
> them, or that it can handle lots of different needs, or that they know
> of nothing better for their requirements, they are being honest about
> that.  If they didn't like it, they would say.
>
> The only person here whom we can be absolutely sure does /not/ have
> "make" forced upon them for their development, is Bart.  And he is the
> one who complains about it.
> My job is to write the algorithms. Not to set uo the build system.
Someone else was given that job and set up the system I described
recently, with git and conan and Azure. He didn't do a bad job at all
and we can get a bug fix out to customers within hours on request. My
input is just to moan when occasionally things go wrong. Had I done it
I'm sure it would have been a lot worse, because basically my skills are
in algorithm development, not setting things up like that.

It's makefile free, thank goodness. My main peeve is boost. When things
go wrong, it always seems to be the boost. I've refused to include it in
my library, despite requests. Whilst it would be nice to have the
threads, I just think it would be a perpetual source of build failures
and grief. That's from experience of boost in other projects. I might
ultimately have to give in. I don't have total control, at the end of
the day, it's not my personal code, it's company code.

Because I'm constantly shifting between platforms, make isn't veey
useful to me. And because mainly I do algorithms, the guts of it are
simple source files with no dependencies other than the standard
libraries. So you don't need elaborates systems for pulling things in.
It's just submit a list of sources to the compiler. And you don't need
make to do that. So I don't use make much, for reasons other than that I
don't particularly like it. CMake is a sort of front end to make, which
says it all really. But CMake can also spin uo an IDE project file. And
if you are developing rather than just building, that's far more
convenient. So I distribute using CMake in preference to make. But if
someone won't accept CMake, then I'd have no hesitation, and drop down
to make.

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

On Fri, 2 Feb 2024 14:14:31 +0000
bart <bc@freeuk.com> wrote:

> On 02/02/2024 09:47, David Brown wrote:
> > On 01/02/2024 23:29, bart wrote:
>
> >> As I said, C's uses of .h and .c files are chaotic.
> >
> > My uses of .h and .c files are not chaotic.
>
> We can't write tools that only work for careful users. Any
> open-source project I want to build WILL be chaotic.
>
> We can however write languages where you are forced to be more
> disciplined. Mine doesn't have the equivalent of .h files for example.
>
> However this is about C.
>
>
> >> I first got rid of a formal 'linker' about 40 years ago. I got rid
> >> of the notion of combining independently compiled modules into an
> >> executable a decade ago.
> >
> > No, you built a monolithic tool that /included/ the linker.
>
> No, I ELIMINATED the linker.
>
> And in the past, I wrote a program called a Loader, much simpler than
> a linker, and very fast (it had to be as I worked with floppies).
>
> >  That's fine
> > for niche tools that are not intended to work with anything else.
> > Most people work with many tools - that's why we have standards,
> > defined file formats, and flexible tools with wide support.
> >
> > Other people got rid of monolithic tools forty years ago when they
> > realised it was a terrible way to organise things.
>
>
>
> >
> >>
> >> But I suspect you don't understand what a 'whole-program compiler'
> >> does:
> >
> > I know exactly what it does.  I am entirely without doubt that I
> > know the point and advantages of them better than you do
>
> You can't create a language devised for whole-program compilation,
> and implement a full-stack compiler for it, without learning a lot
> about the ins and outs.
>
> So I suspect I know a bit more about it than you do.
>
> Probably you're mixing this up with whole-program optimisation.
>
> - the /real/ points
> > and advantages, not some pathetic "it means I don't have to use
> > that horrible nasty make program" reason.
> >
> >> * It means that for each binary, all sources are recompiled at the
> >> same time to create it
> >
> > No, it does not.
>
> That's not a whole-program compiler then. Not if half the modules
> were compiled last week!
>
> >>
> >> * It doesn't mean that an application can only comprise one binary
> >>
> >
> > Correct.
> >
> >>
> >> * It moves the compilation unit granularity from a module to a
> >> single EXE or DLL file
> >
> > No, it does not.
>
> Again, it can't be a whole-program compiler if it can compile modules
> independently.
>
> > In real-world whole program compilation systems, the focus is on
> > inter-module optimisations.  Total build times are expected to go
> > /up/. Build complexity can be much higher, especially for large
> > programs.  It is more often used for C++ than C.
> >
> > The main point of a lot of whole-program compilation is to allow
> > cross-module optimisation.  It means you can have "access"
> > functions hidden away in implementation files so that you avoid
> > global variables or inter-dependencies between modules, but now
> > they can be inline across modules so that you have no overhead or
> > costs for this.  It means you can write code that is more
> > structured and modular, with different teams handling different
> > parts, and with layers of abstractions, but when you pull it all
> > together into one whole-program build, the run-time costs and
> > overhead for this all disappear.  And it means lots of checks and
> > static analysis can be done across the whole program.
> >
> >
> > For such programs, each translation unit is still compiled
> > separately, but the "object" files contain internal data structures
> > and analysis information, rather than generated code.  Lots of the
> > work is done by this point, with inter-procedural optimisations
> > done within the unit. These compilations will be done as needed, in
> > parallel, under the control of a build system.  Then they are
> > combined for the linking and link-time optimisation which fits the
> > parts together.  Doing this in a scalable way is hard, and the
> > subject of a lot of research, as you need to partition it into
> > chunks that can be handled in parallel on multiple cpu cores (or
> > even distributed amongst servers).  Once you have parts of code
> > that are ready, they are handed on to backend compilers that do
> > more optimisation and generate the object code, and this in turn is
> > linked (sometimes incrementally in parts, again aiming at improving
> > parallel building and scalability.
>
> You've just described a tremendously complex way to do whole-program
> analysis.
>

But it proves that your statement above (it can't be a whole-program
compiler if it can compile modules independently) is false.

> There are easier ways. The C transpiler I use takes a project of
> dozens of modules in my language, and produces a single C source file
> which will form one EXE or one DLL file.
>
> Now any ordinary optimising C compiler has a view of the entire
> program and can do wider optimisations (but that view does not span
> multiple EXE/DLL files.)
>

If the program in question is really big then there is a good chance
that your method will expose internal limits of the back-end compiler.
I think, that's one of the reason (not the only one) why Mozilla didn't
re-write the whole Firefox in Rust. According to my understanding, Rust
does something similar to your approach, except that it outputs LLVM IR
instead of C and there are real concern that LLVM back end would have
troubles with input as big as the whole FF.

> > /You/ can't work it, but you excel at failing to get things
> > working. You have a special gift - you just have to look at a
> > computer with tools that you didn't write yourself, and it
> > collapses.
>
> Yes, I do. I'm like that kid poking fun at the emperor's new clothes;
> I'm just stating what I see. But in one way it is hilarious seeing
> you lot defend programs like 'as' to the death.
>
> Why not just admit that it is a POS that you've had to learn to live
> with, instead of trying to make out it is somehow superior?
>
>

I never run gnu as directly. Running it by means of driver program
(personally I prefer clang for that task, but gcc will do the job as
well) isolates me from all peculiarities.

On 02/02/2024 14:28, Michael S wrote:
> On Fri, 2 Feb 2024 09:02:15 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>>
>> But don't hold your breath waiting for something that will replace
>> make, or attract users of any other build system.
>>
>>
>
> It seems, you already forgot the context of my post that started this
> short sub-thread.
>

That is absolutely possible. It was not intentional, but the number of
posts in recent times has been overwhelming. I apologise if I have
misinterpreted what you wrote.

> BTW, I would imagine that Stu Feldman, if he is still in good health,
> would fine talking with Bart more entertaining that talking with you.

I have no idea who that is, so I'll take your word for it.

> I think, you, English speakers, call it birds of feather.
>

On Fri, 2 Feb 2024 15:49:20 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 02/02/2024 14:28, Michael S wrote:
> > On Fri, 2 Feb 2024 09:02:15 +0100
> > David Brown <david.brown@hesbynett.no> wrote:
> >>
> >> But don't hold your breath waiting for something that will replace
> >> make, or attract users of any other build system.
> >>
> >>
> >
> > It seems, you already forgot the context of my post that started
> > this short sub-thread.
> >
>
> That is absolutely possible. It was not intentional, but the number
> of posts in recent times has been overwhelming. I apologise if I
> have misinterpreted what you wrote.
>
> > BTW, I would imagine that Stu Feldman, if he is still in good
> > health, would fine talking with Bart more entertaining that talking
> > with you.
>
> I have no idea who that is, so I'll take your word for it.
>

Inventor of make

> > I think, you, English speakers, call it birds of feather.
> >
>

On 02/02/2024 14:47, bart wrote:
> On 02/02/2024 08:02, David Brown wrote:
>> On 01/02/2024 23:55, Michael S wrote:
>>> On Thu, 1 Feb 2024 22:38:13 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>
>>>> On 01/02/2024 21:23, Michael S wrote:
>>>>> On Thu, 1 Feb 2024 18:34:08 +0000
>>>>
>>
>>>>>
>>>>> You proposal and needs of David Brown are not necessarily
>>>>> contradictory.
>>>>> All you need to do to satisfy him is to add to your compiler an
>>>>> option for export of dependencies in make-compatible format, i.e.
>>>>> something very similar to -MD option of gcc.
>>>>>
>>>>> Then David could write in his makefile:
>>>>>
>>>>> out/foo.elf : main_foo.c
>>>>>     mcc -MD $< -o $@
>>>>>
>>>>> -include out/foo.d
>>>>>
>>>>> And then to proceed with automatiion of his pre and post-processing
>>>>> needs.
>>>>
>>>> But then I'd still be using "make", and Bart would not be happy.
>>>>
>>>> And "gcc -MD" does not need any extra #pragmas, so presumably neither
>>>> would an implementation of that feature in bcc (or mcc or whatever).
>>>> So Bart's new system would disappear entirely.
>>>>
>>>>
>>>>
>>>
>>> Bart spares you from managing list(s) of objects in your makefile and
>>> from writing arcan helper macros.
>>> Yes, I know, you copy&past arcan macros from project to project, but
>>> you had to write them n years ago and that surely was not easy.
>>>
>>
>> Google "makefile automatic dependencies", then adapt to suit your own
>> needs.  Re-use the same makefile time and again.
>>
>> Yes, some of the functions I have in my makefiles are a bit hairy, and
>> some of the command line options for gcc are a bit complicated.  They
>> are done now.
>>
>> If there had been an easier way than this, which still let me do what
>> I need (Bart's system does not), which is popular enough that you can
>> easily google for examples, blogs, and tutorials, then I'd have been
>> happy to use that at the time.  I won't change to something else
>> unless it gives me significant additional benefits.
>>
>> People smarter and more experienced than Bart have been trying to
>> invent better replacements for "make" for many decades.  None have
>> succeeded. Some build systems are better in some ways, but nothing has
>> come close to covering the wide range of features and uses of make, or
>> gaining hold outside a particular niche.  Everyone who has ever made
>> serious use of "make" knows it has many flaws, unnecessarily
>> complications, limitations and inefficiencies.  Despite that, it is
>> the best we have.
>>
>> With Bart's limited knowledge and experience,
>
> That's true: only 47 years in computing, and 42 years of evolving,
> implementing and running my systems language.

Yes. Most of it using your languages, your tools, your programs, and
determinedly refusing to learn or use anything else more than the barest
minimum, and so completely convinced of your own superiority and the
failings of everyone else and all other languages and software that you
are unable to learn things properly or consider anything from a
viewpoint other than your own.

You have experience - but it is limited by the walls you put up around
yourself.

>
> What can I possibly know about compiling sources files of a lower-level
> language into binaries?

You know how /you/ do it, and how /you/ want to do it. You know sod all
about anyone else.

>
> That is another aspect you might do well to learn how to do: KISS. (Yes
> I can be a patronising fuck too.)
>

KISS is great. It's what encourages people to use existing standard
tools like "make" and "C", instead of trying to re-invent their own
personal wheels all the time. /Sometimes/ it is useful to re-invent
something from scratch. Most of the time, it is not.

>
>> And that, of course, is absolutely fine.  No one is paying Bart to
>> write a generic build system, or something of use to anyone else.  He
>> is free to write exactly what he wants, in the way he wants, and if
>> ends up with a tool that he finds useful himself, that is great.  If
>> he ends up with something that at least some other people find useful,
>> that is even better, and I wish him luck with his work.
>>
>> But don't hold your breath waiting for something that will replace
>> make, or attract users of any other build system.
>
> Jesus. And you seem to determined to ignore everything I write, or have
> a short memory.
>
> I'm not suggesting replacing make, only to reduce its involvement.

I didn't say you were trying to replace make, or even thought you were.
I said you were not replacing make. There's a difference.

>
> Twice I posted a list of 3 things that make takes care of; I'm looking
> at replacing just 1 of those things, the I which for me is more critical.
>

And I have repeatedly said that if you are making a tool that is useful
for you, then great - make your tool and use it.

bart <bc@freeuk.com> writes:
>On 02/02/2024 08:02, David Brown wrote:

>> With Bart's limited knowledge and experience,
>
>That's true: only 47 years in computing, and 42 years of evolving,
>implementing and running my systems language.

It's pretty clear that you have very limited knowledge
and experience with unix, make and and pretty much
anything that isn't your soi disant compiler.

>
>What can I possibly know about compiling sources files of a lower-level
>language into binaries?

Very little, it appears, outside of your toy projects.

>
>How many assemblers, compilers, linkers, and interpreters have /you/
>written?

Can't speak for David, but in my case, at least one of each, and
you can add operating systems and hypervisors to that list.

>It certainly won't for your stuff, or SL's, or JP's, or TR's, as you
>all seem to delight in wheeling out the most complex scenarios you can find.

The "stuff" I write is for customers. Any so-called-bart-complexity is based on
customer requirements. The customers are quite happy with the solutions
they get.

>
>That is another aspect you might do well to learn how to do: KISS. (Yes
>I can be a patronising fuck too.)

KISS is a good principle to follow, and while I cannot again speak
for David, it's a principle followed by most programmers I've worked
with. That doesn't mean throwing away perfectly usable tools
(one can easily make KISS-compliant makefiles, for example).

>I'm not suggesting replacing make, only to reduce its involvement.

And to reduce it's involvement, something must replace make. ipso facto.

On 02/02/2024 14:43, Michael S wrote:
> On Fri, 2 Feb 2024 14:14:31 +0000
> bart <bc@freeuk.com> wrote:

>> You've just described a tremendously complex way to do whole-program
>> analysis.
>>
>
> But it proves that your statement above (it can't be a whole-program
> compiler if it can compile modules independently) is false.

Then /every/ compiler can be regarded as a whole-program one, since the
end result, even if the modules were randomly compiled over the last
month, will always be a whole program.

So it comes down to what is meant by a whole-program compiler.

My definition is where you build one program (eg. one EXE or DLL file on
Windows) with ONE invocaton of the compiler, which processes ALL source
and support files from scratch.

The output (from my compiler) is a single file, usually an EXE or DLL,
that may use external shared libraries. Or, rarely, it may generate a
single OBJ file for more exotic requirements, but it will need external
tools. Then it may end up as a component of a larger program.

Or sometimes the output is fixed up in memory and run immediately.

That describes the compiler I use for my systems language.

My C compiler is not a whole-program one. Although you can submit all
modules and it can produce one EXE/DLL file, so that the behaviour can
appear similar, internally they are compiled independently.

I have thought about using real whole-program techniques (so that all
modules share a global symbol table for example, and common headers are
processed only once), but I don't use C enough to make that interesting
to attempt.

>> There are easier ways. The C transpiler I use takes a project of
>> dozens of modules in my language, and produces a single C source file
>> which will form one EXE or one DLL file.
>>
>> Now any ordinary optimising C compiler has a view of the entire
>> program and can do wider optimisations (but that view does not span
>> multiple EXE/DLL files.)
>>
>
> If the program in question is really big then there is a good chance
> that your method will expose internal limits of the back-end compiler.

My personal whole-program projects impose some limitations.

One is the scale of the application being compiled. However they are
designed for use with a fast compiler. That puts an upper limit of about
0.5M lines per project, if you want to keep build time below, say, 1 second.

(Figures pertain to my slowish PC, running an unoptimised compiler, so
are conservative. An optimised compiler might be 40% faster.)

0.5M lines of code means about a 5MB executable, which is a pretty hefty
project. The vast majority of executables and libraries on my PC are
smaller than that.

Another is that whole-program compilation is harder to parallelise (the
above figures are for a single core). But you can of course compile
multiple programs at the same time.

The killer is that most professional compilers are hugely complex: they
are big, and they take considerable machine resources. These are ones
like gcc or any using LLVM.

So to get around that in order to do whole-program stuff, things get
very, very complicated.

I can't help that.

But I can't remember how we got here. The thread subject is the
far-simpler-to-realise topic of discovering the modules for a
non-whole-program C compiler, which seems to give the big boys a lot
more trouble!

On 02/02/2024 14:45, Michael S wrote:
>
> Actually, nowadays monolithic tools are solid majority in programming.
> I mean, programming in general, not C/C++/Fortran programming which by
> itself is a [sizable] minority.
> Even in C++, a majority uses non-monolithic tools well-hidden behind
> front end (IDE) that makes them indistinguishable from monolithic.
>

It can often be helpful to have a single point of interaction - a
front-end that combines tools. But usually these are made of parts.

For many of the microcontrollers I work with, the manufacturer's
standard development toolset is based around Eclipse and gcc. From the
user point of view, it looks a lot like one monolithic IDE that lets you
write your code, compile and link it, and download and debug it on the
microcontroller. Under the hood, it is far from a monolithic
application. Different bits come from many different places. This
means the microcontroller manufacturer is only making the bits that are
specific to /their/ needs - such as special views while debugging, or
"wizards" for configuring chip pins. The Eclipse folk are experts at
making an editor and IDE, the gcc folks are experts at the compiler, the
openocd folks know about jtag debugging, and so on. And to a fair
extent, advanced users can use the bits they want and leave out other
bits. I sometimes use other editors, but might still use the toolchain
provided with the manufacturer's tools. I might swap out the debugger
connection. I might use the IDE for something completely different. I
might install additional features in the IDE. I might use different
toolchains. Manufacturers, when putting things together, might change
where they get their toolchains, or what debugging connectors they use.
It's even been known for them to swap out the base IDE while keeping
most of the rest the same (VS Code has become a popular choice now, and
a few use NetBeans rather than Eclipse).

(Oh, and for those that don't believe "make" and "gcc" work on Windows,
these development tools invariably have "make" and almost invariably use
gcc as their toolchain, all working in almost exactly the same way on
Linux and Windows. The only difference is builds are faster on Linux.)

This is getting the best (or at least, trying to) from all worlds. It
gives people the ease-of-use advantages of monolithic tools without the
key disadvantages of real monolithic tools - half-arse editors,
half-arsed project managers, half-arsed compilers, and poor
extensibility because the suppliers are trying to do far too much
themselves.

I don't think it is common now to have /real/ monolithic development
tools. But it is common to have front-ends aimed at making the
underlying tools easier and more efficient to use, and to provide
all-in-one base packages.

On 02/02/2024 15:14, bart wrote:

> Yes, I do. I'm like that kid poking fun at the emperor's new clothes;
> I'm just stating what I see. But in one way it is hilarious seeing you
> lot defend programs like 'as' to the death.
>

No, /you/ are the emperor in this analogy. Well, you are actually the
kid - except you are the kid with no clothes who /thinks/ he's an emperor.

> Why not just admit that it is a POS that you've had to learn to live
> with, instead of trying to make out it is somehow superior?
>

The whole world is out of step, except Bart.

Has it never occurred to you that when you are in disagreement with
everyone, /you/ might be the one that is wrong? I think you suffer from
the "misunderstood genius" myth. It's surprisingly common amongst
people who have invested heavily in going their own way, against common
knowledge or common practice. It's a sort of psychological defence
mechanism against realising you've been wrong all this time.

On 2024-02-02, bart <bc@freeuk.com> wrote:
> disciplined. Mine doesn't have the equivalent of .h files for example.

My musical instrument has frets for easy intonation, you silly violin
people, in your silly violin newsgroup.

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

In article <20240202165335.0000384a@yahoo.com>,
Michael S <already5chosen@yahoo.com> wrote:
....
>> I have no idea who that is, so I'll take your word for it.
>>
>
>Inventor of make

At Bell Labs, in 1976.

Currently, like quite a few ex-Bell Labs people, a big wheel at Google.

--
Marshall: 10/22/51
Jessica: 4/4/79

On 02/02/2024 15:31, David Brown wrote:
> On 02/02/2024 15:14, bart wrote:
>
>> Yes, I do. I'm like that kid poking fun at the emperor's new clothes;
>> I'm just stating what I see. But in one way it is hilarious seeing you
>> lot defend programs like 'as' to the death.
>>
>
> No, /you/ are the emperor in this analogy.  Well, you are actually the
> kid - except you are the kid with no clothes who /thinks/ he's an emperor.
>
>> Why not just admit that it is a POS that you've had to learn to live
>> with, instead of trying to make out it is somehow superior?
>>
>
> The whole world is out of step, except Bart.

Has it ever occurred to YOU that the world is more than Unix and make
and massive compilers like gcc and clang?

> Has it never occurred to you that when you are in disagreement with
> everyone, /you/ might be the one that is wrong?  I think you suffer from
> the "misunderstood genius" myth.  It's surprisingly common amongst
> people who have invested heavily in going their own way, against common
> knowledge or common practice.  It's a sort of psychological defence
> mechanism against realising you've been wrong all this time.

This is a newsgroup about C. That is a language that can be fairly
adequately implemented with a 180KB program, the size of Tiny C. Tiny C
itself can turn C source into binary at about 10MB per second.

So, a toy language, really, and a toy implementation that nevertheless
does the job: in most cases, a user of the resulting program will not be
able to tell how it was compiled.

And yet there is this massive collection of of huge, complex tools built
around a toy language, dwarfing it by 1000:1, that you insist is what
it's really all about, and you want to put down anyone who disagrees.

It's like saying that the only businesses worth having are huge
corporations, or the only form of transport must be a jetliner.

The way 'as' works IS rubbish. It is fascinating how you keep trying to
turn it round and make it about me. There can't possibly be anything
wrong with it, whoever says so must be deluded!

On 2024-02-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <20240202165335.0000384a@yahoo.com>,
> Michael S <already5chosen@yahoo.com> wrote:
> ...
>>> I have no idea who that is, so I'll take your word for it.
>>>
>>
>>Inventor of make
>
> At Bell Labs, in 1976.
>
> Currently, like quite a few ex-Bell Labs people, a big wheel at Google.

It's like a cargo cult. If we hire old Unix geezers and prop them up in
chairs, be they dead or alive, magic will happen.

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

On 2024-02-02, bart <bc@freeuk.com> wrote:
> Has it ever occurred to YOU that the world is more than Unix and make
> and massive compilers like gcc and clang?

There is more, but from your perspective, it's just more stuff to
shake your fist at and avoid learning about.

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

On 02/02/2024 15:18, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 02/02/2024 08:02, David Brown wrote:
>
>>> With Bart's limited knowledge and experience,
>>
>> That's true: only 47 years in computing, and 42 years of evolving,
>> implementing and running my systems language.
>
> It's pretty clear that you have very limited knowledge
> and experience with unix, make and and pretty much
> anything that isn't your soi disant compiler.

Yes. And?

>
>>
>> What can I possibly know about compiling sources files of a lower-level
>> language into binaries?
>
> Very little, it appears, outside of your toy projects.

That's right, I only have experience of the stuff I've done. And?

Most stuff I want to build is on a similar scale, so you'd probably
consider all that as toys too.

You're saying that anyone not using Unix, not building 10Mloc projects,
and not a fan of make, should FOAD?

>
>>
>> How many assemblers, compilers, linkers, and interpreters have /you/
>> written?

OK. How do I know these aren't just toys, or is it only you who is
allowed to judge?

BTW what exactly is a toy project?

> Can't speak for David, but in my case, at least one of each, and
> you can add operating systems and hypervisors to that list.

I don't do OSes. If I did, you probably have a good idea of what mine
would look like!

>> It certainly won't for your stuff, or SL's, or JP's, or TR's, as you
>> all seem to delight in wheeling out the most complex scenarios you can find.
>
> The "stuff" I write is for customers. Any so-called-bart-complexity is based on
> customer requirements. The customers are quite happy with the solutions
> they get.
>
>>
>> That is another aspect you might do well to learn how to do: KISS. (Yes
>> I can be a patronising fuck too.)
>
> KISS is a good principle to follow, and while I cannot again speak
> for David, it's a principle followed by most programmers I've worked
> with. That doesn't mean throwing away perfectly usable tools
> (one can easily make KISS-compliant makefiles, for example).
>
>
>> I'm not suggesting replacing make, only to reduce its involvement.
>
> And to reduce it's involvement, something must replace make. ipso facto.

No. I'm saying make should be less involved in specifying which files to
be submitted to a compiler-toolchain.

Especially for a makefile specifying a production or distribution build,
such as one done at a remote site by someone is not the developer, but
just wants a working binary.

bart <bc@freeuk.com> writes:
>On 02/02/2024 15:18, Scott Lurndal wrote:

>
>You're saying that anyone not using Unix, not building 10Mloc projects,
>and not a fan of make, should FOAD?

No. I'm saying that your dislike of make is personal. If you
don't like it, don't use it. Make your own, nobody is stopping
you. Just don't brag about how "small", "easy" or "nice" it is
until it can handle the same job as make.

bart <bc@freeuk.com> writes:
[...]
> The way 'as' works IS rubbish. It is fascinating how you keep trying
> to turn it round and make it about me. There can't possibly be
> anything wrong with it, whoever says so must be deluded!

"as" works. It's not perfect, but it's good enough. Its job is to
translate assembly code to object code. It does that. There's is
nothing you could do with your preferred user interface (whatever that
might be) that can't be done with the existing one. "as" is rarely
invoked directly, so any slight clumsiness in its well defined user
interface hardly matters. Any changes to its interface could break
existing scripts.

Nobody is claiming that "there can't possibly be anything wrong with
it". You made that up.

Why does the way "as" works offend you?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-02-02, bart <bc@freeuk.com> wrote:
> The way 'as' works IS rubbish.

Pretend a developer of "as" (say, the GNU one) is reading this thread.

What is it that is broken?

Do you have a minimal repro test case of your issue?

What is the proposed fix?

> turn it round and make it about me. There can't possibly be anything
> wrong with it, whoever says so must be deluded!

A vast amount of code is being compiled daily, passing through as,
without anyone noticing.

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

On 2/2/24 16:18, bart wrote:
>
> My definition is where you build one program (eg. one EXE or DLL file on
> Windows) with ONE invocaton of the compiler, which processes ALL source
> and support files from scratch.
>
And can you disclose the magic trick who let your magic
compiler know exactly the list of "ALL source and support
files" needed for a scratchy build ?

--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+

On 02/02/2024 18:36, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> The way 'as' works IS rubbish. It is fascinating how you keep trying
>> to turn it round and make it about me. There can't possibly be
>> anything wrong with it, whoever says so must be deluded!
>
> "as" works. It's not perfect, but it's good enough. Its job is to
> translate assembly code to object code. It does that. There's is
> nothing you could do with your preferred user interface (whatever that
> might be) that can't be done with the existing one. "as" is rarely
> invoked directly, so any slight clumsiness in its well defined user
> interface hardly matters. Any changes to its interface could break
> existing scripts.

That always seems to be the excuse. Some half-finished test version is
produced, with no proper file interface, and an output that temporarily
gets sent to a.out until it can be sorted out properly.

But it never is finished, and the same raw half-finished product works
the same way decades later, surprising every new generation who have to
relearn its quirks.

I saw an example today in tutorial:

as -o filename.o filename.as

having to type the name twice again.

> Nobody is claiming that "there can't possibly be anything wrong with
> it". You made that up.
>
> Why does the way "as" works offend you?

It just does. I've used a few assemblers, this one is downright weird:

* The output is odd: it ALWAYS goes to a.out. Hmm, that's the executable
file produced by gcc, so is it performing linking? No, this a.out
is an object file; gcc's a.out is an executable! (And if you and link
a.out with gcc, it will go wrong unless you use -o)

* You have to specify the output file name and extension, so writing
the input file twice

* If you start it with no params, instead of a usage message, it sits
silently waiting for you to type assembly code live at the terminal

* It accepts multiple input files. OK, presumably it will write each to
a corresponding .o file? No it writes all the code to one output.

* So, it is combining multiple, distinct assembler files to one single
object? That's actually quite neat. Except no, the input files are
effectively just concatenated into one big ASM file. Any symbol L3
in one, will clash with an L3 in another.

* All these behaviours are quite different to that of gcc. Pass
a.s, a.s, a.s to gcc, and will produce a.o, b.o, c.o. 'as' will
concatenate and produce one object file called a.out.

This is apparently the flagship assembler provided with Unix systems.

On 02/02/2024 19:43, tTh wrote:
> On 2/2/24 16:18, bart wrote:
>>
>> My definition is where you build one program (eg. one EXE or DLL file
>> on Windows) with ONE invocaton of the compiler, which processes ALL
>> source and support files from scratch.
>>
>    And can you disclose the magic trick who let your magic
>    compiler know exactly the list of "ALL source and support
>    files" needed for a scratchy build ?

If talking about the language used by my whole-program compiler, the
info comes from the module scheme. And /that/ involves simply listing
the modules the project comprises, in one place.

Other languages with module schemes tend to have ragged collections of
'import' statements at the top of every module.

Below is the lead module of my C compiler (cc.m) which is not C code,
but in my language. This module only contains project info. This allows
a choice of module for different configurations, but I sometimes just
comment lines in and out.

No other project info, import statements etc appear anywhere else.

5 modules are not shown in that list, which belong to the language's
standard library. Those are included automatically.

-------------------------------
cc.m
-------------------------------

!CLI
module cc_cli

!Global Data and Tables

module cc_decls
module cc_tables

!Lexing and Parsing
module cc_lex
module cc_parse

!General

module cc_lib
module cc_support

!PCL handling
module cc_blockPCL
module cc_genPCL
module cc_libPCL
module cc_pcl

!MCL handling

module cc_mcldecls
module cc_genmcl
module cc_libmcl
module cc_optim
module cc_stackmcl

!Bundled headers

module cc_headers
! module cc_headersx

module cc_export

!Diagnostics
module cc_show
! module cc_showdummy

!x64 and exe backend

! module mc_genss
! module mc_objdecls
! module mc_writeexe
! module mc_writess
! module mc_disasm

-------------------------------

! lines are comments. PCL is the IL. MCL is native code. The mc_ files
provide direct EXE generation, rather than ASM (as normally built it
invokes my external assembly 'as'. I'm joking, it is called 'aa'.). But
I haven't bothered with that backend.

This is in in action:

c:\cx>mm cc Build the above app
Compiling cc.m---------- to cc.exe

c:\cx>cc sql Test cc on sql.c
Compiling sql.c to sql.exe

c:\cx>sql See if it works
SQLite version 3.25.3 2018-11-05 20:37:38
...

Building the compiler with 'mm cc' takes 80ms; that's why I have no need
of dependency graphs or incremental compilation.

bart <bc@freeuk.com> writes:
>On 02/02/2024 18:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:

>I saw an example today in tutorial:
>
> as -o filename.o filename.as
>
>having to type the name twice again.

As has been pointed out numerous times, you don't need to
type both names twice.

All I have to type to build my entire project is 'mr'.

I very seldom every need to use 'cc' or 'as' directly except
for one-off examples to post here.

On 2024-02-02, bart <bc@freeuk.com> wrote:
> That always seems to be the excuse. Some half-finished test version is
> produced, with no proper file interface, and an output that temporarily
> gets sent to a.out until it can be sorted out properly.

Historically, GCC had to work with proprietary "as" programs; it
couldn't redefine the API.

> But it never is finished, and the same raw half-finished product works
> the same way decades later, surprising every new generation who have to
> relearn its quirks.

Most people using GCC do not learn anything about as.

Even those programming in assembler, because the gcc driver
recognizes .s and .S suffixes.

But we've been through this?

> I saw an example today in tutorial:
>
> as -o filename.o filename.as
>
> having to type the name twice again.

You want:

gcc -c filename.S

The .S file is preprocessed for you so you can use #define macros and
#include, and handed off to an assembler, somehow resulting in
filename.o.

There are lots of tutorials out there written by people who are
"writing to learn".

> It just does. I've used a few assemblers, this one is downright weird:

I've used lots of electric stove elements and room heaters! But this
ceramic resistor is weird. It has no on/off switch or temperature
control, and just bare wires?! No plug. Sure, if I pass current through
it, it warms up, so I guess what these electrical engineers call "working"
in their little world.

"as" is not an application designed for programming; it's an internal
toolchain component. Why can't you understand that?

--
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:
> On 02/02/2024 18:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
[...]
> That always seems to be the excuse. Some half-finished test version is
> produced, with no proper file interface, and an output that
> temporarily gets sent to a.out until it can be sorted out properly.

It's not an "excuse", it's an explanation.

But OK, let me drop everything and fix it for you. I can submit a patch
for "as" so it behaves the way you want. I'll also submit patches for
gcc so it invokes "as" with the new interface. It will still have to
handle the old interface at least temporarily, so there will have to be
a way to ask "as" which interface it uses. Nothing will ever generate a
file named "a.out" unless it's explicitly told to do so. I'll also send
the word out so everyone knows not to rely on the name "a.out" anymore.
And I'll convince everyone that they've been doing it wrong for the last
several decades.

I'll let you know when that's done. Because nothing short of that would
satisfy you.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */