My MCC project was intended to upgrade my BCC C compiler to use a
similar backend to my other compilers.

The aims were:

* A more solid code generator that would run more C programs with
fewer errors

* To apply the modest optimiser of that new backend

* To eliminate the intermediate ASM stages of BCC and directly
generate EXEs

* To have faster compilation because of that

* To have full ABI compliance, with proper handling of struct
passing

As it turned out, only the last of those has been achieved, since:

* The generated code, even if better, did not magically make C
programs work that didn't before. It is impractical to debug
large convoluted C programs to find a bug that exists elsewhere
entirely

* I started the direct EXE backend yesterday, but tedium had set in
and I abandoned it. So MCC is slower than BCC, partly because of the
extra IL stage, but also the ASM stages are handled discretely. In
BCC, the ASMs were kept in memory and the assembler was incorporated.

* BCC was a one-file solution (compiler + headers + assembler/linker).
MCC was intended as a 2-file one (windows.h was taken outside; it's
too big). As it is, MCC is a 3-file solution (mcc.exe + aa.exe +
windows.h) which also makes it slower as I said.

* I haven't bothered activating the optimiser.

* I found out that, even without the final EXE generation, it was still
slower than Tiny C, when there are lots of smaller files (with bigger
files, the speed would be about par I think)

So, MCC is still a usable product, and would be a better starting point
for further work (for example, to create an interpreter for its IL,
which opens up debugging capabilities), but I now have two private,
mediocre C compilers.

Something I added to both was support for wildcard inputs like '*.c'. I
did this to more easily build projects like Malcolm's BBX which could be
done like this:

mcc *.c freetype\* samplerate\*.c

To avoid having to type that lot, I put those inputs into an '@' options
file called 'bbx':

*.c freetype\* samplerate\*.c

Now I just type 'mcc @bbx'. I was surprised however when I tried to do:

gcc @bbx

because:

(1) gcc doesn't like backslashes in options files; they have to be "/"

(2) gcc doesn't expand wildcard filespecs like "*.c" inside options
files

Why not? Since this is not done by the OS, it must be done by the app
anyway.

But that's one more small thing at least that my compilers do better!

(The bigger projects I've used as test inputs were:

Lua
TCC
Pico C
SQL (sqlite3.c + shell.c)
BBX
LibJPEG
AA, QQ, CC (transpiled C from three of my projects)

The last three seem to run fine (my conservative C code always does!).
Most of the others seemed to work based on superficial tests, but I
didn't do in-depth testing.

But TCC didn't work. Version 0.9.27 (I tried also .25 and .28) went the
furthest: it could compile programs and produce EXEs, but the EXEs were
faulty.

At some point I will have another go at Seed7.)

On 28/09/2023 12:14, Bart wrote:
> My MCC project was intended to upgrade my BCC C compiler to use a
> similar backend to my other compilers.

> But TCC didn't work. Version 0.9.27 (I tried also .25 and .28) went the
> furthest: it could compile programs and produce EXEs, but the EXEs were
> faulty.

MCC can generate ASM source code with named locals and temps, or using
only their offsets to keep the size down, which is what I'd been using
but had forgotten about.

But there was a problem with the offsets for temps (used when I run out
of registers) which I have to look at.

Generating ASMs with fully named temps, then Tiny C works. Further, the
exe produced can compile itself, to multiple generations. (BCC only
managed one generation.)

So it's not quite as poor as I'd thought. I might have a go at 0.9.28 again.

Bart <bc@freeuk.com> writes:

> My MCC project was intended to upgrade my BCC C compiler to use a
> similar backend to my other compilers. [...]

Please confine your postings in comp.lang.c to topics and subjects
relevant to the C language. None of what you say in your posting
is topical in comp.lang.c. An obvious suggestion is the newsgroup
comp.compilers instead.

On 28/09/2023 23:50, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> My MCC project was intended to upgrade my BCC C compiler to use a
>> similar backend to my other compilers. [...]
>
> Please confine your postings in comp.lang.c to topics and subjects
> relevant to the C language. None of what you say in your posting
> is topical in comp.lang.c. An obvious suggestion is the newsgroup
> comp.compilers instead.

That's me told!

This project was first mentioned as a possibility at the end of August.
I was giving an update on it before moving on to my normal projects and
saner languages.

Maybe some people here (obviously not the old-timers) would find a blog
report on the tribulations of creating a personal C compiler interesting.

Or maybe someone is thinking of doing something of their own, and my
experience shows one-man compilers can be viable.

So how about letting them make up their own mind. If not, it is easy
enough to ignore the post or to killfile me.

Meanwhile I could equally suggest you post all your deadly-dull stuff
about C standards minutiae to comp.std.c

On 2023-09-28, Bart <bc@freeuk.com> wrote:
> On 28/09/2023 23:50, Tim Rentsch wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> My MCC project was intended to upgrade my BCC C compiler to use a
>>> similar backend to my other compilers. [...]
>>
>> Please confine your postings in comp.lang.c to topics and subjects
>> relevant to the C language. None of what you say in your posting
>> is topical in comp.lang.c. An obvious suggestion is the newsgroup
>> comp.compilers instead.
>
> That's me told!

comp.compilers *is* a nice newsgroup, though.

Mind you, it's moderated.

You can't go on long C sucks tirades and whatnot.

Bart <bc@freeuk.com> writes:

> On 28/09/2023 23:50, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> My MCC project was intended to upgrade my BCC C compiler to use a
>>> similar backend to my other compilers. [...]
>>
>> Please confine your postings in comp.lang.c to topics and subjects
>> relevant to the C language. None of what you say in your posting
>> is topical in comp.lang.c. An obvious suggestion is the newsgroup
>> comp.compilers instead.
>
> That's me told!
>
> This project was first mentioned as a possibility at the end of
> August. I was giving an update on it before moving on to my normal
> projects and saner languages.
>
> Maybe some people here (obviously not the old-timers) would find a
> blog report on the tribulations of creating a personal C compiler
> interesting.
>
> Or maybe someone is thinking of doing something of their own, and my
> experience shows one-man compilers can be viable.

None of that changes the reality that your comments are not
about the C language or C programs and so are not topical here.

> So how about letting them make up their own mind. If not, it is easy
> enough to ignore the post or to killfile me.

I know that your MO is to be a rude, self-centered, insecure
jerk. You have been for years and there is no indication that
will change any time soon. There is plenty of evidence that
people in the newgroup here are not interested in what you have
to say about your experience working on compilers, especially
since those compilers are not written in C and aren't faithful to
the C language (and it isn't clear whether you don't know that or
if you just don't care). So people have made up there minds;
the only question is how long it will take you to realize it, if
ever.

> Meanwhile I could equally suggest you post all your deadly-dull stuff
> about C standards minutiae to comp.std.c

My comments about the details of C pertain to the C language and
how to write C programs. They are topical here. Discussions in
comp.std.c are supposed to do with how to change the C standard
or how to read the C standard in areas where there is some
question about what is meant. If you think my comments are
deadly dull you are free to ignore the postings or put me in
your kill file. But whether you do that or not, my comments
are topical, and yours are not.

On 29/09/2023 06:10, Tim Rentsch wrote:

> I know that your MO is to be a rude, self-centered, insecure
> jerk.

What's yours?

On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
> On 29/09/2023 06:10, Tim Rentsch wrote:
>
> > I know that your MO is to be a rude, self-centered, insecure
> > jerk.
> What's yours?
>
Oh don't lower the tone by replying to stuff like that.

I think Tim is in a mood. He posted something negative about me as
well. It's not normal for him.

On 29/09/2023 06:10, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:

> to say about your experience working on compilers, especially
> since those compilers are not written in C

Is that really relevant? Does a compiler for language L have to be
written in L to be taken seriously?

In any case in can be transpiled to C in 60ms:

c:\cx>tm mc -c cc
Compiling cc.m---------- to cc.c
TM: 0.06

> and aren't faithful to
> the C language (and it isn't clear whether you don't know that or
> if you just don't care).

In which ways? My product compiles a C 'subset' but does not formally
define what it is. Yet it manages to compile 100s of 1000s of lines of C
applications (not my generated code) which would be challenging for many
such small compilers.

But it no longer supports my own extensions, like the many that gcc
provides, and it no longer tries to improve on the language or fail
programs on features I feel ought to be deprecated.

On 29/09/2023 11:35, Malcolm McLean wrote:
> On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
>> On 29/09/2023 06:10, Tim Rentsch wrote:
>>
>>> I know that your MO is to be a rude, self-centered, insecure
>>> jerk.
>> What's yours?
>>
> Oh don't lower the tone by replying to stuff like that.
>
> I think Tim is in a mood. He posted something negative about me as
> well. It's not normal for him.
>

I think it is!

He seems to like policing this /unmoderated/ newsgroup according to what
/he/ finds interesting or relevant.

Meanwhile many here are happy to participate in endless discussions
about the 'halting' problem.

On Friday, September 29, 2023 at 1:21:44 PM UTC+3, Bart wrote:
> On 29/09/2023 06:10, Tim Rentsch wrote:
>
> > I know that your MO is to be a rude, self-centered, insecure
> > jerk.
> What's yours?

Modus operandi.
Is there kitchen.lang.latin newsgroup?

On Friday, September 29, 2023 at 1:59:18 PM UTC+3, Bart wrote:
> On 29/09/2023 11:35, Malcolm McLean wrote:
> > On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
> >> On 29/09/2023 06:10, Tim Rentsch wrote:
> >>
> >>> I know that your MO is to be a rude, self-centered, insecure
> >>> jerk.
> >> What's yours?
> >>
> > Oh don't lower the tone by replying to stuff like that.
> >
> > I think Tim is in a mood. He posted something negative about me as
> > well. It's not normal for him.
> >
> I think it is!
>
> He seems to like policing this /unmoderated/ newsgroup according to what
> /he/ finds interesting or relevant.
>
> Meanwhile many here are happy to participate in endless discussions
> about the 'halting' problem.

Many? You are wildly exaggerating.

On Friday, 29 September 2023 at 12:07:50 UTC+1, Michael S wrote:
> On Friday, September 29, 2023 at 1:59:18 PM UTC+3, Bart wrote:
> > On 29/09/2023 11:35, Malcolm McLean wrote:
> > > On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
> > >> On 29/09/2023 06:10, Tim Rentsch wrote:
> > >>
> > >>> I know that your MO is to be a rude, self-centered, insecure
> > >>> jerk.
> > >> What's yours?
> > >>
> > > Oh don't lower the tone by replying to stuff like that.
> > >
> > > I think Tim is in a mood. He posted something negative about me as
> > > well. It's not normal for him.
> > >
> > I think it is!
> >
> > He seems to like policing this /unmoderated/ newsgroup according to what
> > /he/ finds interesting or relevant.
> >
> > Meanwhile many here are happy to participate in endless discussions
> > about the 'halting' problem.
> Many? You are wildly exaggerating.
>
There's one poster who occasionally posts to comp.lang.c who believes he has
found a flaw in the straightforwards proof that halting is non-computable that
everyone knows (run the halt detector on itself then loop forever if it detects
halt, and halt if it detects non-halting behaviour is the gist). The volume of
discussion that this has created is unbelieveable and, yes, I have participated
myself.

Mostly he posts to comp.theory however, where it is at least technically on topic.

In article <2c2f6ab4-949a-46ff-b97c-036103f396d5n@googlegroups.com>,
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
>> On 29/09/2023 06:10, Tim Rentsch wrote:
>>
>> > I know that your MO is to be a rude, self-centered, insecure
>> > jerk.
>> What's yours?
>>
>Oh don't lower the tone by replying to stuff like that.
>
>I think Tim is in a mood. He posted something negative about me as
>well. It's not normal for him.
>

It *is* normal for him.

That's all he does - posts the most boring, uninteresting drivel
imaginable, but, yet, at least by the looser standard now generally used in
CLC, on-topic.

(Note and clarification of the above: By the usual standard of most groups,
as applied to the specific rules of CLC, *nothing* is on-topic here. But
of course, that standard is rarely applied, since it would lead to, well,
you know, nothing ever being posted)

--
Just like Donald Trump today, Jesus Christ had a Messiah complex.

And, in fact, the similarities between the two figures are quite striking.
For example, both have a ragtag band of followers, whose faith cannot be shaken.

In article <uf6alm$809b$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 29/09/2023 11:35, Malcolm McLean wrote:
>> On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
>>> On 29/09/2023 06:10, Tim Rentsch wrote:
>>>
>>>> I know that your MO is to be a rude, self-centered, insecure
>>>> jerk.
>>> What's yours?
>>>
>> Oh don't lower the tone by replying to stuff like that.
>>
>> I think Tim is in a mood. He posted something negative about me as
>> well. It's not normal for him.
>>
>
>I think it is!

Yes. It is.

>He seems to like policing this /unmoderated/ newsgroup according to what
>/he/ finds interesting or relevant.

Yup.

>Meanwhile many here are happy to participate in endless discussions
>about the 'halting' problem.

Yup.

The rules are obviously applied, to put it charitably, inconsistently.

Topicality rules for thee, but not for me.

--
Pensacola - the thinking man's drink.

On 29/09/2023 12:59, Bart wrote:
> On 29/09/2023 11:35, Malcolm McLean wrote:
>> On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
>>> On 29/09/2023 06:10, Tim Rentsch wrote:
>>>
>>>> I know that your MO is to be a rude, self-centered, insecure
>>>> jerk.
>>> What's yours?
>>>
>> Oh don't lower the tone by replying to stuff like that.
>>
>> I think Tim is in a mood. He posted something negative about me as
>> well. It's not normal for him.
>
> I think it is!
>
> He seems to like policing this /unmoderated/ newsgroup according to what
> /he/ finds interesting or relevant.
>

Tim is an extraordinarily patronising grumpy old git. (And that is
coming from someone who knows he can often be patronising!) He is also
very rarely wrong about the technicalities of C, and thus a useful
resource for this group.

I don't think you need fear the consequences of being on his bad side -
he killfiled me years ago, without it doing me any harm.

I do appreciate that it's useful for there to be occasional "policing"
of the group - polite reminders when threads are straying too far from
topicality. We want to keep the group strongly focused on C. (And I
say that as someone who is on the receiving end of such reminders every
now and again - I don't always follow them immediately, but I approve of
the principle.)

Discussions about specific compiler details have traditionally been
off-topic in comp.lang.* groups - its too easy to get bogged down by
compiler-specific threads rather than threads about the language itself.
Some mention of common compilers is inevitable.

However, I do think that a thread about your C compiler is very much
on-topic. You might get into a heated discussion, but that's hardly
unusual. You might get tips or ideas, or answers to questions.

> Meanwhile many here are happy to participate in endless discussions
> about the 'halting' problem.

Actually, almost all the comp.lang.c regulars were strongly against such
discussions, at least when it became clear that the person behind them
was off his head and not the slightest bit interested in listening to
rational arguments or mathematical realities.

But "whataboutism" is not a good argument anyway.

On 29/09/2023 11:35, Malcolm McLean wrote:
> On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
>> On 29/09/2023 06:10, Tim Rentsch wrote:
>>
>>> I know that your MO is to be a rude, self-centered, insecure
>>> jerk.
>> What's yours?
>>
> Oh don't lower the tone by replying to stuff like that.
>
> I think Tim is in a mood. He posted something negative about me as
> well. It's not normal for him.
>

Perhaps ...

He can tell intuitively that 7 things annoy him, but he can only be
concurrently irritated about 3 of them.

....?

No? I'll get my coat.

Kenny McCormack about Tim:

> That's all he does - posts the most boring, uninteresting
> drivel imaginable, but, yet, at least by the looser
> standard now generally used in CLC, on-topic.

Technical discussions can be boring to an observer who has
mastered the subject, but I for one appreciate Tim's
feedback to my articles.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 29/09/2023 15:40, David Brown wrote:

> However, I do think that a thread about your C compiler is very much
> on-topic.  You might get into a heated discussion, but that's hardly
> unusual.  You might get tips or ideas, or answers to questions.

You might be pleased to know that the revised version is less verbose by
default when more than one file is involved.

But it is still somewhat more so than gcc:

c:\luac>gcc @lua

c:\luac>mcc @lua
Compiling 33 files to lua.exe

Anton Shepelev <anton.txt@gmail.moc> writes:

> Kenny McCormack about Tim:
>
>> That's all he does - posts the most boring, uninteresting
>> drivel imaginable, but, yet, at least by the looser
>> standard now generally used in CLC, on-topic.

Apparently Kenny has forgotten a recent posting of mine,
responding to his posting asking something, that was meant
to provide a helpful answer to his question.

> Technical discussions can be boring to an observer who has
> mastered the subject, but I for one appreciate Tim's
> feedback to my articles.

Thank you, it's nice to hear that someone appreciates my
comments.

Bart <bc@freeuk.com> writes:

> On 29/09/2023 06:10, Tim Rentsch wrote:
>
>> I know that your MO is to be a rude, self-centered, insecure
>> jerk.
>
> What's yours?

I presume this question is meant to be rhetorical. Still
it might be useful to write down some of the precepts I
try to follow. Please add "I try to", or words to that
effect, at the start of each of the following.

Distinguish facts, beliefs, and opinion.

Emphasize communication and exchange of views, seeking
to convey rather than convince; prefer discussion to
debate. The first goal is for each person to understand
the other.

Avoid oversimplification: I should at least mention
when a statement is only approximately true rather than
completely accurate.

Double check any statements for correctness, accuracy,
and completeness.

Stay out of arguments about programming style. I very
much want to understand why people prefer to write code
the way the do, but in most cases there is little to be
gained in having an argument about it.

Follow general rules of good writing - be concise, direct,
unambiguous, accurate, and easy to read. Always review
and revise; do at least one final reading before sending.

Observe topicality guidelines. Many times when I am
wondering about whether to post a followup, noticing
that the discussion has strayed well outside the lines
of what is topical makes the decision easy: don't post.

Post only when what I would say seems to add value. If
someone else has answered the question, there is no reason
to reply unless I have something useful to add.

Be calm before following up. Usually it helps to let hot
blood cool down before continuing an emotional exchange.

Respond to what is written, not to the personality of the
writer. Avoid ad hominem remarks.

Practice active listening - both making an effort to hear
and understand what other people are saying, and checking
back to make sure they are following what I am saying.

Both respect others' preferences and stay faithful to my
own judgments about what to say and how to say it. Be
polite and considerate but also firm. I like to think
I'm getting better at this one; I am working on it.

Strive to improve. Needless to say I am not always
successful in following these principles so when I
notice a shortcoming I try to do better next time.

(No doubt there are some additional habits or principles
I have left out, but I am stopping here at least for now.)

Bart <bc@freeuk.com> writes:

> On 29/09/2023 06:10, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>>
>> to say about your experience working on compilers, especially
>> since those compilers are not written in C
>
> Is that really relevant? Does a compiler for language L have to be
> written in L to be taken seriously?

What matters is whether you have something to say about
programming in C or about the C language. Your compiler
isn't written in C so anything you have to say about the
compiler itself isn't relevant here, whether or not it
should be taken seriously.

In talking about how the compiler behaves, you don't say
anything that pertains to the C language. I don't think
this notion is very hard to understand. Talking about the
environment in which the compiler is built, even though it
might be interesting in other contexts, still has nothing
to do with the C language.

>> and aren't faithful to
>> the C language (and it isn't clear whether you don't know that or
>> if you just don't care).
>
> In which ways?

No one knows but you, and it's not even clear if you know.
Ironically, if you were to go through and make up a list of
differences between what your compiler accepts and what the
C standard requires, and present that list here, that WOULD
be topical, especially if there were reasons related to how
easy or hard some aspects of C are to compile. For reasons
beyond understanding you leave out exactly the pieces of
information that would make it relevant in comp.lang.c. I'm
at a loss to understand why you do that.

> My product compiles a C 'subset' but does not formally
> define what it is.

An informal definition is a lot better than no description
at all, and at least is something about the C language.
So figure out what the discrepancies are (and only you can
do that), and tell us about it. That's why we're here!

> [speed of compiler]

There's nothing wrong with feeling pride in having written
a fast program (in a non-C language), but it's not a subject
of interest in this newsgroup.

> But it no longer supports my own extensions, like the many that gcc
> provides, and it no longer tries to improve on the language or fail
> programs on features I feel ought to be deprecated.

What would be relevant and possibly interesting is to say
what C language constructs you think should be considered
or left out. Not what constructs IN OTHER LANGUAGES you
think are nice but what additions or changes to C you think
could add value. Explain what, and leave it at that; let
other people form their own opinions about how valuable
each change might be.

On 16/10/2023 03:26, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:

>> My product compiles a C 'subset' but does not formally
>> define what it is.
>
> An informal definition is a lot better than no description
> at all, and at least is something about the C language.
> So figure out what the discrepancies are (and only you can
> do that), and tell us about it. That's why we're here!

OK, an informal definition is the subset of C that I personally use, and
that I saw being commonly used on open source projects, at the start of
2017.

It would loosely be C99 but missing Complex, VLAs, designated
initialisers, compound literals, but with _Generic from C11 (that one
could be trivially implemented in about 40 lines of code).

Since 2017, those missing features are much more commonly used, but I
haven't changed the front end of the compiler.

There are also a whole bunch of restrictions and points of non-conformance.

Still, the compiler works on these projects there were used for testing:

* sqlite3.c + shell.c
* Tiny C 0.9.27 (0.9.28 uses extra features)
* Lua 5.4
* Pico C interpreter
* BBX (Malcolm's resource compiler)
* LIBJPEG 9e
* Piet (an interpeter for programs that look like Mondrian paintings)

Plus a bunch of smaller ones. Plus all the generated C code from my
tools, but that uses an even smaller subset (eg. there are no #includes
and no macros).

>> [speed of compiler]
>
> There's nothing wrong with feeling pride in having written
> a fast program (in a non-C language), but it's not a subject
> of interest in this newsgroup.

I didn't mention the speed of the compiler. I said I can /transpile/ the
source code to C more or less instantly, since the choice of the
implementation language seemed to be an issue for you.

The actual speed of MCC is limited by having to use an intermediate ASM
stage.

Bart <bc@freeuk.com> writes:

> On 16/10/2023 03:26, Tim Rentsch wrote:
>
>> Bart <bc@freeuk.com> writes:
>
>
>>> My product compiles a C 'subset' but does not formally
>>> define what it is.
>>
>> An informal definition is a lot better than no description
>> at all, and at least is something about the C language.
>> So figure out what the discrepancies are (and only you can
>> do that), and tell us about it. That's why we're here!
>
> OK, an informal definition is the subset of C that I personally
> use, and that I saw being commonly used on open source projects,
> at the start of 2017.
>
> It would loosely be C99 but missing Complex, VLAs, designated
> initialisers, compound literals, but with _Generic from C11 (that
> one could be trivially implemented in about 40 lines of code).

Given that, a good target would be to aim for conformance with
C11, where Complex and VLAs are optional. Compound literals
and designated initializers shouldn't be that hard to add, and are
both very useful. If you can get your compiler up to the level
of C11 conformance, or at least close enough, I would consider
trying it with my current project (which is written entirely
in C). The code in that project uses both compound literals and
designated initializers. Do you handle bitfields? I use those
also.

> Since 2017, those missing features are much more commonly used,
> but I haven't changed the front end of the compiler.
>
> There are also a whole bunch of restrictions and points of
> non-conformance.

Please elaborate. These details are just the sort of thing
that the group is here to discuss.

> Still, the compiler works on these projects [list]

This doesn't tell me anything since I am not familiar with
these code bases.

>>> [speed of compiler]
>>
>> There's nothing wrong with feeling pride in having written
>> a fast program (in a non-C language), but it's not a subject
>> of interest in this newsgroup.
>
> I didn't mention the speed of the compiler. [...]

Sorry, I misread your earlier comment. Those comments were on a
subject not of interest in the newsgroup, but indeed they were not
about the speed of the compiler. My apologies for the incorrect
summary.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 29 September 2023 at 11:21:44 UTC+1, Bart wrote:
>
>> On 29/09/2023 06:10, Tim Rentsch wrote:
>>
>>> I know that your MO is to be a rude, self-centered, insecure
>>> jerk.
>>
>> What's yours?
>
> Oh don't lower the tone by replying to stuff like that.
>
> I think Tim is in a mood.

If I am in a mood it's because a few self-centered individuals
repeatedly engage in voluminous and protracted discussions whose
overlap with material germane to the topic of the newsgroup can
be measured in at most small numbers of square angstroms, and who
persist in doing so despite multiple requests not to.

> He posted something negative about me as well.

That's wrong. My comments were about what you wrote, not about
you. I recommend to everyone that they learn to tell the
difference between the two.

> It's not normal for him.

It is unusual for me to make direct ad hominem remarks. I
confess that I don't respond well to flagrantly rude and
inconsiderate behavior.