On 14/01/2024 01:36, bart wrote:
> On 13/01/2024 23:26, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> 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:
>>>> [...]
>>>>>>> That's a reasonable thing to do. But how does make do it? Can't a
>>>>>>> compiler apply the same approach if N files have been submitted?
>>>>>> Yes. And in fact, languages with good module support like Modula-2
>>>>>> don't need external make utilities.
>>>>>
>>>>> Finally somebody admitting that some languages may not need make as
>>>>> much.
>>>> Bart, seriously, what the hell are you talking about?
>>>> 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.
>>
>> Most?  I don't know.  Many?  Sure.
>>
>> You wrote, "Finally somebody admitting that some languages may not need
>> make as much.".  Has anyone here claimed otherwise?  If not, why do you
>> find Kaz's statement so remarkable?
>
> People have suggested using make for everything, from hello.c up to JP's
> and SL's massive applications.

Do you think that any one person here speaks for everyone? /I/ have
written that I find "make" to be a useful tool for all kinds of things,
not just C projects. (I never suggested I use it for "everything",
however.) But that's /me/, and the way /I/ like to work - it's a
convenient tool, and it is in no way C-specific. For some other things,
however, I don't find it useful so I don't use it. I rarely need it in
combination with Python projects (although I have used it for some
aspects of some Python projects). I didn't use it with Delphi.
Sometimes I do, technically, use "make", but it is hidden behind an IDE.

Writing that someone is "admitting" that there are languages that may
not need make suggests you think there is some grand conspiracy here -
that the entire newsgroup is in denial and hiding things. That is
complete nonsense - pure paranoia. No one has even hinted at anything
of the sort.

It would be helpful if you did not make all these crazy exaggerations
and extrapolations. Maybe you'd find that, if you simply calmed down,
the world is /not/ all against you and everything you say.

On 15/01/2024 09:51, Gabriel Rolland wrote:
> 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.

Welcome to the group - and as a new C programmer!

We don't /just/ discuss the finer points of the C standards, but that is
definitely something we do cover, and you'll be hard pushed to find a
discussion forum with more standards experts than you find here. We are
happy to discuss all kinds of aspects of C programming, but if you need
platform-specific help or help with particular libraries, it's not often
a good place - but we might be able to suggest alternatives.

It's worth starting a new thread if you have something specific - a lot
of people will already have marked this thread as pointless and ignored!

> This group
> seems rather lively, I guess it is partly thanks to you, Bart.

Oh, Bart does not lack in enthusiasm and energy for his postings :-) He
is, however, often confusingly inaccurate about C. Ask some questions,
and you'll quickly see which regulars give answers that work for your
needs (some are better at getting the exact details right, others are
better at explaining in layman's terms).

>
>> 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.

They say the best way to get help on the internet is not by asking a
question, but by posting a wrong answer and waiting to be corrected.
Bart has tried this a lot, but he is not good at listening to the
corrections.

Unsurprisingly for a newsgroup titled "comp.lang.c", most people here
use C a lot, or have used it a lot in the past, and most people here are
interested in the language. Bart is an outsider in that sense. Most of
us also use one or more different languages for various purposes. Many
of us use *nix systems (typically, but not always, Linux) rather than
Windows or Macs - unless you are doing Windows or Mac specific
development, *nix is generally considered more developer friendly. But
it's far from an exclusive rule.

>
>> 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.

It is fascinating to see how Bart defends himself against imaginary
attacks, tilting at windmills. When Bart finds something he doesn't
like about C (and he finds a /lot/ that he doesn't like), he is unable
to distinguish between replies that say "I don't like it either, but I
can live with it", or "It is this way because of ...", or "Some people
/do/ like it", or "You have misunderstood - the feature works like
this...". In Bart's mind, any reply gets read as "We all love
everything about C and its a perfect language". This often leads to
unproductive threads, such as this one.

>
> 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.
>

A tool that you might find useful when playing around is
<https://godbolt.org>. It is an online compiler. In particular, it
makes it extremely easy to test bits of code with a variety of
compilers, and any command line options you like, and look at the
generated assembly. (You can also run the program, but I personally
find looking at the assembly more useful.)

>> All people need to do is be honest.
>
> I agree.

I think most of us do.

>
>> 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 12:39, bart wrote:
> 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.

*nix does not make heavy use of file extensions (as you know). You can
use the "file" command to see what kind of file you have (as you also
know, as you've been told before). Sometimes file extensions are
helpful, such as for distinguishing different source code languages.

If you ask gcc to compile but not link a file, such as "gcc -c hello.c",
the default output will be an object file named "hello.o".

If you ask gcc to compile and link, such as "gcc hello.c", the default
output will be an executable called "a.out". (It is in "elf" format -
long ago, the default executable format was called "a.out".)

>
>> 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?

If that's a problem, write "gcc -o d.exe d.c" to get an executable named
"d.exe" (even on Linux). Or write "make d", to compile and link "d.c"
into an executable called "d".

>
> * 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...).
>

I think I see a common factor running through all these problems you are
having...

On 15/01/2024 07:37, Chris M. Thomasson wrote:
> 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?
>

It is a /long/ time since I have found any point in writing pure
assembly files. I do sometimes need to write assembly code - but
writing it as gcc inline assembly makes it far easier because the
compiler handles all the mess of register allocation and otherwise
getting optimal integration with C (or C++).

It also seems a bit odd to use non-portable assembly to implement sync
primitives equivalent to those later standardised in C11/C++11. gcc has
had builtin functions for atomic accesses for decades (C11/C++ merely
changed the spellings and standardised them), and higher level features
like mutexes are provided by the OS.

Still, you use the tools you like, as you like to use them.

>> 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? ;^)

Yes.

On 15/01/2024 07:07, Kaz Kylheku wrote:
> On 2024-01-15, bart <bc@freeuk.com> wrote:

>>> GCC has great inline assembly.

>> 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.)

OK. I think you've just confirmed my worst fears about gcc inline assembly.

But you've also made it clear that this isn't really assembly at all. Is
it even for x64? I can't tell! The use of 'mov' rather than 'ldr' or
'str' suggests it is x86 or x64 rather than ARM. But are those 32-bit
mov's or 64-bit?

So it's some sort of hideous hybrid that gcc has come up with, that is
neither assembly nor C.

It figures that most examples I could find on-line were only a handful
of lines, often just one line, of actual instructions rather than
directives. My inline assembler doesn't have directives.

It would be far, far simpler to write assembly in its own file (and keep
well away from AT&T syntax), than to try and inline it. Which defeats
the purpose of it.

As for your revised example, I would write it like this (I'm using my
language, but no reason why that assem...end block can't be written the
same way within in C, using assem {...}, and without those ghastly strings):

func F(int b, c)int =
static int d=4
++d

assem
mov rax, [c]
imul2 rax, [d]
add rax, [b]
end
end

Exactly the same as before, except I don't need to explicitly write to
'a'. If a return value is expected in this context, then an assem block
is expected to set up that value in the right place.

Or I could even assign an assem block to variable:

a := assem mov rbx, [c]; imul2 rbx, [d]; add rbx, [b]; end

(I didn't know I could do this, but it seems to work.)

> 25: 0f af d1 imul %ecx,%edx
> 28: 01 d0 add %edx,%eax
> 2a: 89 c0 mov %eax,%eax

-----

> f: 0f af f0 imul %eax,%esi
> 12: 01 f7 add %esi,%edi
> 14: 89 f8 mov %edi,%eax

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

That is a back-end detail; it's not usually specified in the instructions.

> 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.

So it's some kind of HLA.

>> 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.

That's how I crudely did it at one time (though still using real
syntax). But it doesn't work when the output is binary code and not
assembly text.

> 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.

So can specify the variables direcly? As in, for example:

asm inc u32 [d] # one-liner form of my syntax

>> 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.

Then you'd write in the HLL. Having inline ASM already takes care of 80%
of the pain of writing pure assembly. In gcc inline, it /adds/ pain!

But I stated my compiler does take care of some details like adding the
frame-pointer into the address mode. That's means you don't need to keep
track of whether a variable is local, static or global.

Below is an example of a function that mostly HLL with some inline ASM.
This one does the job of LIBFFI (another needlessly hard to build
library), for Win64 ABI.

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

export function os_calldllfunction(
ref proc fnaddr,
int retcode, nargs,
ref[]u64 args,
ref[]byte argcodes)u64 =

u64 a
r64 x
int nextra := 0, pushedbytes

!Stack is 16-byte aligned at this point

if nargs<4 then
nextra := 4-nargs !need at least 4 slots for shadow space
elsif nargs.odd then !need one more for a 16-byte-aligned stack
nextra := 1
fi

pushedbytes:=(nextra+nargs)*8

to nextra do
asm push 0
od

for i := nargs downto 1 do
a := args[i] !get generic 64-bit value to push
asm push u64 [a]
od

! Blindly load first 4 args to both int/float regs, whether used or not,
! and assuming calling a variadic function whether it is or not

assem
mov D10, [Dstack]
movq XMM0, [Dstack]
mov D11, [Dstack+8]
movq XMM1, [Dstack+8]
mov D12, [Dstack+16]
movq XMM2, [Dstack+16]
mov D13, [Dstack+24]
movq XMM3, [Dstack+24]
end

if retcode='I' then
a := (ref func:int64(fnaddr))^()
asm add Dstack,[pushedbytes]
return a

else
x := (ref func:r64(fnaddr))^()
asm add Dstack,[pushedbytes]
return u64@(x) !(type-punning cast)

fi
end

(Uses alternate register naming.)

bart <bc@freeuk.com> writes:
>On 15/01/2024 07:07, Kaz Kylheku wrote:
>> On 2024-01-15, bart <bc@freeuk.com> wrote:

>>
>> 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;
>> }

>But you've also made it clear that this isn't really assembly at all. Is
>it even for x64? I can't tell! The use of 'mov' rather than 'ldr' or
>'str' suggests it is x86 or x64 rather than ARM. But are those 32-bit
>mov's or 64-bit?

1) it's not an assembler, it's a way to "patch" the assembler code
generated by the compiler.

>
>So it's some sort of hideous hybrid that gcc has come up with, that is
>neither assembly nor C.

Your baseless opinion noted. Feel free to submit a patch to
the GCC team to implement your preferred syntax for inline assembler.

Do ensure that it works for all 100 of the GCC target architectures.

>It would be far, far simpler to write assembly in its own file (and keep
>well away from AT&T syntax),

No, it would not be.

And the AT&T syntax is _far_ superior to the intel syntax
with all the ugly syntactic sugar.

val = tp->mem_read(psource, len);
rax = get_reg_value(regs, REG_RAX, QUAD);

__asm__ __volatile__ (
"testl $1, %1\n\t" // 1 byte operand?
"jne 1f\n\t" // Yes, go to it

"testl $8, %1\n\t" // Was it eight bytes?
"jne 2f\n\t" // Yup. Done.

"testl $4, %1\n\t" // Was it 4 bytes?
"je 3f\n\t" // no, Try 2 bytes

"movsx %%ebx, %%rbx\n\t" // Sign extend 32-bits to 64
"cdqe\n\t" // Sign extend EAX to RAX
"jmp 2f\n" // Done here

"3:\tmovsx %%bx, %%rbx\n\t" // Sign extend 16-bits to 64
"movsx %%ax, %%rax\n\t" // Sign extend AX TO RAX
"jmp 2f\n" // Done here

"1:\tmovsx %%bl, %%rbx\n" // Sign extend BL to RBX
"movsx %%al, %%rax\n" // Sign extend AL to RAX
"2:\tsub %%rbx, %%rax\n" // Subtract from comparison value
"pushfq\n\t" // Save the flags from the sub
"popq %0\n\t"
:"=r"(flags_word)
:"r"(len), "b"(val), "a"(rax));

guest_rflags &= ~MATH_FLAGS;
guest_rflags |= (flags_word & MATH_FLAGS);
source += inc;
count--;

> On 14/01/2024 01:36, bart wrote:
>>
>> People have suggested using make for everything, from hello.c up to
>> JP's and SL's massive applications.

While it's literally not wrong when you formulate it as "massive",
that's not the central point. The insight (for me) is another...

My take on that is based on the observation, now a bit abstract,
that we have processes that transform some input to some output...

input --> [ process ] --> output

....and the Makefile (syntax, and operational semantics) reflects
this relation and operation (formally quite straightforward) as

output: input
process

(And as noted elsethread already, this is even a generic view,
not restricted to compiling programming languages.)

There may be more or less input and output entities, and more or
less complex processes, and a lot of interconnected processes. But
it scales, both, the process view and the Makefile organization.

Whether it's trivial in one case, or "complex" ("massive") in other
cases doesn't change the coherent view on the topic, and also the
systematic approach (here [for example]: Makefiles) to tackle it.

A coherent systematic approach has (in my experience) advantages
(per se!), and more so if compared to isolated ad hoc handling of
such transformations. It's independent of and with respect to the
scaling.

(Note: There are of course also other things to consider that are
not covered in this post; like, e.g. whether it is more sensible
to use an available standard tool or method, or to cobble together
ones own solutions. The latter decision lies in the responsibility
of the person who is responsible for the project.)

Janis

PS: Bart, note that I read any responses from you only if others
find them valuable and answer them with quotes of your text. So
don't expect answers from me any more.
It would also be desirable if you'd open an own thread (also with
an appropriate subject) to discuss your themes. - Thanks.

Gabriel Rolland <gabrielrolland@gmail.com> writes:
>bart <bc@freeuk.com> writes:
>
>

>
>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.

Sometimes it can help to start from the beginning:

http://squoze.net/UNIX/v7/files/doc/06_shell.pdf

On 15/01/2024 03:14, bart wrote:
> 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:
>>>

>> 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.

You forgot the "IMHO" disclaimer. /You/ think it looks diabolic, and
you probably think that means everyone else thinks so too, and that
anyone who says they can use gcc inline assembler successfully is lying
or in denial.

I've used inline assembly with a fair number of compilers over the
years. There is no doubt that gcc's system can look scary. And there
is no doubt that there are simpler systems around.

However, I have never seen an inline assembly syntax that integrates
with an optimising compiler in an efficient way, and is not
approximately as complicated as gcc's.

Simpler inline assembly invariably places a lot more limits on the
integration. For example, it can require "assembly only" functions,
which cannot be inlined into other code. Or it forces specific uses of
registers, and perhaps forces local data to be put on the stack instead
of being in registers.

Several of the optimising compilers I have used have supported gcc's
syntax for inline assembly - including gcc, icc, clang and CodeWarrior
(which is a commercial compiler with no connection whatsoever with gcc
or open source - it just copies several of gcc's extensions because they
are a de-facto standard). The only compiler I used with an inline
assembly of comparable power and integration to gcc's, but a different
syntax, was Diab Data. It's syntax was nicer in some ways, less nice in
others, but I am confident that you would, if you were being honest,
find it equally diabolical.

(Note that gcc also supports what it calls "Basic assembly syntax". But
for most purposes, "Extended assembly syntax" is used because it is much
more powerful.)

> 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.
>

You pass the relevant data into and out of the inline assembly. If you
think you need access to other symbols in the assembly, you are (almost
certainly) doing things wrong. You are trying to do the compiler's job
behind its back, and that is not a good idea.

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

Exactly. You don't know.

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

If you are trying to write extensive programs in assembly, you are
already getting it wrong. Inline assembly is for things that cannot be
expressed in high level languages, or the very rare occasions where you
know a way to do something in assembly that is very much more efficient
than the compiler can generate, and the code is speed critical, and
there are no built-ins for the task, and no target intrinsics provided
by the processor manufacturer.

>
> 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.)

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

asm ("imul2 %[c], %[d]\n\t"
"add %[c], %[b]"
: [c] "+g" (c) : [b] "g" (b), [d] "g" (d));
a = c;
}

The generated result (from <https://godbolt.org>) is :

F():
mov eax, 3
imul2 eax, 4
add eax, 2
mov DWORD PTR a[rip], eax
ret

As you can see, I only need two manual assembly instructions - thinks
like moving data around are best handled in C, typically automatically
done by the compiler to fit the input and output operands. And the
compiler generates code that works with the optimiser.

With your simplistic inline assembly, you need to write everything
manually. And the compiler must assume to use rax and other scratch
registers, meaning it can't use them for local data that lives around
the assembly - even if your code does not use them. It has to put the
register data on the stack, and then your inline assembly has to move it
off the stack - a pointless waste of time compared to gcc that knows
about the data and the registers. Your assembly changes the value of
"a", but the compiler doesn't know that - so it is forced to make sure
all memory data is written out before the assembly, and re-read after
the assembly. What a painful waste of target efficiency!

Yes, your assembly syntax is simple and clear. No, it is not better for
real-world use-cases where inline assembly is relevant.

Let's look at an actual example from my own code, in an older project.
I wanted an endian swap function on an ARM microcontroller, and for
reasons that escape me for now, I did not want to use gcc's
__builtin_bswap32, or an intrinsic from a header, or just plain C code
(which modern gcc could optimise to a single "rev" instruction). The
code was probably originally written for quite an old version of the
compiler. So I wrote the function:

static inline uint32_t swapEndian32(uint32_t x) {
uint32_t y;
asm ("rev %[y], %[x]" : [y] "=r" (y) : [x] "r" (x) : );
return y;
}

This is, IMHO, quite clear once you know that gcc assembly consists of
the assembly template, the outputs, then the inputs. And it generates
the code optimally - when used in an expression, there will be no extra
moves, or data put on the stack, or wasted registers. The compiler can
move the code back and forth while optimising, eliminate calls when the
result is used, and generally do its job just as well with this function
as any other inline function or built in operator.

>
> You need to tell me, because I will otherwise not have a clue.

It's clear that you haven't a clue. So how can you justify ranting and
raving against something you don't understand?

> From what
> I've seen of gcc inline asm:
>
>  * Code has to be written within string literals,

Yes, obviously. Assembly is not C, so writing assembly mixed in your C
requires it to be in a format that is acceptable in C syntax (or at
least close enough to C syntax to be a non-invasive extension). String
literals are also quite amenable to generation by macros, for those that
want to write something complicated.

> in dreadfil AT&T
>    syntax.

"Dreadful" is, again, /your/ opinion - not shared by everyone. (I
personally don't care either way.) It only applies to x86, not any
other targets, and is easily changed by the "-masm=intel" flag.

> And apparently even with embedded \n line breaks. (Good
>    grief - I think early 80s BASICs had more sophisticated facilities!)

That is an inevitability for string literals. And it doesn't matter
much in practice, since most inline assembly (IME) consists of a single
statement - gcc handles any moves that might be needed.

Remember, the compiler passes the assembly on to the assembler - this is
/not/ a C compiler with a built-in assembler. And that's a good thing.
Have you any idea how many assembly instructions there are for all the
targets supported by gcc? And you'd need to update gcc every time there
was a new instruction, rather than just updating the assembler (which is
a lot simpler).

Of course it would be /possible/ to extend gcc with a built-in
assembler. But what would that give you? Lots of duplicate work to
support C, C++, Fortran, Ada, and other languages? The assembler
already handles assembly - why make an HLL do it? It's a lot better to
put the effort into reducing the number of times you actually need to
write inline assembly, by improving the optimiser and builtin functions.

On 15/01/2024 08:07, Kaz Kylheku wrote:
> On 2024-01-15, bart <bc@freeuk.com> wrote:
>> On 15/01/2024 00:34, Kaz Kylheku wrote:

>> 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.

That is not the only problem, but it is certainly a limitation.

>
>> 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.

That makes sense.

> 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.

Yes. You could also use "g", which allows registers, or memory
addresses, or immediate results, which could be appropriate for some
operands on some processors (like the x86). Re-arranging slightly
(unless that is considered "cheating"), so that the C code is "c *= d; c
+= b;", then only "c" needs to be in a register. And gcc can do the
move for you, so you don't need the third instruction. (On a processor
with three argument instructions, common for many RISC cpus, your "add"
would go directly to "a". But you'd also want to keep all operands as "r".)

> They are referenced by number: %0, %1, %2, %3 in the order they
> appear. (A way to use named references exists.)

Yes. I like to use it, if I have more than two operands. I often use
it even if I have just one or two operands.

> GNU inline assembly is ugly, but it's very well designed semantically;
> it hits the target.
>

I don't think gcc inline assembly is particularly pretty, or easy to use
- but I have not seen any alternatives that come close to the power and
/are/ pretty or easy to use. Inline assembly is something to be used
rarely, when you really need it - and rarely used things are allowed to
be difficult or ugly, and to require the user to look up reference
manuals. If a language or compiler's inline assembly is easy to use,
it's a sign that the tool is so weak that people will need to resort to
assembly on a regular basis.

On 15/01/2024 14:46, Janis Papanagnou wrote:
>
> It would also be desirable if you'd open an own thread (also with
> an appropriate subject) to discuss your themes. - Thanks.
>

To be fair, he already did - "C and Make" - Message-ID:
<uo1dbu$img2$1@dont-email.me>

"Started a new thread as the last one went somewhat off-topic regarding
'CPP tags'."

On 15/01/2024 14:35, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:

>> But you've also made it clear that this isn't really assembly at all. Is
>> it even for x64? I can't tell! The use of 'mov' rather than 'ldr' or
>> 'str' suggests it is x86 or x64 rather than ARM. But are those 32-bit
>> mov's or 64-bit?
>
> 1) it's not an assembler, it's a way to "patch" the assembler code
> generated by the compiler.
>
>>
>> So it's some sort of hideous hybrid that gcc has come up with, that is
>> neither assembly nor C.
>
> Your baseless opinion noted. Feel free to submit a patch to
> the GCC team to implement your preferred syntax for inline assembler.
>
> Do ensure that it works for all 100 of the GCC target architectures.

Which all share the same instruction set? And all have an 'ebx' register:

"movsx %%ebx, %%rbx\n\t"
?

>
>> It would be far, far simpler to write assembly in its own file (and keep
>> well away from AT&T syntax),
>
> No, it would not be.
>
> And the AT&T syntax is _far_ superior to the intel syntax
> with all the ugly syntactic sugar.
>
> val = tp->mem_read(psource, len);
> rax = get_reg_value(regs, REG_RAX, QUAD);
>
> __asm__ __volatile__ (
> "testl $1, %1\n\t" // 1 byte operand?
> "jne 1f\n\t" // Yes, go to it
>
> "testl $8, %1\n\t" // Was it eight bytes?
> "jne 2f\n\t" // Yup. Done.
>
> "testl $4, %1\n\t" // Was it 4 bytes?
> "je 3f\n\t" // no, Try 2 bytes

> "movsx %%ebx, %%rbx\n\t" // Sign extend 32-bits to 64
> "cdqe\n\t" // Sign extend EAX to RAX
> "jmp 2f\n" // Done here
>
> "3:\tmovsx %%bx, %%rbx\n\t" // Sign extend 16-bits to 64
> "movsx %%ax, %%rax\n\t" // Sign extend AX TO RAX
> "jmp 2f\n" // Done here
>
> "1:\tmovsx %%bl, %%rbx\n" // Sign extend BL to RBX
> "movsx %%al, %%rax\n" // Sign extend AL to RAX
> "2:\tsub %%rbx, %%rax\n" // Subtract from comparison value
> "pushfq\n\t" // Save the flags from the sub
> "popq %0\n\t"
> :"=r"(flags_word)
> :"r"(len), "b"(val), "a"(rax));

You're having a laugh, surely? AT&T is bad enough even without the
travesty of it displayed here:

"jmp 2f\n"
"3:\tmovsx %%bx, %%rbx\n\t"

What's with the strings, newline and tab escapes? What's that 'f' for?
Instead of %rbx you now have to type %%rbx; better not leave out an % by
mistake. And you have to pay close attention here:

"testl $1, %1\n\t" // 1 byte operand?

so as not to mix up $1 and %1. It almost makes makefiles look readable!

I generally write:

"\tmovsx %%bx, %%rbx\n\t"

as:

movsx rbx, bx

I assume "2f" and "2:" are labels? I don't understand why you couldn't
have made it a /little/ more readable by writing:

"1:\tmovsx %%bl, %%rbx\n" // Sign extend BL to RBX
"movsx %%al, %%rax\n" // Sign extend AL to RAX

for example as:

"1: movsx %%bl, %%rbx" nl // ...
" movsx %%al, %%rax" nl // ...

BTW those comments are superfluous, unless you are acknowledging that
the syntax is so unreadable, that you have to write a version in English.

On 15/01/2024 08:40, Kaz Kylheku wrote:
> 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; })

static inline int mul_add(int x, int y, int z) {
asm("imul %[z], %[y]\n\t"
"add %[z], %[x]"
: [z] "+r" (z) : [y] "g" (y), [x] "g" (x));
return z;
}

>
> 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;
> }
>

Yes.

>
> 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.

static inline int mul(int x, int y) {
asm("imul %[x], %[y]"
: [x] "+r" (x) : [y] "g" (y));
return x;
}

static inline int add(int x, int y) {
asm("add %[x], %[y]"
: [x] "+r" (x) : [y] "g" (y));
return x;
}

static inline int mul_add(int x, int y, int z) {
return add(x, mul(y, z));
}

Now compiling G gives (with Intel syntax - because some people cry
louder than others!) :

G:
mov eax, edi
imul r9d, DWORD PTR [rsp+8]
imul esi, edx
add r8d, r9d
add eax, esi
imul r8d, DWORD PTR [rsp+16]
add ecx, r8d
imul ecx, DWORD PTR [rsp+24]
add eax, ecx
ret

Notice how gcc can now re-arrange the adds and multiplies for greater
efficiency, and skip redundant moves and unnecessary register loads.

This is almost as optimal as if we define:

static inline int mul_add(int x, int y, int z) {
return x + y * z;
}

The only difference is that the for the inline assembly, the compiler
can't take advantage of what it knows about being able to ignore the
upper half of the 64-bit registers when doing this 32-bit arithmetic.

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. ...

That's not been my experience. The make file is generally only a small
fraction of the total size of the source code files. This is
particularly true if it was written by someone familiar with and making
effective use of make's defaults, which are generally well-chosen (you
would not agree, of course - but those defaults were chosen for a target
audience with very different preferences from yours).

> ... A component you can't always
> ignore since essential build info is encoded in it.

Well, yes - but that build info needs to be stored somewhere. It could
be in the documentation, but especially for projects far more
complicated than yours, equivalent documentation would be large,
complex, and easily misunderstood. Putting that information in a make
file is far more reliable, when targeting platforms that support make.
It's also a lot easier to customize the make file than to figure out how
to make corresponding modifications to the documentation.

Part of the information could be put in a build script. In fact, that's
what makefile controls: for each rule, there's a build script. By
default, the "sh" shell is used to interpret those scripts, but you can
change it to use your preferred scripting language instead.
However, all of those parts of a makefile that aren't build scripts
encode additional useful information that ordinary script languages
aren't designed to handle.

On 15/01/2024 17:04, David Brown wrote:
> On 15/01/2024 08:40, Kaz Kylheku wrote:

>> 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.
>>
>
> Yes.  For inline assembly, simple is not really important, but small is
> beautiful!  Say exactly what you mean, no more and no less, and let the
> compiler do what it does best.
>
>
> And move to C++20.  Then you can write (for the mythical madd
> instruction) :
>
> constexpr int mul_add(int x, int y, int z)
> __attribute__((const))
> {
>   if (std::is_constant_evaluated()) {
>     return x + y * z;
>   } else {
>     asm("madd %[x], %[y], %[z]"
>         : [x] "+r" (x) : [y] "g" (y), [z] "g" (z));
>     return x;
>   }
> }
>
>
> Now the compiler can evaluate at compile time if the parameters are
> known, or using the super-efficient madd instruction at runtime if
> necessary.
>

Apologies for replying to my own post, but of course this can be done in
C with gcc extensions (and when we have inline assembly, we are already
relying on gcc extensions):

static inline int mul_add(int x, int y, int z)
__attribute__((const))
{   if (__builtin_constant_p(x + y * z)) {
return x + y * z;
} else {
asm("madd %[x], %[y], %[z]"
: [x] "+r" (x) : [y] "g" (y), [z] "g" (z));
   return x;
}
}

This is, in fact, even better than the C++20 version since it will
optimise to compile-time computation if the result can be calculated at
compile time, even if all the parameters are not "constant expressions".
This code will be optimised to "return 0;" :-)

int F4(int y, int z) {
return mul_add(y * z, -y, z);
}

bart <bc@freeuk.com> writes:

> 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...
>

Oh no, that was not about the spelling of the word. It was about
semantics. I think they can be quite defended, and everybody here has
proved it.

>> 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.)

This has been answered better than I could by David Brown.

> 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.

The executable. Unix treatment of file extension is non existent,
true. So I don't bother with file extensions much. But I have yet to go
on comp.os.windows to explain how confusing file extensions are.

>> 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.
>
That is not about the use case my two cents were about. Why bring up
cross compilation to the table ?
I think it is another problem and it is the reason why your answer is
longer than you intended.

> (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.

This is a supposition on your part. If gcc/cc was working as you said,
like outputting of hello.c hello.exe by default. In that case I would
maybe have considered something like aliasing gcc thus :

alias cc='gcc -o current.exe'

So I wouldn't have that extra hassle. But that would belong to my
'.profile' opinions and everybody can have his own '.profile' opinion
about how gcc should work. I respect that.

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

> On 15/01/2024 09:51, Gabriel Rolland wrote:
>> 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.
>
> Welcome to the group - and as a new C programmer!
>
> We don't /just/ discuss the finer points of the C standards, but that
> is definitely something we do cover, and you'll be hard pushed to find
> a discussion forum with more standards experts than you find here. We
> are happy to discuss all kinds of aspects of C programming, but if you
> need platform-specific help or help with particular libraries, it's
> not often a good place - but we might be able to suggest alternatives.
>
> It's worth starting a new thread if you have something specific - a
> lot of people will already have marked this thread as pointless and
> ignored!
>
>> This group
>> seems rather lively, I guess it is partly thanks to you, Bart.
>
> Oh, Bart does not lack in enthusiasm and energy for his postings :-)
> He is, however, often confusingly inaccurate about C. Ask some
> questions, and you'll quickly see which regulars give answers that
> work for your needs (some are better at getting the exact details
> right, others are better at explaining in layman's terms).
>
>>
[snip]

Thank you for the welcoming words and the quick intro :)

scott@slp53.sl.home (Scott Lurndal) writes:

> Gabriel Rolland <gabrielrolland@gmail.com> writes:
>>bart <bc@freeuk.com> writes:
>>
>>
>
>>
>>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.
>
> Sometimes it can help to start from the beginning:
>
> http://squoze.net/UNIX/v7/files/doc/06_shell.pdf

Thanks a lot for the resource ! I will check that.

David Brown <david.brown@hesbynett.no> writes:
>On 15/01/2024 03:14, bart wrote:

<snip>

> The only compiler I used with an inline
>assembly of comparable power and integration to gcc's, but a different
>syntax, was Diab Data.

Now there's a name I haven't heard in decades. What ever happened
to them? We worked with them back in the early 90's using their
88100 compiler. It was impressive, particularly compared to the
PCC port that Motorola provided. Greenhills was ok, but diab
produced better code. gcc was still pretty primitive in those days.

A good Norweigian company.

bart <bc@freeuk.com> writes:
>On 15/01/2024 14:35, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>
>>> But you've also made it clear that this isn't really assembly at all. Is
>>> it even for x64? I can't tell! The use of 'mov' rather than 'ldr' or
>>> 'str' suggests it is x86 or x64 rather than ARM. But are those 32-bit
>>> mov's or 64-bit?
>>
>> 1) it's not an assembler, it's a way to "patch" the assembler code
>> generated by the compiler.
>>
>>>
>>> So it's some sort of hideous hybrid that gcc has come up with, that is
>>> neither assembly nor C.
>>
>> Your baseless opinion noted. Feel free to submit a patch to
>> the GCC team to implement your preferred syntax for inline assembler.
>>
>> Do ensure that it works for all 100 of the GCC target architectures.
>
>Which all share the same instruction set?

No, of course not. The compiler syntax must be usable for all supported
architectures. All the compiler does is pass it through to the
assembler output after any parameter substitution. The compiler doesn't
even look at the opcode.

>You're having a laugh, surely?

No. I'm serious. [DWORD] is useless cruft.

>AT&T is bad enough even without the
>travesty of it displayed here:
>
> "jmp 2f\n"
> "3:\tmovsx %%bx, %%rbx\n\t"

If you don't understand the standard C escapes, you really
should go back to read the standard carefluly.

>
>What's with the strings, newline and tab escapes? What's that 'f' for?

RTFM for the architecture dependent assembler that the compiler
driver will end up calling to build the output object file.

Gabriel Rolland <gabrielrolland@gmail.com> writes:
>bart <bc@freeuk.com> writes:
>

>> 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.
>
>The executable. Unix treatment of file extension is non existent,

That is an understatement. A unix filename is a sequence of bytes
with no semantics associated with them, other than by application
convention.

The largest security hole in Windows was its reliance on extension
to identify file type regardless of content.

> This is a supposition on your part. If gcc/cc was working as you said,
> like outputting of hello.c hello.exe by default. In that case I would
> maybe have considered something like aliasing gcc thus :
>
> alias cc='gcc -o current.exe'

or
function cc
{ gcc -o "$1".exe "$1".c
}

as was posted upthread.

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

> This has been answered better than I could by David Brown.

I'm not reading DB's comments today.

> The executable. Unix treatment of file extension is non existent,
> true. So I don't bother with file extensions much. But I have yet to go
> on comp.os.windows to explain how confusing file extensions are.

This is not a Linux newsgroup. It's a language group.

But I expect you do use file extensions. Otherwise any file in one of
your folders be absolutely anything: text, source in any language,
document, binary data, object file, executable ...

I'm imagine if 'abc' was a C source file, you'd have to put the object
file 'abc' in a separate folder, and the executable 'abc' in a third
one? Otherwise they will clash.

So extensions serve useful purposes for both machine, and human users.

Programs that deal with them will of course check that they are what
they say they are.

> This is a supposition on your part. If gcc/cc was working as you said,
> like outputting of hello.c hello.exe by default. In that case I would
> maybe have considered something like aliasing gcc thus :
>
> alias cc='gcc -o current.exe'

> So I wouldn't have that extra hassle.
> But that would belong to my
> '.profile' opinions and everybody can have his own '.profile' opinion
> about how gcc should work. I respect that.

Suppose you write an application as myprog.c. You distribute it for
people to build. The instructions could have been as simple as:

gcc myprog.c

and it will create myprog which can be invoked as ./myprog, or as
myprog.exe which on Windows is invoked as just myprog.

But because of this stupid quirk in gcc that could have been fixed in
three lines of code, millions of people have to add extra instructions:

gcc myprog.c -o myprog

You don't get this in other languages.

It is just Wrong.

Hardcoding the name of an output file is something a beginner might do,
or in the early stages of an an application (I do that myself).

But that program version is never going to see the light of day. So how
the hell did that idiotic behaviour of gcc (and the worse one of as)
ever escape into the wild? QoI was lacking.

Meanwhile everybody is defending it, and there are even people like you
saying that is an advantage!

On 15/01/2024 17:35, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:

>> You're having a laugh, surely?
>
> No. I'm serious. [DWORD] is useless cruft.

I don't use [DWORD], whatever that means.

Meanwhile %% in front of every register name, f after a label, and ""
and \n and \t on every line is useful cruft!

>> AT&T is bad enough even without the
>> travesty of it displayed here:
>>
>> "jmp 2f\n"
>> "3:\tmovsx %%bx, %%rbx\n\t"
>
> If you don't understand the standard C escapes, you really
> should go back to read the standard carefluly.

I understand C escape codes. I am asking WHAT THE FUCK ARE THEY DOING IN
EVERY LINE OF AN ASSEMBLY PROGRAM?

You're doing this on purpose aren't you?

>
>>
>> What's with the strings, newline and tab escapes? What's that 'f' for?
>
> RTFM for the architecture dependent assembler that the compiler
> driver will end up calling to build the output object file.

So you don't actually know.

Just admit that my approach to inline assembler is better and give it up.

bart <bc@freeuk.com> writes:
>On 15/01/2024 16:40, Gabriel Rolland wrote:
>> bart <bc@freeuk.com> writes:
>
>> This has been answered better than I could by David Brown.
>
>I'm not reading DB's comments today.

Your loss.

>
>> The executable. Unix treatment of file extension is non existent,
>> true. So I don't bother with file extensions much. But I have yet to go
>> on comp.os.windows to explain how confusing file extensions are.
>
>This is not a Linux newsgroup. It's a language group.
>
>But I expect you do use file extensions.

Sure, for convenience, not necessity. Some very useful tools,
such as make, have default rules for common file name suffixes,
but there's nothing that prevents one from supplying their own
rules.

>Otherwise any file in one of
>your folders be absolutely anything: text, source in any language,
>document, binary data, object file, executable ...

It's a directory, not a folder.

And yes, any file in a directory can be pretty much anything the
user wants it to be. c_code_main is a perfectly legal name for
a c source file while b235 is a perfectly legal name for the
executable file generated by a C compiler from the source file
c_code_main.

>
>I'm imagine if 'abc' was a C source file, you'd have to put the object
>file 'abc' in a separate folder, and the executable 'abc' in a third
>one? Otherwise they will clash.

$ cat /tmp/z
#include <stdio.h>

int
main(int argc, const char **argv, const char **envp, const char **auxv)
{ printf("Hello World\n");

return 0;
} $ cat /tmp/z | cc -x c -o a -
$ ./a
Hello World
$

>Programs that deal with them will of course check that they are what
>they say they are.

And how, exactly, will they do that for a text file?

>But because of this stupid quirk in gcc that could have been fixed in
>three lines of code, millions of people have to add extra instructions:
>
> gcc myprog.c -o myprog

You keep beat a dead horse. Pointless and a waste of time.

>
>You don't get this in other languages.

That's demonstrably false.

bart <bc@freeuk.com> writes:
>On 15/01/2024 17:35, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>
>>> You're having a laugh, surely?
>>
>> No. I'm serious. [DWORD] is useless cruft.
>
>I don't use [DWORD], whatever that means.
>
>Meanwhile %% in front of every register name, f after a label, and ""
>and \n and \t on every line is useful cruft!
>
>>> AT&T is bad enough even without the
>>> travesty of it displayed here:
>>>
>>> "jmp 2f\n"
>>> "3:\tmovsx %%bx, %%rbx\n\t"
>>
>> If you don't understand the standard C escapes, you really
>> should go back to read the standard carefluly.
>
>I understand C escape codes. I am asking WHAT THE FUCK ARE THEY DOING IN
>EVERY LINE OF AN ASSEMBLY PROGRAM?

Even you included them in the example you posted (and elided from this reply).

I include the C escape codes (they're not necessary for proper compilation) to make
the intermediate assembler output more readable, in the unlikely event
that one might need to look at it for some reason. Force of long-standing
habit.

You can certainly leave them out if you don't want them. They're not
required. But you'd know that if you had bothered to read the
documentation.

>>> What's with the strings, newline and tab escapes? What's that 'f' for?

Assemblers for fifty years have used numeric temporary labels. So that
the target can be before or after the branch instruction, one may suffix
the branch label with 'f' or 'b' on a branch-class instruction. The
GNU gas assembler is hardly the first assembler to support such syntax.

But, I suspect you already know this, and may even have been able to
figure it out from context. But that wouldn't fit your trolling
narrative.