On 14/01/2024 17:54, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> bart <bc@freeuk.com> writes:
> [...]
>
>> You repeatedly react strongly to things nobody said. You invent
>> strawman arguments.
>
> That's what bart does. He continually misrepresents other
> people's statements, to make them look stupid, so he can feel
> superior. Only insecure people feel a need to perpetually brag
> and to constantly run down everyone else's point of view.

Yes, sorry. I forgot that was your job.

On 1/14/24 13:17, bart wrote:
> On 14/01/2024 17:54, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> bart <bc@freeuk.com> writes:
>> [...]
>>
>>> You repeatedly react strongly to things nobody said.  You invent
>>> strawman arguments.
>>
>> That's what bart does.  He continually misrepresents other
>> people's statements, to make them look stupid, so he can feel
>> superior.  Only insecure people feel a need to perpetually brag
>> and to constantly run down everyone else's point of view.
>
> Yes, sorry. I forgot that was your job.
>
>

I'm new here, so please forgive my ignorance. What's yours?

I suppose what I'm asking is: What exactly is your goal here, Bart?

On 2024-01-14, Anthony Cuozzo <anthony@cuozzo.us> wrote:
> On 1/14/24 13:17, bart wrote:
>> On 14/01/2024 17:54, Tim Rentsch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> You repeatedly react strongly to things nobody said.?? You invent
>>>> strawman arguments.
>>>
>>> That's what bart does.?? He continually misrepresents other
>>> people's statements, to make them look stupid, so he can feel
>>> superior.?? Only insecure people feel a need to perpetually brag
>>> and to constantly run down everyone else's point of view.
>>
>> Yes, sorry. I forgot that was your job.
>>
>>
>
> I'm new here, so please forgive my ignorance. What's yours?
>
> I suppose what I'm asking is: What exactly is your goal here, Bart?

Good question. This thread has gone on. and on, and on, and ....
Most sane people would have got bored and found something better to do.

On 14/01/2024 18:44, Anthony Cuozzo wrote:
> On 1/14/24 13:17, bart wrote:
>> On 14/01/2024 17:54, Tim Rentsch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> You repeatedly react strongly to things nobody said.  You invent
>>>> strawman arguments.
>>>
>>> That's what bart does.  He continually misrepresents other
>>> people's statements, to make them look stupid, so he can feel
>>> superior.  Only insecure people feel a need to perpetually brag
>>> and to constantly run down everyone else's point of view.
>>
>> Yes, sorry. I forgot that was your job.
>>
>>
>
> I'm new here, so please forgive my ignorance. What's yours?
>
> I suppose what I'm asking is: What exactly is your goal here, Bart?

What is anyone's goal here?

This newsgroup is just a bunch of old-timers who mainly discuss the
finer points of the C standard, although the group has been more or less
dead for the past couple of years.

Since there are rarely any people who post about any practical problems,
I think they mainly use stackoverflow and reddit for that. The regulars
mainly just argue amongst themselves.

I'm somewhat of an outsider and I like to point out things that I
believe are wrong in things like the C language and the assorted
collection of Unix-specific tools that apparently go with it.

I'm an outsider because I don't routinely use C, or any of the tools,
and because I don't have background in Unix-based development. I have a
different perspective.

So, what happens here is that I mention something that might be some
bizarre quirk of C, or some weird, unfriendly way some tool works, or
anything that goes against common-sense or intuition, or that I find has
caused me grief.

And then the regulars, instead of agreeing, go on the defensive. Some go
on the attack, saying I'm the one at fault, I should RTFM, or do this or
that, or that I'm ignorant, etc etc. (You've seen the thread.)

So since I have nothing better to do**, I like to defend myself. And
sometimes it is fascinating seeing people defend the indefendable.

All people need to do is be honest.

Does that answer your question?

(** That's not quite true, this is taking me away from my current
project. But when people openly insult me, I can't let it go. They need
to stop replying.)

On 1/14/2024 10:10 AM, bart wrote:
> On 14/01/2024 17:22, Tim Rentsch wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> On 12/01/2024 19:15, Scott Lurndal wrote:
>> [...]
>>>> What the FM documents.  RTFM.
>>>
>>> I see.  So forget just having intuitive behaviour. [...]
>>
>> The problem is not what the behavior is.  The problem is
>> with your intuition about what the behavior should be.
>
> I would love to know what behaviour of an assembler is intuitive to /you/.

I assemble my code (GAS, MASM, ect...) and make it produce an object
file (*.o) or whatever. Then I use it in the linker...

[...]

On 1/14/2024 11:57 AM, bart wrote:
> On 14/01/2024 18:44, Anthony Cuozzo wrote:
>> On 1/14/24 13:17, bart wrote:
>>> On 14/01/2024 17:54, Tim Rentsch wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> bart <bc@freeuk.com> writes:
>>>> [...]
>>>>
>>>>> You repeatedly react strongly to things nobody said.  You invent
>>>>> strawman arguments.
>>>>
>>>> That's what bart does.  He continually misrepresents other
>>>> people's statements, to make them look stupid, so he can feel
>>>> superior.  Only insecure people feel a need to perpetually brag
>>>> and to constantly run down everyone else's point of view.
>>>
>>> Yes, sorry. I forgot that was your job.
>>>
>>>
>>
>> I'm new here, so please forgive my ignorance. What's yours?
>>
>> I suppose what I'm asking is: What exactly is your goal here, Bart?
>
> What is anyone's goal here?
>
> This newsgroup is just a bunch of old-timers who mainly discuss the
> finer points of the C standard, although the group has been more or less
> dead for the past couple of years.

Old Timers? Is 46 old? Well, okay bad example... ;^) lol.

[...]

bart <bc@freeuk.com> writes:
> On 14/01/2024 17:22, Tim Rentsch wrote:
>> bart <bc@freeuk.com> writes:
>>> On 12/01/2024 19:15, Scott Lurndal wrote:
>> [...]
>>>> What the FM documents. RTFM.
>>>
>>> I see. So forget just having intuitive behaviour. [...]
>> The problem is not what the behavior is. The problem is
>> with your intuition about what the behavior should be.
>
> I would love to know what behaviour of an assembler is intuitive to /you/.
>
> Or anybody.
>
> I would be surprised if that involved the brain-dead behaviour of
> either naming every output 'a.out', so overwriting the file created 5
> seconds previously, or spewing reams of binary code to a text terminal
> sensitive to escape codes.

I already mentioned that GNU as doesn't write machine code to the
terminal. (I discussed problems that could occor *if it did*.) Did you
miss that? I know you're seeing at least *some* of my posts.

Yes, it writes its output to "a.out" by default, for historical reasons.
It also has an option to specify the name of the output file -- an
option that is almost always used in practice. Invoking the "as"
command directly is relatively rare.

I don't know how many scripts there are that assume "a.out" is the
default output name, but changing the behavior of GNU as would break
those scripts. It would also require updates to some books and
tutorials. And for no particular benefit (I know you disagree with
that).

You don't like the default? Don't use it. As far as I know, hardly
anyone does.

> I don't know how many assemblers you're written; I've done four or
> five standalone ones. All took files as input, and wrote
> correspondingly named files as output.

It turns out that the ability to read from stdin is convenient.

> (Except my first one, but that machine didn't a file system, so it can
> be excused.)
>
> The behaviour of 'as' is quite extraordinary. But it is typical of the
> regulars here to gang up on somebody who points out the bleeding
> obvious, and pretend that /they/ are mistaken, and that 'as' works
> perfectly.

Stop lying. Nobody says that it works "perfectly". It works the way it
works, which is sufficient to cover all reasonable use cases. If you
misuse it, you can have problems.

[...]

> How about accepting some constructive criticism for a change, and
> ADMITTING that the behaviour is rubbish, but it has to be accepted
> because the way it works is hard-coded into too many tools to change it.

I don't admit that the behavior is "rubbish", because I don't think it
is. You do. That's fine; I have no interest in changing your mind.
The behavior is unlikely to change because other tools would have to be
changed to accomodate the change -- *and* because the existing behavior
is good enough.

Now if I were designing the UI from scratch, I might have it take an
input file name on the command line and replacing the input file name
suffix with ".o" as the default output file name; if no input file name
is provided, it reads from stdin and the "-o" option becomes mandatory.
(That's just off the top of my head, and I may have missed something.)

That would be, in my humble opinion, a slightly cleaner UI than what we
have now -- but it would provide exactly zero functionality that the
current UI doesn't already provide.

> Having a product called 'as2' is totally out of the question of course!

Nobody is stopping you. GNU as is free software. If you want to fork
it and implement your preferred default behavior, go for it. It's
unlikely you'll convince anyone to use it, though.

--
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-01-14, bart <bc@freeuk.com> wrote:
> On 12/01/2024 21:31, Kaz Kylheku wrote:
>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>
>>> I mainly remember the times when they do hang.
>>
>> DOS/Windows stuff hangs also:
>>
>> C:\Users\kazk>findstr foo
>> ... "hang" ...
>>
>> Even Microsoft clued in to the idea that a text filter shouldn't
>> spew extraneous diagnostics by default.
>
> If you type 'findstr' with no arguments, it reports an error. Maybe
> 'sort' was a better example to make your point.

So does grep with no arguments? I don't see where that is going.
>
>>> But with 'as', it just sits there. I wonder what it's waiting for; for
>>> me to type in ASM code live from the terminal? (If 'as' is designed for
>>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember
>>> it generating discrete, temporary .s files.)
>>
>> gcc -pipe works in pipe mode.
>>
>> The "as" command is intended for compiler use; not only is it not
>> an interactive assembler, it doesn't even have particularly good
>> diagnostics for batch use. You have to know what you're doing.
>
> You're sort of making excuses for it.

I'm just stating what I have always believed the requirements to be.

In Unixes and the GNU Project, there has not been a focus on assembly
language as a primary development language, with a great developer
experience.

That's pretty much a fact.

The amount of material written in .s or .S files is very small.

> My 'aa' assembler was also
> designed mainly for machine-generated code, so it has very few frills.
>
> The syntax however is decent enough that I can use it for my inline
> assembler too.

GCC has great inline assembly.

You can reference C expressions, which
are evaluated to registers that the register allocator chooses, which
you can reference in your inline code in a symbolic way.

You can also indicate that your code template has certain effects,
so that the compiler is informed.

I had a nice experience many years ago when I wrapped the MIPS
"load-linked/store-conditional" primitives as separate inline code
macros.

When I used these macros to write a synchronization primitive, GCC
optimized away an unnecessary instruction or two, due to the way they
integrated together.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-14, bart <bc@freeuk.com> wrote:
> How about accepting some constructive criticism for a change, and
> ADMITTING that the behaviour is rubbish, but it has to be accepted
> because the way it works is hard-coded into too many tools to change it.

I think a lot of aspects of "as" could easily be changed without
breaking anything.

But nobody is screaming for "as" to provide a great developer experience
to someone writing large amounts of code in assembly language; it is not
a pain point.

The GNU implementation of the OS/360 JCL (job control language) is
even worse than GNU As: it is so bad, that it doesn't actually exist.

That's not going to change, until that lack causes hurt to the GNU
project.

The times when I have used assembly language in the context of gcc,
I didn't run "as", because gcc recognizes .s and .S files.

It exhibits the usual conventions: with -c, the .s file goes to .o,
otherwise it's a complete program that goes to a.out.

Typically, I don't have to do anything in a Makefile to add an assembly
language source file. Just list the object file in the OBJS variable.

E.g. having created a crc32-x86.S I would add it to the OBJS :=
line in the Makefile:

OBJS := ... crc32-x86.o

and that's it. Make will deduce that there is a crc32-x86.S from
which that can be built, and then the $(OBJS) are what the program
is built from; the .o is pulled into it.

Empty directory:

$ ls -l
total 0

Empty assembler file:

$ touch foo.S

Make .o with no instructions in it:

$ make foo.o
cc -c -o foo.o foo.S
$ ls -l
total 4
-rw-rw-r-- 1 kaz kaz 444 Jan 14 16:48 foo.o
-rw-rw-r-- 1 kaz kaz 0 Jan 14 16:48 foo.S
$ file foo.o
foo.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

This is just familiar commands I've been using for over 30 years; nothing
weird. Just like you, I don't have to learn anything time-wasting and
unproductive arcania.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> bart <bc@freeuk.com> writes:
>> On 14/01/2024 17:22, Tim Rentsch wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 12/01/2024 19:15, Scott Lurndal wrote:
>>> [...]
>>>>> What the FM documents. RTFM.
>>>>
>>>> I see. So forget just having intuitive behaviour. [...]
>>> The problem is not what the behavior is. The problem is
>>> with your intuition about what the behavior should be.
>>
>> I would love to know what behaviour of an assembler is intuitive to /you/.
>>
>> Or anybody.
>>
>> I would be surprised if that involved the brain-dead behaviour of
>> either naming every output 'a.out', so overwriting the file created 5
>> seconds previously, or spewing reams of binary code to a text terminal
>> sensitive to escape codes.
>
> I already mentioned that GNU as doesn't write machine code to the
> terminal. (I discussed problems that could occor *if it did*.) Did you
> miss that? I know you're seeing at least *some* of my posts.
>
> Yes, it writes its output to "a.out" by default, for historical reasons.
> It also has an option to specify the name of the output file -- an
> option that is almost always used in practice. Invoking the "as"
> command directly is relatively rare.

Invoking the as command directly is not just rare, it's a poor
which invites causing problems for someone who tries to cross-compile
your program.

Your compiler knows where the assembler is; it was configured to know
that.

If your compiler is /path/to/arm-toolchain/bin/arm-linux-gnu-gcc,
it's very unlikely that "as" is the right thing for calling the
assembler.

It might quite likely be /path/to/arm-toolchain/bin/arm-linux-gnu-as
(i.e. use the same $(CROSS) prefix), but that is an educated guess.
The assembler comes from binutils and might be at a different path,
even if the basename is right.

The best thing is to just invoke the compiler front end on the .s file.
(If it is .S, you have to for the reason that it has to be preprocessed.
I make assembly files .S because soone or later, someone will need
preprocessing, and git has shit support for renaming.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 15/01/2024 00:34, Kaz Kylheku wrote:
> On 2024-01-14, bart <bc@freeuk.com> wrote:
>> On 12/01/2024 21:31, Kaz Kylheku wrote:
>>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>
>>>> I mainly remember the times when they do hang.
>>>
>>> DOS/Windows stuff hangs also:
>>>
>>> C:\Users\kazk>findstr foo
>>> ... "hang" ...
>>>
>>> Even Microsoft clued in to the idea that a text filter shouldn't
>>> spew extraneous diagnostics by default.
>>
>> If you type 'findstr' with no arguments, it reports an error. Maybe
>> 'sort' was a better example to make your point.
>
> So does grep with no arguments? I don't see where that is going.

This is about typing some command and it is apparently doing nothing, no
indication whether it's busy, has crashed, is stuck in a loop, or is
waiting for YOU to do something.

I didn't know grep was on Windows, but if I type 'grep' with no params,
it gives a usage message, so no complaints there.

> In Unixes and the GNU Project, there has not been a focus on assembly
> language as a primary development language, with a great developer
> experience.
>
> That's pretty much a fact.

That is extraordinary. Wasn't C first implemented in assembly? It's
always been a mainstay of computing as far as I can remember. Except no
one now write whole apps in assembly. (I've done quite a few in the past.)

Plenty though implement compilers that generate ASM source /in a file/
and they expect to feed that to an assembler. Most generate object files
from that.

>
> The amount of material written in .s or .S files is very small.
>
>> My 'aa' assembler was also
>> designed mainly for machine-generated code, so it has very few frills.
>>
>> The syntax however is decent enough that I can use it for my inline
>> assembler too.
>
> GCC has great inline assembly.

> You can reference C expressions, which
> are evaluated to registers that the register allocator chooses, which
> you can reference in your inline code in a symbolic way.

GCC inline assembly looks absolutely diabolic. I take it you've never
seen it done properly?

Actually I spent 5-10 minutes looking for examples, to try and figure
out if asm instructions could in fact directly refer to symbols in the HLL.

But most examples were one or two lines of weird syntax, following by
some interfacing code. So I don't know.

If /I/ had to write extensive programs in gcc inline assembly, then put
a gun to my head now!

Take this example in C:

int a;

void F(void) {
int b=2, c=3;
static int d=4;

a = b + c * d;
}

I will now show it in my language but with that assignment replaced by
inline assembly:

int a

proc F=
int b:=2, c:=3
static int d=4

assem
mov rax, [c] # (note my ints are 64 bits)
imul2 rax, [d]
add rax, [b]
mov [a], rax
end
end

My question is: what would the C version look like with that line in gcc
inline assembly? (In both cases, 'a' should end up with the value 14.)

You need to tell me, because I will otherwise not have a clue. From what
I've seen of gcc inline asm:

* Code has to be written within string literals, in dreadfil AT&T
syntax. And apparently even with embedded \n line breaks. (Good
grief - I think early 80s BASICs had more sophisticated facilities!)

* You mostly use offsets to get at local variables

* You apparently aren't allowed to use just any registers as you need
to negotiate with gcc so as not to interfere with /its/ use of
registers. So most examples I saw seemed to deal with this.

I consider that when writing assembly, YOU are in charge not the
compiler. As you can see from mine:

* It is written just as it would be in an actual ASM file

* You can refer to variables directly (the compiler will add what is
needed to access locals or statics)

If a function uses inline ASM, variables are kept in memory not
registers. (I might allow that at some point.) Most such functions
however contain only ASM.

That still lets ASM use the facilities of the HLL such as functions,
declarations, named constants, scopes etc.

I suppose you're going to suggest that gcc's facilities are superior...

On 1/14/2024 4:34 PM, Kaz Kylheku wrote:
> On 2024-01-14, bart <bc@freeuk.com> wrote:
>> On 12/01/2024 21:31, Kaz Kylheku wrote:
>>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>
>>>> I mainly remember the times when they do hang.
>>>
>>> DOS/Windows stuff hangs also:
>>>
>>> C:\Users\kazk>findstr foo
>>> ... "hang" ...
>>>
>>> Even Microsoft clued in to the idea that a text filter shouldn't
>>> spew extraneous diagnostics by default.
>>
>> If you type 'findstr' with no arguments, it reports an error. Maybe
>> 'sort' was a better example to make your point.
>
> So does grep with no arguments? I don't see where that is going.
>>
>>>> But with 'as', it just sits there. I wonder what it's waiting for; for
>>>> me to type in ASM code live from the terminal? (If 'as' is designed for
>>>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember
>>>> it generating discrete, temporary .s files.)
>>>
>>> gcc -pipe works in pipe mode.
>>>
>>> The "as" command is intended for compiler use; not only is it not
>>> an interactive assembler, it doesn't even have particularly good
>>> diagnostics for batch use. You have to know what you're doing.
>>
>> You're sort of making excuses for it.
>
> I'm just stating what I have always believed the requirements to be.
>
> In Unixes and the GNU Project, there has not been a focus on assembly
> language as a primary development language, with a great developer
> experience.
>
> That's pretty much a fact.
>
> The amount of material written in .s or .S files is very small.
>
>> My 'aa' assembler was also
>> designed mainly for machine-generated code, so it has very few frills.
>>
>> The syntax however is decent enough that I can use it for my inline
>> assembler too.
>
> GCC has great inline assembly.
>
> You can reference C expressions, which
> are evaluated to registers that the register allocator chooses, which
> you can reference in your inline code in a symbolic way.
>
> You can also indicate that your code template has certain effects,
> so that the compiler is informed.
>
> I had a nice experience many years ago when I wrapped the MIPS
> "load-linked/store-conditional" primitives as separate inline code
> macros.
>
> When I used these macros to write a synchronization primitive, GCC
> optimized away an unnecessary instruction or two, due to the way they
> integrated together.
>

GCC had a nasty bugger wrt trylock around 20 years ago. There is a
thread over on comp.programming.threads that mentions it.

On 1/14/2024 4:34 PM, Kaz Kylheku wrote:
> On 2024-01-14, bart <bc@freeuk.com> wrote:
>> On 12/01/2024 21:31, Kaz Kylheku wrote:
>>> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>
>>>> I mainly remember the times when they do hang.
>>>
>>> DOS/Windows stuff hangs also:
>>>
>>> C:\Users\kazk>findstr foo
>>> ... "hang" ...
>>>
>>> Even Microsoft clued in to the idea that a text filter shouldn't
>>> spew extraneous diagnostics by default.
>>
>> If you type 'findstr' with no arguments, it reports an error. Maybe
>> 'sort' was a better example to make your point.
>
> So does grep with no arguments? I don't see where that is going.
>>
>>>> But with 'as', it just sits there. I wonder what it's waiting for; for
>>>> me to type in ASM code live from the terminal? (If 'as' is designed for
>>>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember
>>>> it generating discrete, temporary .s files.)
>>>
>>> gcc -pipe works in pipe mode.
>>>
>>> The "as" command is intended for compiler use; not only is it not
>>> an interactive assembler, it doesn't even have particularly good
>>> diagnostics for batch use. You have to know what you're doing.
>>
>> You're sort of making excuses for it.
>
> I'm just stating what I have always believed the requirements to be.
>
> In Unixes and the GNU Project, there has not been a focus on assembly
> language as a primary development language, with a great developer
> experience.
>
> That's pretty much a fact.
>
> The amount of material written in .s or .S files is very small.
>
>> My 'aa' assembler was also
>> designed mainly for machine-generated code, so it has very few frills.
>>
>> The syntax however is decent enough that I can use it for my inline
>> assembler too.
>
> GCC has great inline assembly.

well, that is a point of contention with me. I just said f* the inline
crap and created pure asm.

>
> You can reference C expressions, which
> are evaluated to registers that the register allocator chooses, which
> you can reference in your inline code in a symbolic way.
>
> You can also indicate that your code template has certain effects,
> so that the compiler is informed.
>
> I had a nice experience many years ago when I wrapped the MIPS
> "load-linked/store-conditional" primitives as separate inline code
> macros.
>
> When I used these macros to write a synchronization primitive, GCC
> optimized away an unnecessary instruction or two, due to the way they
> integrated together.
>

On 1/14/2024 2:58 PM, Keith Thompson wrote:
[...]
> I already mentioned that GNU as doesn't write machine code to the
> terminal. (I discussed problems that could occor *if it did*.) Did you
> miss that? I know you're seeing at least *some* of my posts.
>
> Yes, it writes its output to "a.out" by default, for historical reasons.
> It also has an option to specify the name of the output file -- an
> option that is almost always used in practice. Invoking the "as"
> command directly is relatively rare.

Rare until you have to use it. Fwiw, keep in mind that this was well
before C++11. Take the sensitive sync algorithms (compiler reordering's,
ect...) out of the realm of C/C++ and code them up using assembly
language. The declarations can be in C with CDECL ABI.

[...]

On 1/14/2024 5:05 PM, Kaz Kylheku wrote:
> On 2024-01-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> bart <bc@freeuk.com> writes:
>>> On 14/01/2024 17:22, Tim Rentsch wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 12/01/2024 19:15, Scott Lurndal wrote:
>>>> [...]
>>>>>> What the FM documents. RTFM.
>>>>>
>>>>> I see. So forget just having intuitive behaviour. [...]
>>>> The problem is not what the behavior is. The problem is
>>>> with your intuition about what the behavior should be.
>>>
>>> I would love to know what behaviour of an assembler is intuitive to /you/.
>>>
>>> Or anybody.
>>>
>>> I would be surprised if that involved the brain-dead behaviour of
>>> either naming every output 'a.out', so overwriting the file created 5
>>> seconds previously, or spewing reams of binary code to a text terminal
>>> sensitive to escape codes.
>>
>> I already mentioned that GNU as doesn't write machine code to the
>> terminal. (I discussed problems that could occor *if it did*.) Did you
>> miss that? I know you're seeing at least *some* of my posts.
>>
>> Yes, it writes its output to "a.out" by default, for historical reasons.
>> It also has an option to specify the name of the output file -- an
>> option that is almost always used in practice. Invoking the "as"
>> command directly is relatively rare.
>
> Invoking the as command directly is not just rare, it's a poor
> which invites causing problems for someone who tries to cross-compile
> your program.
[...]

Luckily I only had to port my asm to Intel and SUN's architectures,
well, I had some PPC as well... So, using it was not poor to me. I had
to because it dealt with sensitive sync algorithms. I did not trust
existing C/C++ compilers. Then C++11 came out, and well... I started
porting my asm to it, standard.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 1/14/2024 2:58 PM, Keith Thompson wrote:
> [...]
>> I already mentioned that GNU as doesn't write machine code to the
>> terminal. (I discussed problems that could occor *if it did*.) Did you
>> miss that? I know you're seeing at least *some* of my posts.
>> Yes, it writes its output to "a.out" by default, for historical
>> reasons.
>> It also has an option to specify the name of the output file -- an
>> option that is almost always used in practice. Invoking the "as"
>> command directly is relatively rare.
>
> Rare until you have to use it.

And still rare after you have to use it. Are you using the word "rare"
in some non-standard sense?

> Fwiw, keep in mind that this was well
> before C++11. Take the sensitive sync algorithms (compiler
> reordering's, ect...) out of the realm of C/C++ and code them up using
> assembly language. The declarations can be in C with CDECL ABI.

How is any of that relevant? Are you saying that invoking the "as"
command directly *isn't* relatively rare?

Even if you needed to invoke "as" directly (and not, for example, via
"gcc"), it's still trivial to tell it the names of the input and output
files. I just typed "as hello.s -o hello.o" on my system, and it worked
just fine. And "gcc -c hello.s" did essentially the same thing.

--
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 1/14/2024 9:47 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 1/14/2024 2:58 PM, Keith Thompson wrote:
>> [...]
>>> I already mentioned that GNU as doesn't write machine code to the
>>> terminal. (I discussed problems that could occor *if it did*.) Did you
>>> miss that? I know you're seeing at least *some* of my posts.
>>> Yes, it writes its output to "a.out" by default, for historical
>>> reasons.
>>> It also has an option to specify the name of the output file -- an
>>> option that is almost always used in practice. Invoking the "as"
>>> command directly is relatively rare.
>>
>> Rare until you have to use it.
>
> And still rare after you have to use it. Are you using the word "rare"
> in some non-standard sense?
>
>> Fwiw, keep in mind that this was well
>> before C++11. Take the sensitive sync algorithms (compiler
>> reordering's, ect...) out of the realm of C/C++ and code them up using
>> assembly language. The declarations can be in C with CDECL ABI.
>
> How is any of that relevant? Are you saying that invoking the "as"
> command directly *isn't* relatively rare?

I am saying that I had to create my own sync primitives in pure assembly
language back them. So, I would use as to assemble them. No problem.
Nothing strange, just that I had to do it. Whether or not that is rare,
well, that's another story? The commands were in a makefile anyway. Is
that rare?

> Even if you needed to invoke "as" directly (and not, for example, via
> "gcc"), it's still trivial to tell it the names of the input and output
> files. I just typed "as hello.s -o hello.o" on my system, and it worked
> just fine. And "gcc -c hello.s" did essentially the same thing.

Well, I used as directly. Just like with MASM. That is rare? ;^)

On 2024-01-15, bart <bc@freeuk.com> wrote:
> On 15/01/2024 00:34, Kaz Kylheku wrote:
>> In Unixes and the GNU Project, there has not been a focus on assembly
>> language as a primary development language, with a great developer
>> experience.
>>
>> That's pretty much a fact.
>
> That is extraordinary. Wasn't C first implemented in assembly? It's

No; C would have been implemented in NB (new B). It was B that was
implemented in assembly. That's just bootstrapping, though.

Thompson and Ritchie didn't have a nice assembler; IIRC, they started
out by assembling code using macros in the TECO editor.

Assembly language has never been emphasized in Unix, to my best
knowledge. It's there.

> always been a mainstay of computing as far as I can remember. Except no
> one now write whole apps in assembly. (I've done quite a few in the past.)

I did a bunch of assembly language programming, which was with
"nice" assemblers. At university, I made a linked list library with
numerous functions on a Sun 3 (68K) using Sun's "as". That was my
first encounter with Unix's idea of assembly. I got it done, but it
was pretty horrible, with next to no diagnostics when there was
something wrong. It was obvious that the tool assumes correct input,
coming from a compiler.

>>> My 'aa' assembler was also
>>> designed mainly for machine-generated code, so it has very few frills.
>>>
>>> The syntax however is decent enough that I can use it for my inline
>>> assembler too.
>>
>> GCC has great inline assembly.
>
>> You can reference C expressions, which
>> are evaluated to registers that the register allocator chooses, which
>> you can reference in your inline code in a symbolic way.
>
> GCC inline assembly looks absolutely diabolic. I take it you've never
> seen it done properly?
>
> Actually I spent 5-10 minutes looking for examples, to try and figure
> out if asm instructions could in fact directly refer to symbols in the HLL.
>
> But most examples were one or two lines of weird syntax, following by
> some interfacing code. So I don't know.
>
> If /I/ had to write extensive programs in gcc inline assembly, then put
> a gun to my head now!
>
> Take this example in C:
>
> int a;
>
> void F(void) {
> int b=2, c=3;
> static int d=4;
>
> a = b + c * d;
> }
>
> I will now show it in my language but with that assignment replaced by
> inline assembly:
>
> int a
>
> proc F=
> int b:=2, c:=3
> static int d=4
>
> assem
> mov rax, [c] # (note my ints are 64 bits)
> imul2 rax, [d]
> add rax, [b]
> mov [a], rax
> end

Problem is that the compiler's register allocator now has to be informed that
the assembly language part is using rax and work around it.

> end
>
> My question is: what would the C version look like with that line in gcc
> inline assembly? (In both cases, 'a' should end up with the value 14.)

Let's make it more interesting: what if b and c come from arguments,
and the static int d actually has state that changes between
invocations, so it can't be optimized away. Let's return the
result, a:

int F(int b, int c)
{ static int d=4;
int a;

d++;

asm("imul %3, %2\n\t"
"add %2, %1\n\t"
"mov %1, %0\n\t"
: "=r" (a)
: "r" (b), "r" (c), "r" (d));

return a;
}

It's pretty arcane in that the material is both in string literals,
and not. The assembly language template is textual; the compiler knows
nothing about its interior.

I specified one output operand, and three input operands, requesting
that they be in registers. I don't specify the register identities.
They are referenced by number: %0, %1, %2, %3 in the order they
appear. (A way to use named references exists.)

We don't have to code the data transfers between the registers
and the C operands they are connected to; that is done for us
by the compiler.

So, okay, unoptimized that looks like:

$ gcc -c inline.c
$ objdump -d inline.o

inline.o: file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <F>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 89 7d ec mov %edi,-0x14(%rbp)
7: 89 75 e8 mov %esi,-0x18(%rbp)
a: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 10 <F+0x10>
10: 83 c0 01 add $0x1,%eax
13: 89 05 00 00 00 00 mov %eax,0x0(%rip) # 19 <F+0x19>
19: 8b 0d 00 00 00 00 mov 0x0(%rip),%ecx # 1f <F+0x1f>
1f: 8b 45 ec mov -0x14(%rbp),%eax
22: 8b 55 e8 mov -0x18(%rbp),%edx
25: 0f af d1 imul %ecx,%edx
28: 01 d0 add %edx,%eax
2a: 89 c0 mov %eax,%eax
2c: 89 45 fc mov %eax,-0x4(%rbp)
2f: 8b 45 fc mov -0x4(%rbp),%eax
32: c9 leaveq
33: c3 retq

Optimized:

$ gcc -O2 -c inline.c
$ objdump -d inline.o

inline.o: file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <F>:
0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 <F+0x6>
6: 83 c0 01 add $0x1,%eax
9: 89 05 00 00 00 00 mov %eax,0x0(%rip) # f <F+0xf>
f: 0f af f0 imul %eax,%esi
12: 01 f7 add %esi,%edi
14: 89 f8 mov %edi,%eax
16: c3 retq

The static variable is accessed relative to the instruction pointer.
The offset is all zeros: that will be patched when this is linked.

Note that between the unoptimized and optimized code, the register
identities changed entirely.

GCC's inline assembly feature is largely agnostic of the assembler
back end. It interfaces with register allocation and such, but is
otherwise generic. This allows it to have exactly the same grammar,
no matter the architecture target.

The syntax isn't particularly nice, but it has power.

> You need to tell me, because I will otherwise not have a clue. From what
> I've seen of gcc inline asm:
>
> * Code has to be written within string literals, in dreadfil AT&T
> syntax. And apparently even with embedded \n line breaks. (Good
> grief - I think early 80s BASICs had more sophisticated facilities!)

The code template, after the registers like %0 and %1 are substituted
into it, is just shoved into the assembly language output verbatim.

The compiler doesn't analyze the interior.

AT&T syntax is used if that's what the assembler requires.

Not all GCC targets have assemblers in whose language the destination operand
is on the right; it's that way for the x86 family though.
>
> * You mostly use offsets to get at local variables

Nope; it's pretty much transparent.

> * You apparently aren't allowed to use just any registers as you need
> to negotiate with gcc so as not to interfere with /its/ use of
> registers. So most examples I saw seemed to deal with this.

This is pretty awesome.

> I consider that when writing assembly, YOU are in charge not the
> compiler.

If you're writing *inline* assembly in compiled code, if you let
the compiler be in charge of some things, it's a lot better.

If specific registers are required, that can be arranged. Sometimes that
happens: some instruction sets have certain instructions that only work with
certain registers, as you know.

If you're not working with instructions like that, it's beneficial if
the compiler allocates them for you. That nicely integrates into the
register allocation.

> As you can see from mine:
>
> * It is written just as it would be in an actual ASM file

It is nice for editing and all, and you were cranking out hundreds
of lines of assembly, or even dozens, you'd want that.

But mainly the code exists to do a job, not to be admired.

> * You can refer to variables directly (the compiler will add what is
> needed to access locals or statics)
>
> If a function uses inline ASM, variables are kept in memory not
> registers. (I might allow that at some point.) Most such functions
> however contain only ASM.

As you can see, this is not a limitation in the GNU inline assembly.
The optimized code did away with memory references, except for the
static int d.

On 1/14/2024 11:07 PM, Kaz Kylheku wrote:
> On 2024-01-15, bart <bc@freeuk.com> wrote:
>> On 15/01/2024 00:34, Kaz Kylheku wrote:
[...]
> GNU inline assembly is ugly, but it's very well designed semantically;
> it hits the target.

I did not like it very much, made my eyes want to bleed. Iirc, Microsoft
got rid of inline assembly for 64-bit targets, cannot remember when.

>
> When you have to do something in assembly language, it is fluid;
> you don't have to contend with an overly ridid instruction template that
> interferes with surrounding optimization.

On 2024-01-15, Kaz Kylheku <433-929-6894@kylheku.com> wrote:
> On 2024-01-15, bart <bc@freeuk.com> wrote:
>> On 15/01/2024 00:34, Kaz Kylheku wrote:
>>> In Unixes and the GNU Project, there has not been a focus on assembly
>>> language as a primary development language, with a great developer
>>> experience.
>>>
>>> That's pretty much a fact.
>>
>> That is extraordinary. Wasn't C first implemented in assembly? It's
>
> No; C would have been implemented in NB (new B). It was B that was
> implemented in assembly. That's just bootstrapping, though.
>
> Thompson and Ritchie didn't have a nice assembler; IIRC, they started
> out by assembling code using macros in the TECO editor.
>
> Assembly language has never been emphasized in Unix, to my best
> knowledge. It's there.
>
>> always been a mainstay of computing as far as I can remember. Except no
>> one now write whole apps in assembly. (I've done quite a few in the past.)
>
> I did a bunch of assembly language programming, which was with
> "nice" assemblers. At university, I made a linked list library with
> numerous functions on a Sun 3 (68K) using Sun's "as". That was my
> first encounter with Unix's idea of assembly. I got it done, but it
> was pretty horrible, with next to no diagnostics when there was
> something wrong. It was obvious that the tool assumes correct input,
> coming from a compiler.
>
>>>> My 'aa' assembler was also
>>>> designed mainly for machine-generated code, so it has very few frills.
>>>>
>>>> The syntax however is decent enough that I can use it for my inline
>>>> assembler too.
>>>
>>> GCC has great inline assembly.
>>
>>> You can reference C expressions, which
>>> are evaluated to registers that the register allocator chooses, which
>>> you can reference in your inline code in a symbolic way.
>>
>> GCC inline assembly looks absolutely diabolic. I take it you've never
>> seen it done properly?
>>
>> Actually I spent 5-10 minutes looking for examples, to try and figure
>> out if asm instructions could in fact directly refer to symbols in the HLL.
>>
>> But most examples were one or two lines of weird syntax, following by
>> some interfacing code. So I don't know.
>>
>> If /I/ had to write extensive programs in gcc inline assembly, then put
>> a gun to my head now!
>>
>> Take this example in C:
>>
>> int a;
>>
>> void F(void) {
>> int b=2, c=3;
>> static int d=4;
>>
>> a = b + c * d;
>> }
>>
>> I will now show it in my language but with that assignment replaced by
>> inline assembly:
>>
>> int a
>>
>> proc F=
>> int b:=2, c:=3
>> static int d=4
>>
>> assem
>> mov rax, [c] # (note my ints are 64 bits)
>> imul2 rax, [d]
>> add rax, [b]
>> mov [a], rax
>> end
>
> Problem is that the compiler's register allocator now has to be informed that
> the assembly language part is using rax and work around it.
>
>> end
>>
>> My question is: what would the C version look like with that line in gcc
>> inline assembly? (In both cases, 'a' should end up with the value 14.)
>
> Let's make it more interesting: what if b and c come from arguments,
> and the static int d actually has state that changes between
> invocations, so it can't be optimized away. Let's return the
> result, a:
>
> int F(int b, int c)
> {
> static int d=4;
> int a;
>
> d++;
>
> asm("imul %3, %2\n\t"
> "add %2, %1\n\t"
> "mov %1, %0\n\t"
> : "=r" (a)
> : "r" (b), "r" (c), "r" (d));
>
> return a;
> }

We can also turn this multiply and add into a stand-alone primitive
that we can put behind a macro:

#define mul_add(x, y, z) \
({ int _res; \
asm("imul %3, %2\n\t" \
"add %2, %1\n\t" \
"mov %1, %0\n\t" \
: "=r" (_res) \
: "r" (x), "r" (y), "r" (z)); \
_res; })

Which we then freely use like this:

int F(int b, int c)
{ static int d=4;
int a;

d++;

a = mul_add(b, c, d);

return a;
}

Complex example:

int G(int a, int b, int c, int d, int e, int f, int g, int h, int i)
{ return mul_add(mul_add(a, b, c),
mul_add(d, mul_add(e, f, g), h),
i);
}

gcc -O2 code:

0000000000000020 <G>:
20: 0f af f2 imul %edx,%esi
23: 01 f7 add %esi,%edi
25: 89 ff mov %edi,%edi
27: 8b 44 24 08 mov 0x8(%rsp),%eax
2b: 8b 54 24 10 mov 0x10(%rsp),%edx
2f: 44 0f af c8 imul %eax,%r9d
33: 45 01 c8 add %r9d,%r8d
36: 44 89 c0 mov %r8d,%eax
39: 0f af c2 imul %edx,%eax
3c: 01 c1 add %eax,%ecx
3e: 89 c9 mov %ecx,%ecx
40: 8b 44 24 18 mov 0x18(%rsp),%eax
44: 0f af c8 imul %eax,%ecx
47: 01 cf add %ecx,%edi
49: 89 f8 mov %edi,%eax
4b: c3 retq

GCC inline assembly is good if you have certain instructions that the compiler
doesn't use, and you'd like to use them as first class primitives (meaning that
they are not disadvantaged compared to primitives the compiler knows about).

We would likely obtain better code if if we unbundled the multiplication
and addition by writing separate mul and add primitives.

Because the code above has to follow the rigid template where imul
is immediately followed by the related add, after which there is
a mandatory mov.

We really want:

#define mul_add(x, y, z) add(x, mul(y, z))

where we separately write the add and mul as inline assembly fragments.

A mul_add primitive might make sense if the processor had such a thing
in one instruction.

With GCC inline assembly, you want to only put the essentials into it:
only do what is necessary and only bundle together what must be
bundled.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

bart <bc@freeuk.com> writes:

[snip]
>> I'm new here, so please forgive my ignorance. What's yours?
>> I suppose what I'm asking is: What exactly is your goal here, Bart?
>
> What is anyone's goal here?
>
> This newsgroup is just a bunch of old-timers who mainly discuss the
> finer points of the C standard, although the group has been more or
> less dead for the past couple of years.

Hello there, everyone, this is actually my first post on Usenet at
all. I started configuring and reading it like two days ago. It is not
really a test since I'd like to reply to some content here. This group
seems rather lively, I guess it is partly thanks to you, Bart.

> Since there are rarely any people who post about any practical
> problems, I think they mainly use stackoverflow and reddit for
> that. The regulars mainly just argue amongst themselves.

I'm kind of young and getting into programming, in C mainly, because I
like backend stuff in general. I dislike going to stackoverflow or
reddit. I reckon these are useful platforms but not open to free
discussion like it is the case here in Usenet. So this newsgroup is not
dead and I find it still useful.

> I'm somewhat of an outsider and I like to point out things that I
> believe are wrong in things like the C language and the assorted
> collection of Unix-specific tools that apparently go with it.
>
> I'm an outsider because I don't routinely use C, or any of the tools,
> and because I don't have background in Unix-based development. I have
> a different perspective.

This may get on the nerve of some people. But it is interesting. Like
when you made a point about the redirection (>) of binary output to
stdout, the people that corrected your assumption of this operator
teached me a lot about how the redirection of stdin works.

> So, what happens here is that I mention something that might be some
> bizarre quirk of C, or some weird, unfriendly way some tool works, or
> anything that goes against common-sense or intuition, or that I find
> has caused me grief.
>
> And then the regulars, instead of agreeing, go on the defensive. Some
> go on the attack, saying I'm the one at fault, I should RTFM, or do
> this or that, or that I'm ignorant, etc etc. (You've seen the thread.)
>
> So since I have nothing better to do**, I like to defend myself. And
> sometimes it is fascinating seeing people defend the indefendable.

If I recall the ongoing thread, there was two "indefendable" statements:
a) make is useless and cryptic
b) gcc's outputing of binaries to a.out by default is useless and
cryptic

Since *a* has been explained already. I'll just give my two cents on
*b*.
When I'm learning to program, I use to have a lot of source files in the
same repository. I don't want't the binaries, I just want to play with
the source and sometimes, compile them and see if they compile correctly
and the behavior is correct. Outputting the binary to a.out by default
instead of "hello.o" is sort of useful here. For two reasons :
1. I don't have the overhaul of remembering how did I call that source
file in that particular moment when I wrote it. I know I have to call
../a.out and that's it.
2. It doesn't crowds my directory with lots of useless binaries.

> All people need to do is be honest.

I agree.

> Does that answer your question?
>
> (** That's not quite true, this is taking me away from my current
> project. But when people openly insult me, I can't let it go. They
> need to stop replying.)

You are then on a long quest. Good luck.

On 15/01/2024 08:51, Gabriel Rolland wrote:
> bart <bc@freeuk.com> writes:

> If I recall the ongoing thread, there was two "indefendable" statements:

OK, whatever the actual spelling of 'indefendable' might be...

> a) make is useless and cryptic

My 'C and Make' thread showed a clear example of it being used
gratuitously. I contend that that happens a lot.

> b) gcc's outputing of binaries to a.out by default is useless and
> cryptic
>
> Since *a* has been explained already. I'll just give my two cents on
> *b*.
> When I'm learning to program, I use to have a lot of source files in the
> same repository. I don't want't the binaries, I just want to play with
> the source and sometimes, compile them and see if they compile correctly
> and the behavior is correct. Outputting the binary to a.out by default
> instead of "hello.o" is sort of useful here. For two reasons :
> 1. I don't have the overhaul of remembering how did I call that source
> file in that particular moment when I wrote it. I know I have to call
> ./a.out

Hang on: are you generating 'a.out' the object file, or 'a.out' the
executable file? (Because ./a.out will execute the file.)

Here is where Unix/Linux's treatment of file extensions does my head in.
'a.out' is used there for both kinds of file. To find out what it
actually is, you have to look inside the file, which defeats the purpose
of having a file extension at all.

> and that's it.
> 2. It doesn't crowds my directory with lots of useless binaries.

The problems of always having the same a.exe/a.out output (here it is
the executable file - see, I have to keep disambiguating!) are multiple:

* If you working with several small one-file programs c, d, and e say,
you want them compiled as c.exe, d.exe and e.exe. Having them all be
a.exe is not going to work; which of c, d, e does it correspond to?
Suppose you want to run c, d, e one after the other?

* You might be testing (as I do), multiple compilers on the same c.c.
The first produces c.exe; you test it. Compile with the second to make a
new c.exe; you test that. Compile with gcc to make a new ... a.exe. Now
you have to remember it's a different executable.

(The number of times I've forgotten that and run c.exe instead, and
thought gcc's code wasn't quite as fast as I'd expected...).

* You compile a big program one.c which takes a long time. You then
compiled another program two.c, which you now realise has overwritten
the a.exe that represented one.c.

The answer isn't to use '-o c.exe' either. In both cases gcc is out of
kilter with the other compilers; it will eiher produce the wrong EXE, or
you need extra options that the others don't.

OK, I replied at more length than I intended. I really feel these small
matters in such tools are important. Others gloss over them:

* "You never run gcc directly; use make!"

* "Write a wrapper script or program around gcc"

* "You spent more time complaining about it then you'd have spent just
typing '-oprog.exe!"

And so on. The trouble is if you post, on a forum, some C code with a
brief note of how it should be built, you can't assume somebody has the
same wrapper, and you don't want to also post a make script, but you
have to add these stupid extra options each time.

I could suggest for example that, if 'gcc prog.c' always generated
'prog', that you instead used:

gcc prog.c -oa.out

if you don't want the proliferation of binaries. But I guess you
wouldn't want that extra hassle.

On 12/01/2024 18:09, bart wrote:
> On 12/01/2024 16:34, David Brown wrote:
>> On 12/01/2024 17:12, bart wrote:
>
>> I don't really understand what you are trying to say here.  Are you
>> suggesting that your 40 year old DOS IDE is equivalent to modern IDE's ?
>
> No. Only that the way I normally work hasn't changed a great deal.
>

OK. Some of us have learned to take advantage of new technology, new
possibilities, new software, new ideas, new tools. We use old tools in
new ways, new tools in old ways - whatever gives a more pleasant and
productive environment, with the best quality results.

>> Are you trying to say you can use your own tools for your own
>> language, and rely on a simple script for C compilation, and can't
>> handle anything else in a build process?
>
> I'm separating the fundamental build-process for a program from what is
> needed for interactive development and testing.
>

Fair enough. These are different tasks. For source code that must be
distributed in buildable form (and the huge majority of source code
written is /not/ distributed), you need a build tool geared at working
on a wide variety of systems, supporting different compilers and OS's,
and ensuring that the correct flags and details are in place. Makefiles
can be a good way to hold this, but for support of a bigger variety of
systems, autoconfig has been a very successful (if heavy-handed)
solution that works across many dozens of systems. A more modern tool
that is simpler in use and works better for common modern systems
(including Windows) is CMake.

For development purposes, your tools are aimed at efficient development
and getting the most help possible from the tools in identifying and
fixing errors. So there you choose your compiler specifically as
something with a lot of warnings and other static checking, and you use
a build system that minimising build time and helps keep track of the
options you need. Make is the obvious choice that works well for many
uses - beyond that, you want integrated build and test systems,
continuous build systems, and that kind of thing.

So while "make" is neither necessary nor sufficient for all situations,
it provides a very versatile tool that can cover a great deal of
situations. If you want one tool that is good enough for a wide range
of uses, "make" is the one to use. It will be overkill for some cases,
and for other cases it might need a makefile generator like CMake or
Meson (or an IDE), but overall it works great for many things. That's
why it is so popular, and the standard build tool for such a high
proportion of projects.

> Makefiles you see supplied with open source projects don't generally
> make that distinction.

Why should they? An optimal deployment build makefile is likely to be
different from an optimal development build makefile. But should the
open source developers make that effort? For a big project that is used
across a wide range of systems, targeting automatic builds by
non-developers, the answer is probably yes. For a smaller project,
where people interested in the source code are expected to be competent
C or C++ developers, why should they go out of their way to spoonfeed
newbies or people who have allergies to standard tools? If the project
targets Windows specifically, perhaps they will provide CMake files or
even MSVC project files. If the main development platform, and the main
target, is *nix, then why should you complain that their build system
targets that? If you don't like it, ask for your money back.

>
> But I can see you're struggling with the concept of simplicity.
>

Simple solutions are fine for simple problems. A hammer is a simple
tool, but it's not much use for screws. I like a toolbox - I have
several simple tools, like hammers and screwdrivers. And I have a few
complex tools, like an electric drill with interchangeable bits, and a
few very niche tools for odd uses (like these special bits for removing
broken screws).

You live in your own little world, where everything is nailed together,
and a hammer is all you need. That's great for /you/, but stop getting
your knickers in a twist just because the rest of the world is different.

>
>>>> download to a target board via a debugger,
>
> (Hey, I used to do that! Not a makefile in sight either; how is that
> possible?
>

Grow up.

> I used to do that with no special tools, no external software and no
> external languages. I had to write assemblers for any new devices I has
> to use.)
>

Yes, I've heard it before. If you wanted a keyboard, you had to carve
it out of a rock with your teeth.

When I learned assembly, I assembled code to hex by hand. On paper. I
don't consider that particularly relevant to my work today.

>
>>>> and all sorts of other bits and pieces according to the needs of the
>>>> project.  One makefile beats a dozen scripts.
>>>
>>> It looks like 'make' is competing with 'bash' then!
>>>
>>
>> I have no idea why you think that - except perhaps because you still
>> have no concept of what "make" is and what it does, and think it is
>> just a script with a complicated syntax.
>
> So, what the hell is it then? What makes it so special compared with any
> other scripting language?

You've answered part of that yourself below!

>
> All I can see is that it can create dependency graphs between files -
> which have to be determined from info that you provide in the file, it's
> not that clever - and can use that to avoid recompilation etc of a file
> unless its dependencies have changed.
>

Make coordinates builds. As you say, it creates DAG graphs for the
tasks needed for the build, based on rules that the user can control.
This means that the user does not have to provide details for everything
- make works out a lot from those rules.

It does, however, need to be told which targets you want to build, and
what their dependencies are. This can be done manually, or using make's
features, or in combination with other tools such as gcc's support for
generating dependency files, or by using makefile generators (like
CMake). Simple makefiles for small projects often list dependencies
manually, more complex makefiles for bigger projects have more scalable
and easy to use solutions. For most of my projects, make (with gcc)
figure out all the required C and C++ files, and all the right
dependencies, automatically. Once it is set up, I don't change the
makefile even when adding or removing source files.

Oh, and make does all this with support for parallel builds - keeping
track of multiple jobs, including tools that themselves use multiple cpu
cores at a time.

> That is something I've never needed done automatically in my own work (I
> do it manually as I will know my projects intimately when I'm working
> with them).

Some developers work on lots of projects. Some projects have lots of
developers working on them. Again, your methods are suited only to your
own little world, not to other people.

>>> If you're curious about what 'as' expects and speculatively try 'as
>>> --help', it displays 167 dense lines.
>>>
>>
>> Are you trying to convince people that your assembler is better than
>> gas because yours has fewer features?  Bizarre.
>
> It's simpler and gives a simple summary of how it works.

Don't you document your tools?

>
> Clearly your idea of 'better' is to be vastly more complicated.

My idea of "better" varies by context - it isn't as overly simplified as
you seem to think. In your little world, "better" means "does what Bart
wants at the moment - no one else matters". In the real world, tools
are written for other people - "better" means it does what /they/ want,
in the full knowledge that people want different things.

>
> I guess an assembler which will only work for the processor you happen
> to be working with is no good at all. It has to also support dozens that
> are not relevant to the task in hand.

Yes.

Because that means I get well-tested tools used by huge numbers of
people, with lots of support, lots of features, and lots of versatility.
And I get them for free, or for low cost - vastly cheaper than if they
were written specifically for /me/. It doesn't matter if it also
supports features I don't need, languages I don't need, targets I don't
need. It matters that they support the features I need, the languages I
need, the targets I need. And it is a huge bonus that when I want to
use a new feature, or language, or target, it's already there.

I've had my share of target-specific tools. I've dealt with different
compilers for each target, each with their own idiosyncrasies,
limitations, extra features, etc. I've written more than my fair share
of Keil-C and Imagecraft-C and other code that has to be fine-tuned for
a specific compiler and target. I've used a dozen assemblers, all with
their own way of handling directives and other bits and pieces. With
gcc and binutils, I have /one/ toolchain base that I have used for
perhaps 8 different targets - it was an enormous step forward. I don't
care if it also supports another dozen targets - maybe I'll use some of
them in the future too.

On 12/01/2024 22:01, bart wrote:
> On 12/01/2024 18:02, Janis Papanagnou wrote:
>> On 12.01.2024 18:09, bart wrote:
>>> On 12/01/2024 16:34, David Brown wrote:
>>>>>
>>>>> It looks like 'make' is competing with 'bash' then!
>>
>> Why don't you just read about those two tools and learn, instead
>> of repeatedly spouting such stupid statements of ignorance.
>
> Because I've repeatedly said I don't need them. Why can't you accept that?
>

You've told us. We believe you. You live in a small, limited little
world where you can get by with the tools you make yourself and don't
have to interact with other developers or other software. By
definition, your tools do all you need - if you want a new feature, you
add it to the tool. And they don't do more than you personally need.

If you are happy like that, great. (You are apparently not particularly
happy about all of this, based on your posts, which is a shame.)

But /please/ stop complaining when other people do things differently.
/You/ are the odd one out here. You alone. Your methods might be
better for /you/, for your own very limited and specific needs - they
are not suitable for the rest of the world.

No one is forcing you to use make, or C, or Linux, or anything else that
triggers you. If you /want/ to use these things, and want to ask for
help or advice, that's fine - as long as you do so in good faith and try
to learn from the answers. But all you seem to want to do is fight and
argue, making a fool of yourself in your wilful ignorance. That's not
particularly good for anyone.

On 13/01/2024 23:39, bart wrote:
> On 13/01/2024 21:42, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 13/01/2024 04:17, Kaz Kylheku wrote:
>>>> On 2024-01-13, bart <bc@freeuk.com> wrote:
>> [...]
>> It's true that some languages don't need "make" as much as C does.
>>
>> Nobody here has said otherwise, likely because other languages are
>> largely off-topic here in comp.lang.c.
>
> Except 'make'? I get the impression that most programs written in C have
> a large component written in 'make' too. A component you can't always
> ignore since essential build info is encoded in it.
>
Can you remember a single thread in this newsgroup, over the last decade
or so, that was about "make" and was not dominated by /you/ ranting
about how you hate make?

Other people might mention "make" in passing, just as they might mention
gcc or clang or msvc, as a tool that is often used in connection with C
programming. There's no more than that - once your rants are filtered out.