On 15/01/2024 19:12, Scott Lurndal wrote:
> 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

True:

c:\c>copy hello.c c_code_main
1 file(s) copied.

c:\c>mcc c_code_main.
Compiling c_code_main. to c_code_main.exe

Although some compilers appear to have a problem with it:

c:\c>gcc c_code_main.
C:\tdm\bin\ld.exe:c_code_main.: file format not recognized; treating
as linker script
C:\tdm\bin\ld.exe:c_code_main.:2: syntax error
collect2.exe: error: ld returned 1 exit status

They still need that scrap of info that was imparted by the extension,
either as .c or as -xc

> while b235 is a perfectly legal name for the
> executable file generated by a C compiler from the source file
> c_code_main.

It might well be. On Linux of course they tend not to have extensions,
for a very simple reason: it would get rapidly tedious to have to type,
many 1000s of times:

./b235.elf

or whatever extension is chosen.

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

Not sure what you're demonstrating here. Except how you're evading the
issue by avoiding intermediate files altogether.

Brilliant. Not sure how it plays with makefiles though which seem to
deal extensively with .o files.

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

How does Linux deal with that same problem?

bart <bc@freeuk.com> writes:
>On 15/01/2024 19:12, Scott Lurndal wrote:
>
>>
>>> 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?
>
>How does Linux deal with that same problem?

Linux doesn't.

The gnu C compiler will produce errors if the input isn't valid C,
I suppose you could call that checking that they are what
they say they are.

On 15/01/2024 19:41, bart wrote:
> 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.

Maybe you will look later - or maybe others will find them interesting.
I am clear in my opinions in my posts, but I have also written a great
deal that is primarily to help you. If you don't pay attention to that,
it's not going to help your reputation of being wilfully ignorant and
disregarding help and advice.

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

So why are you concerned here with Linux's use, or lack thereof, of file
extensions?

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

Sure, file extensions can be very useful. They can also be deceiving,
which is why it is a huge security hole in Windows (though I'd hesitate
to agree with Scott that it is the /biggest/ hole in Windows) to treat
them as so important. It tells me something when a file has .txt, or
..c, or .md at the end. It also gives programs useful information if
they have to deal with multiple file types that cannot be identified
clearly. But it is not something a system should rely on for something
important, and programs should allow file extensions to be overridden.

Thus gcc will assume "file.c" is a C file, while "file.f" is a Fortran
file. But you can override that if you want. And file extension is
irrelevant to *nix OS's for identifying if a file should be executed or
not. Everyone wins, no one loses - unlike the Windows user who
double-clicks on a malware file called "Readme.txt.exe" and the OS has
"helpfully" hidden the ".exe" bit.

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

Yes, gcc could have been made that way. I expect people would have been
fine with that. But it's not made that way, and most people seem fine
with what gcc actually does. I doubt there are many people who think
defaulting to a.out is a particular advantage these days (presumably it
was a good idea historically), but I doubt that there are many who are
bothered by it.

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

gcc is not a language. But without having tried every other compiler
(for C or other languages), I'd be loath to claim there are no other
compilers that also have a default output file. I don't think you have
either.

I believe, however, that I can honestly say I don't know if any of the
other C compilers (or linkers, as that's more accurate) I have used over
the decades have a default output file, and what it might be. I've
always specified the output filename I want.

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

Do you not think that someone else might have noticed if it were such an
issue? Have you ever heard anyone else complain? gcc is something like
four decades old, and *nix and C compilers are another decade older.

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

Maybe to some people it /is/ an advantage. Have you ever considered that?

On 1/15/2024 5:20 AM, David Brown wrote:
> 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.

Fair enough! Well, back in the day, I was very worried about a "rouge"
compiler making a mistake in my sync code, one little mistake would ruin
its correctness. So, I said, okay. I only have to target a couple of
archs, okay let get to work. So, I wrote my asm in externally assembled
files, one for each arch I had to target. Fwiw, here is my main
rational. It worked for me! If you think it is "moronic", so be it. No
problem at all. It was before C++11 and I was "nervous", so try to take
some pity on me, thanks... ;^)

https://web.archive.org/web/20070823190955/http://appcore.home.comcast.net/

Btw, can you view that link? Thanks David.

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

Well, shit happens! Once C++11 came out, I said ahhhh! I can possibly
remove that externally assembled sync code of mine wrt porting it over
to standard C/C++11.

BTW, GCC has a nasty bug wrt trylock...

On 15/01/2024 18:30, Scott Lurndal wrote:
> 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.

A good /Swedish/ company, not Norwegian!

The compiler was bought by Wind River, and I don't think it is very
relevant now.

I only ever got to play with the compiler for a short while, back in the
late 1990's, for the m68k. Our company couldn't afford it at the time
as it was /not/ cheap. But it had powerful optimisation for its day.

I've never been much fond of Greenhills, though I have not had much use
of it (some customers have).

On 1/15/2024 8:29 AM, David Brown wrote:
> 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.
[...]

Wrt inline GCC assembly, remember __volatile__ and memory? ;^)

On 1/15/2024 6:15 AM, bart wrote:
[...]

Iirc, Microsoft got rid of inline assembly for 64 bit targets a while back.

On 1/15/2024 10:55 AM, bart wrote:
> 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.

inline assembler is not my cup of tea. If I work for a team that uses
it, well I can use it as well... However, I might not have a big smile
on my face when I am working on it. My boss says, hey man, if you don't
smile right now you are fired. Well, I would smile for sure! ;^)

David Brown <david.brown@hesbynett.no> writes:
>On 15/01/2024 18:30, Scott Lurndal wrote:
>> 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.
>
>A good /Swedish/ company, not Norwegian!

Hm. I could have sworn the folks we dealt with were
in Norway - perhaps a branch office?

On Thu, 11 Jan 2024 18:31:00 +0000, bart <bc@freeuk.com> wrote in
<unpc54$33efd$1@dont-email.me>:

> See? It's built in to my compiler. No separate 'make' is needed.

"You die on weird hills."

I've been using make for 32 years. I'd love to discuss
it with you -- but not in c.l.c.

[ fu2: comp.unix.programmer ]

--
-v

David Brown <david.brown@hesbynett.no> writes:
> On 12/01/2024 18:09, bart wrote:
[...]
>> I'm separating the fundamental build-process for a program from what
>> is needed for interactive development and testing.
[...]
>> 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.
[...]

Is it? Most open source projects I've seen use "make" both for
developer incremental builds and end user full builds. My experience is
that this works just fine -- especially given make's ability to do
parallel builds.

--
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-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 1/15/2024 8:29 AM, David Brown wrote:
>> 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.
> [...]
>
> Wrt inline GCC assembly, remember __volatile__ and memory? ;^)

The volatile is only important if you're writing sync primitives, so the
compiler won't move loads or stores to one side or the other of the
inline assembly. If you're just doing some calculation, it's
counterproductive to tell the compiler not to move the code.

"memory" is only needed if your inline code clobbers memory. E.g.
one of the operands is a pointer, and the code writes through it.
That location isn't one of the output operands.

--
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-15, bart <bc@freeuk.com> wrote:
> c:\c>copy hello.c c_code_main
> 1 file(s) copied.

There goes that damned AT&T instruction syntax for file copying, same
like in Unix.

Doesn't it bother you that it isn't: copy destination source?

--
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 23:28, Kaz Kylheku wrote:
> On 2024-01-15, bart <bc@freeuk.com> wrote:
>> c:\c>copy hello.c c_code_main
>> 1 file(s) copied.
>
> There goes that damned AT&T instruction syntax for file copying, same
> like in Unix.
>
> Doesn't it bother you that it isn't: copy destination source?

I haven't said anything about in which direction the data goes.

This is something that tends to depend on device, so Motorola went left
to right, and Zilog/Intel went right to left.

So it did seem odd for this x86 assembler to do the opposite of Intel.

However, doesn't it bother /you/ that AT&T also does the opposite of not
only how assignment works in C, but in most languages? That would be
more pertinent than somebody's choices of command-line syntax.

On 2024-01-15, bart <bc@freeuk.com> wrote:
> 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?

The instruction template is just a string literal to the
compiler. It specifies text to be inserted into the assembly
output.

Some assembly languages require the whitespace; you need
instructions to be on separate lines.

GCC does not look inside this template other than to replace
% codes like %0 (the first register).

In my example, I put the newlines and tabs together on the right

"imul %3, %2\n\t"
"add %1, %2\n\t"
"mov %1, %0\n\t"

Thanks to these newlines and tabs, the textual output (generated .s
file if we use gcc -S) has this in it:

#APP
# 24 "inline.c" 1
imul %edx, %esi
add %esi, %edi
mov %edi, %edi

# 0 "" 2
#NO_APP
movl 8(%rsp), %eax
movl 16(%rsp), %edx

GCC's code is using eight spaces; mine is tabs. The indentation on
imul is spaces: that was generated by GCC. You don't have to
indent your first instruction.

You can understand why GCC went with this textual templating approach, since
the number of back-end assembly languages is astonishing. In some cases, I
think, GCC supports more than one assembler syntax for the same architecture.
Historically it has worked with assemblers that didn't come from GNU.

It would not be practical for GNU C to have a bazillino assembly language
syntaxes in its grammar.

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

Your approach to inline assembler has nicer looking syntax, but
semantically, it doesn't seem to be on same level as the GCC approach.

GCC's inline assembly does nice things that are might not be possible in your
implementation. (Or pretty much anyone else's).

Some of it has been sufficiently exemplified elsewhere in the thread.

GCC can choose registers for your inline assembly block, and will automatically
move between those registers and the operands they are connected to (if
necessary). The inline code seamlessly integrates with the code generated by
the compiler. You can write primitives that generate code as well as compiler
built-ins.

--
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 1/15/2024 3:24 PM, Kaz Kylheku wrote:
> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 1/15/2024 8:29 AM, David Brown wrote:
>>> 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.
>> [...]
>>
>> Wrt inline GCC assembly, remember __volatile__ and memory? ;^)
>
> The volatile is only important if you're writing sync primitives, so the
> compiler won't move loads or stores to one side or the other of the
> inline assembly. If you're just doing some calculation, it's
> counterproductive to tell the compiler not to move the code.
>
> "memory" is only needed if your inline code clobbers memory. E.g.
> one of the operands is a pointer, and the code writes through it.
> That location isn't one of the output operands.
>

I want my sync primitive code to be _un_abused by any "clever"
optimizations. I want it is as it is. No rouge compiler thinking that
link-time optimizations are all fun and joy, lets dance around the sync
instructions... Step on them, ruin them, make them incorrect. Even GCC
had a nasty error with an optimization wrt Pthread
pthread_mutex_trylock(). Simply ruined is correctness wrt the standard.

Some sarcastic comic relief: A setting for all compilers,
-ct_stay_away_from_my_asm_pretty_please Would that make some programmers
laugh out loud? lol. ;^)

On 1/15/2024 4:04 PM, bart wrote:
> On 15/01/2024 23:28, Kaz Kylheku wrote:
>> On 2024-01-15, bart <bc@freeuk.com> wrote:
>>>      c:\c>copy hello.c c_code_main
>>>           1 file(s) copied.
>>
>> There goes that damned AT&T instruction syntax for file copying, same
>> like in Unix.
>>
>> Doesn't it bother you that it isn't: copy destination source?
>
> I haven't said anything about in which direction the data goes.
>
> This is something that tends to depend on device, so Motorola went left
> to right, and Zilog/Intel went right to left.
>
> So it did seem odd for this x86 assembler to do the opposite of Intel.
>
> However, doesn't it bother /you/ that AT&T also does the opposite of not
> only how assignment works in C, but in most languages? That would be
> more pertinent than somebody's choices of command-line syntax.
>

Fwiw, just make both, I did AT&T syntax and Intel syntax files. Nice and
neat (I think so) with the C ABI, CDECL.

https://groups.google.com/g/comp.arch/c/6zvMwefWIWw/m/5nIzi8MPAgAJ
___________
Fwiw, I found some of my older 686 code I posted about way back in 2006.
The WayBack Machine is pretty nice!

http://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

Here is a MASM version:

http://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html
___________

No big deal, I just had to do it. So, once it was done, it was done. If
I needed another arch, I would code one up for it (per-arch asm file).
SPARC, no problem. Just keep in mind to NEVER put a memory barrier
instruction in a branch delay slot on SPARC. oh very bad...

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

[Inline assembly]

> The instruction template is just a string literal to the
> compiler. It specifies text to be inserted into the assembly
> output.
>
> Some assembly languages require the whitespace; you need
> instructions to be on separate lines.
>
> GCC does not look inside this template other than to replace
> % codes like %0 (the first register).
>
> In my example, I put the newlines and tabs together on the right
>
> "imul %3, %2\n\t"
> "add %1, %2\n\t"
> "mov %1, %0\n\t"
>
> Thanks to these newlines and tabs, the textual output (generated .s
> file if we use gcc -S) has this in it:
>
> #APP
> # 24 "inline.c" 1
> imul %edx, %esi
> add %esi, %edi
> mov %edi, %edi
>
> # 0 "" 2
> #NO_APP
> movl 8(%rsp), %eax
> movl 16(%rsp), %edx
>

This is still peculiar: why prioritise the appearance of the
intermediate code which I assume you're rarely going to look at?

It's the version with strings and escape codes that you're going to be
writing and maintaining, and that people will see in the C sources!

This is akin to a language allowing embedded C but you have to write it
like this:

clang{"\tprintf(\"A=%%d\\n\", a);\n"};

so that the generated version looks like:

printf("A=%d\n", a);

Except you can't refer to 'a' directly, you have to write it as %0 and
then have some extra mechanism to somehow map that to 'a'.

> You can understand why GCC went with this textual templating approach, since
> the number of back-end assembly languages is astonishing. In some cases, I
> think, GCC supports more than one assembler syntax for the same architecture.
> Historically it has worked with assemblers that didn't come from GNU.

gcc is a project 10s of 1000s of files. If a particular configuration
targets one architecture out of 100, it can also support the ASM syntax
for that architecture.

You don't need to have the ASM syntax embedded within the C grammar. Not
so specifically anyway; you allow a bunch of keyword and register tokens
within asm{...}.

Yes it's a bit harder, but if I can do it within a 0.3MB product, gcc
can do it within 24MB.

> It would not be practical for GNU C to have a bazillino assembly language
> syntaxes in its grammar.
>
>> Just admit that my approach to inline assembler is better and give it up.
>
> Your approach to inline assembler has nicer looking syntax, but
> semantically, it doesn't seem to be on same level as the GCC approach.
>
> GCC's inline assembly does nice things that are might not be possible in your
> implementation. (Or pretty much anyone else's).
>
> Some of it has been sufficiently exemplified elsewhere in the thread.
>
> GCC can choose registers for your inline assembly block,

The point of ASM is that /you/ call the shots.

It's not just more natural syntax, but better integration within the
host language. More example, I can 'goto' to a label within an ASSEM
block, and 'jmp' out of the ASSEM block to a HLL label, or to an label
within a separate ASSEM block further on.

> and will automatically
> move between those registers and the operands they are connected to (if
> necessary). The inline code seamlessly integrates with the code generated by
> the compiler. You can write primitives that generate code as well as compiler
> built-ins.

OK. But it's not an 'assembler' as is generally understood. Mine is; it
looks exactly line normal assembly, and it is written inline to the HLL.

Although these days I keep such hybrid functions within their own modules.

On 15/01/2024 16:29, David Brown wrote:
> 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]"

Which processor is this for again?

On 15/01/2024 15:23, David Brown wrote:
> On 15/01/2024 03:14, bart wrote:

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

Not with gcc. You don't want to mess with that.

But /I/ use inline assembler when /I/ in in charge of the code.

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

I want to write HLL functions that may have a number of lines in
assembly, from one line up to a few dozen.

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

Sorry, but you've turned it into gobbledygook. My example was for x64
which is a 1.5 address machine, here you've turned it into a 2-address
machine. Could I make it 3-address? What are the rules?

It is a different language.

> 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

The initialisations I used were so I could test that it gave the correct
results. Without them, godbolt gives me this for the body of the function:

movl d.0(%rip), %edx
movl -8(%rbp), %eax
imul2 %eax, %edx
add %eax, -4(%rbp)
movl %eax, -8(%rbp)
movl -8(%rbp), %eax
movl %eax, a(%rip)

My version (which evaluates a=b+c*d; somehow your version modifies c)
gives me this (D0 == rax):

mov D0, [Dframe+test.f.c]
imul2 D0, [test.f.d]
add D0, [Dframe+test.f.b]
mov [test.a], D0

Unsurprisingly, this is exactly the ASM I typed (plus the necessary name
qualifiers). That is the entire point.

If I tweak your C version, make a,b,c,d all external statics, and apply
-O3, godbolt gives me this:

imul2 c(%rip), d(%rip)
add c(%rip), b(%rip)
movl c(%rip), %eax
movl %eax, a(%rip)
ret

This is slightly worrying: imul2 is not a valid instruction (it's
specific to my assembler). While add can't take two memory operands.

So it looks like it can only do so much checking. (Using gcc locally
gave valid assembly.)

So it all seems hit and miss.

I'll reply to the second half of your post later.

Let me just say that, in my interpreter, the extensive use of inline
assembly in one module, makes some programs run twice as fast, as a
gcc-O3-compiled C rendering.

It also lets me write trivial solutions to the LIBFFI problem.

It works.

On 16/01/2024 01:04, bart wrote:
> On 15/01/2024 23:28, Kaz Kylheku wrote:
>> On 2024-01-15, bart <bc@freeuk.com> wrote:
>>>      c:\c>copy hello.c c_code_main
>>>           1 file(s) copied.
>>
>> There goes that damned AT&T instruction syntax for file copying, same
>> like in Unix.
>>
>> Doesn't it bother you that it isn't: copy destination source?
>
> I haven't said anything about in which direction the data goes.
>
> This is something that tends to depend on device, so Motorola went left
> to right, and Zilog/Intel went right to left.
>
> So it did seem odd for this x86 assembler to do the opposite of Intel.
>
> However, doesn't it bother /you/ that AT&T also does the opposite of not
> only how assignment works in C, but in most languages? That would be
> more pertinent than somebody's choices of command-line syntax.
>

AFAIUI, AT&T syntax was first for the PDP11, which used left to right
direction. It was later modified and adopted for x86 before Intel had
actually made a good assembly syntax (AFAIK).

I think it has become more common to use right-to-left ordering for
assemblies, but there has never been a real consensus.

In the early days, different groups made their own assemblers, and
sometimes their own assembly language or mnemonics. Certainly they
would use their own choice of directives and other syntax, keeping them
the same as they had for other targets. And if you already make
assemblers that have left-to-right syntax, then it makes sense to keep
that for new targets - it means more re-use of your assembler source
code, and more familiarity for users who deal with multiple targets.
The majority of people working on assembly code for the x86 on *nix
systems (at least early on) would have been familiar with the AT&T
syntax for PDP11, m68k, or other processors - keeping the same style for
x86 made their life easier.

Given a completely free choice, I'd probably choose Intel format for x86
rather than AT&T. But since I don't write x86 assembly, and can read
either format on godbolt, I don't mind much either way.

And given a completely free choice to design a new assembly language for
a processor (pre-existing or new), I think I'd go for a right-to-left
assignment. As you say, it fits better with most programming languages
(other than Forth, Cobol, and some programmable calculator languages).

As for other things like the % before register names - well, you either
have to have special markings for register names or you have to have
special marking for external symbols (at least those from HLL's that
don't carefully avoid clashes with register names). No choice is going
to be perfect for everyone's tastes.

On 15/01/2024 21:27, Chris M. Thomasson wrote:
> On 1/15/2024 8:29 AM, David Brown wrote:
>> 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.
> [...]
>
> Wrt inline GCC assembly, remember __volatile__ and memory? ;^)
>

Yes, these are useful, and I use them - when appropriate.

On 16/01/2024 03:18, Chris M. Thomasson wrote:
> On 1/15/2024 3:24 PM, Kaz Kylheku wrote:
>> On 2024-01-15, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> On 1/15/2024 8:29 AM, David Brown wrote:
>>>> 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.
>>> [...]
>>>
>>> Wrt inline GCC assembly, remember __volatile__ and memory? ;^)
>>
>> The volatile is only important if you're writing sync primitives, so the
>> compiler won't move loads or stores to one side or the other of the
>> inline assembly.

That is not what "volatile" means - either in normal C code, or for gcc
inline assembly!

>> If you're just doing some calculation, it's
>> counterproductive to tell the compiler not to move the code.
>>
>> "memory" is only needed if your inline code clobbers memory. E.g.
>> one of the operands is a pointer, and the code writes through it.
>> That location isn't one of the output operands.
>>
>
> I want my sync primitive code to be _un_abused by any "clever"
> optimizations. I want it is as it is.

What a strange idea!

I want the compiler to be clever and optimise code. But I want to tell
the compiler enough about my inline assembly so that it can optimise
appropriately.

For synchronisation inline assembly, a "memory" clobber is often
required - but usually it is not enough on its own (you need memory
barrier assembly instructions too). And for lots of other uses of
inline assembly, you don't want memory clobbers as they can be costly -
sometimes very wasteful.

"volatile" on inline assembly tells the compiler that the code may use
or cause side-effects other than just what it is told by the inputs,
outputs and clobbers. It will enforce an ordering with respect to other
volatile inline assembly, and other C volatile accesses - but it will
not be ordered with respect to other calculations, non-volatile inline
assembly, or non-volatile loads and stores.

You might think that using "volatile" and a "memory" clobber stops any
re-ordering of code in relation to your inline assembly, but you'd be
wrong. And if you think that, then perhaps an external assembly file is
the easiest way to get the guarantees you want.

> No rouge compiler thinking that
> link-time optimizations are all fun and joy, lets dance around the sync
> instructions... Step on them, ruin them, make them incorrect. Even GCC
> had a nasty error with an optimization wrt Pthread
> pthread_mutex_trylock(). Simply ruined is correctness wrt the standard.
>

You've mentioned this many times - do you have a reference that gives
the source of this function (at the time when there was an issue), and a
description or report of what you think gcc did wrong? I am curious as
to whether it was a bug in the code or a bug in gcc (gcc is certainly
not bug-free).

On 16/01/2024 12:54, bart wrote:
> On 15/01/2024 16:29, David Brown wrote:
>> 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]"
>
> Which processor is this for again?
>

It's for a cpu with a "madd" instruction that implements "x = x + y * z"
in a single instruction - as Kaz pointed out, doing this in inline
assembly would make sense if it the cpu had such a dedicated
instruction. Inline assembly is typically used in such situations,
where the processor has a more efficient instruction sequence than the
compiler can generate.

But this mythical cpu uses Intel-style assembly syntax, for your
convenience :-)

On 16/01/2024 12:30, bart wrote:
> On 16/01/2024 01:21, Kaz Kylheku wrote:
>> On 2024-01-15, bart <bc@freeuk.com> wrote:
>
> [Inline assembly]
>
>> The instruction template is just a string literal to the
>> compiler. It specifies text to be inserted into the assembly
>> output.
>>
>> Some assembly languages require the whitespace; you need
>> instructions to be on separate lines.
>>
>> GCC does not look inside this template other than to replace
>> % codes like %0 (the first register).
>>
>> In my example, I put the newlines and tabs together on the right
>>
>>    "imul %3, %2\n\t"
>>    "add %1, %2\n\t"
>>    "mov %1, %0\n\t"
>>
>> Thanks to these newlines and tabs, the textual output (generated .s
>> file if we use gcc -S) has this in it:
>>
>> #APP
>> # 24 "inline.c" 1
>>          imul %edx, %esi
>>          add %esi, %edi
>>          mov %edi, %edi
>>
>> # 0 "" 2
>> #NO_APP
>>          movl    8(%rsp), %eax
>>          movl    16(%rsp), %edx
>>
>
> This is still peculiar: why prioritise the appearance of the
> intermediate code which I assume you're rarely going to look at?

It's often just habit. The tab character is entirely unnecessary, at
least for gas (other assemblers may complain about instructions
appearing at the start of the line). You do need some kind of
separation between the assembly instructions - if you don't use "\n",
then you could also use ";" (again, I know it works for gas). "\n\t" is
a common habit, however, and has the benefit of looking nice if you
examine the generated assembly - and if you are working with inline
assembly, sometimes that is a very useful thing to check.

>
> It's the version with strings and escape codes that you're going to be
> writing and maintaining, and that people will see in the C sources!
>

Well, you don't often write inline assembly - its rare to write it.
It's typically the kind of thing you write once for your particular
instruction, then stick it away in a header somewhere. You might use it
often, but you don't need to read or edit the code often.

In reality, you don't even often write the inline assembly yourself -
you include a manufacturer-supplied header full of "intrinsics" - small
inline assembly functions wrapping useful assembly instructions.

The whole thing would be nicer if C (or at least gcc) supported a
multi-line string syntax akin to Python's """ ... """ syntax. But it
doesn't. (Actually, such an extension could be very useful for lots of
things.)

>>> Just admit that my approach to inline assembler is better and give it
>>> up.
>>
>> Your approach to inline assembler has nicer looking syntax, but
>> semantically, it doesn't seem to be on same level as the GCC approach.
>>
>> GCC's inline assembly does nice things that are might not be possible
>> in your
>> implementation. (Or pretty much anyone else's).
>>
>> Some of it has been sufficiently exemplified elsewhere in the thread.
>>
>> GCC can choose registers for your inline assembly block,
>
> The point of ASM is that /you/ call the shots.

No.

The point of inline assembly is to do something that you can't do in C
alone (even with compiler extensions).

>
> It's not just more natural syntax, but better integration within the
> host language. More example, I can 'goto' to a label within an ASSEM
> block, and 'jmp' out of the ASSEM block to a HLL label, or to an label
> within a separate ASSEM block further on.
>

You can "goto" C labels in gcc inline assembly. I can't imagine much
real-world use for it, but you can do it. (You use "asm goto" and pass
the labels into the assembly expression.)

I think you are viewing inline assembly as a verbatim list of
instructions inserted blindly into the code generated by the compiler.
I view it more like an expression that fits into the flow of the C code,
and the flow of the generated code. It is working /with/ the compiler,
not /against/ it.

>> and will automatically
>> move between those registers and the operands they are connected to (if
>> necessary). The inline code seamlessly integrates with the code
>> generated by
>> the compiler.  You can write primitives that generate code as well as
>> compiler
>> built-ins.
>
> OK. But it's not an 'assembler' as is generally understood. Mine is; it
> looks exactly line normal assembly, and it is written inline to the HLL.
>

Exactly. gcc inline assembly is inline assembly - it is not an
assembler. (gcc also supports what it calls "basic assembly syntax" -
you create a "naked" function and give a list of assembly instructions.
This is typically used for things like specialised startup code in a
microcontroller, or for task switching in an RTOS.)

> Although these days I keep such hybrid functions within their own modules.
>

It's always good to keep things like this tidied away.