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

>> 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.
>
> Not reasonably so. The parser of every front end would have to have
> a special case for that assembly language.
>
> The proposal does not pass a cost/benefit analysis, due to the
> high cost and low benefit.
>
>> 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{...}.
>
> keywords and tokens are grammar.

So how does the grammar of HTML work: does it also include the entire
grammar of JavaScript?

JS appears inside <script> ... </script> tags.

My assemble appears in a 'assem ... end block', or there's a one-liner
version which starts with 'asm'.

When my parser sees 'assem' or 'asm', it calls one of these functions:

if lx.subcode=0 then
p:=readassemline()
else
p:=readassemblock()
fi

They are in a 250-line module that deals with assembly. They return an
'assem' AST node.

Now, my assembly syntax is not Intel, just Intel style, and is flavoured
with elements of my HLL syntax (so uses 'u32' for example rather than
'dword').

There is a separate set of tables within the target-specific backend,
which contains all the supported x64 opcodes and registgers for example.
This part is needed anyway to generate x64 native code, whether assembly
source or binary.

When the global symbol table is initialised, the contents of those
opcode and register tables are added to it.

It's done in a way so that, if not in an ASM block, those can be used as
normal identifiers:

int mov, rax, push

mov := rax + push

If I wanted to refer to those from inline assembly, I have to escape them:

asm push [`push]

So, with a different architecture, I have a different backend and
different set opcode and register names.

The 250-line parsing module could possibly be made to deal with more
than one target, otherwise it's not a great imposition.

This stuff needn't be that hard. There just seems unwillingness to make
things easy and sensible.

Perhaps in a world full of C macros, makefile syntax and bash scripts,
the assembly syntax isn't considered too outre.

But, you say assembly isn't used much; have you considered that that
might be because it's such a pig to use?

> How things look does become important when you are writing tens of
> thousands of lines of code.

But not thousands, or even hundreds? Or dozens? Code can always benefit
from being readable and also not being painful to type.

Personally I think /any/ conventional assembly looks dreadful in even
small amounts, including mine. But gcc-style is a LOT worse.

On 1/16/2024 5:38 AM, David Brown wrote:
> 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:
[...]
>> 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).

It was a bug in GCC itself. It was posted over on
comp.programming.threads. Just of the top of my head, it was from a
smart guy by the name of David Schwartz... I probably butchered his last
name wrt spelling! I just need to find it again. Argh.

I created my own externally assembled sync primitives because, well, I
wanted to try to make sure no compiler can mess around with them. One
little mistake and is does not work at all.

On 1/16/2024 6:06 AM, David Brown wrote:
> 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.[...]

As soon as you use inline assembler in a file, you sort of "need" to?
Alter the name of the file, or add in sufficient comments that says this
is arch specific! Damn it. ;^) Ahhh, bust out the macros.

ct_foo.c becomes ct_foo_i686.c ?

;^D Been there done that...

On 1/16/2024 5:38 AM, David Brown wrote:
> 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:
[...]
> 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).
>

I think I found it David!

https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ

On 2024-01-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 1/16/2024 5:38 AM, David Brown wrote:
>> 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:
> [...]
>> 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).
>>
>
> I think I found it David!
>
> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ

David Schwartz has since been acquired by and merged with David
Butenhoff, to form David Schwartzenhoff. The new motto is "bigger living
through slightly less concurrency".

--
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/16/2024 5:08 PM, Chris M. Thomasson wrote:
> On 1/16/2024 5:38 AM, David Brown wrote:
>> 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:
> [...]
>> 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).
>>
>
> I think I found it David!
>
> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>
>
>
>

Here is a nice quote from Dave Butenhof in that thread:
____________________________

Dave Butenhof's profile photo
Dave Butenhof
Nov 15, 2007, 3:12:14 PM
to
Chris Thomasson wrote:
> "Zeljko Vrba" <zvrba....@ieee-sb1.cc.fer.hr> wrote in message
> news:slrnfjnt6l...@ieee-sb1.cc.fer.hr...
>> On 2007-11-14, Chris Thomasson <cri...@comcast.net> wrote:
>>>
>>> If GCC performs the optimization that David Schwartz pointer out, your
>>> basically screwed. AFAICT, GCC is totally busted if it allows stores to
>>> escape a critical-section. This is a race-condition waiting to
>>> happen. I am
>>>
>> How is the compiler supposed to know where a CS begins and ends? should
>> it have a knowledge of every imaginable official and unofficial API?
>
> I was under the impression that POSIX puts some restrictions on
> compilers. Humm... I can't really remember where I heard that right now,
> but I sure think I did. Humm...
The point is that POSIX puts restrictions on the behavior of a
conforming system. That includes library, kernel, and compiler. If the
RESULT doesn't behave like POSIX, then it's not POSIX.

A compiler that's part of a conforming POSIX system environment can't
generate code that breaks synchronization. How it and the rest of the
system accomplish that is unspecified.

Often, it means simply not performing risky optimizations. But if they
are enabled, then the system needs to be able to detect and avoid
performing them in "dangerous" areas of code. (A complicated problem,
but nothing's impossible.)
____________________________

On 2024-01-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 1/16/2024 5:08 PM, Chris M. Thomasson wrote:
>> On 1/16/2024 5:38 AM, David Brown wrote:
>>> 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:
>> [...]
>>> 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).
>>>
>>
>> I think I found it David!
>>
>> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>>
>>
>>
>>
>
> Here is a nice quote from Dave Butenhof in that thread:
> ____________________________
>
> Dave Butenhof's profile photo
> Dave Butenhof
> Nov 15, 2007, 3:12:14 PM
> to
> Chris Thomasson wrote:
> > "Zeljko Vrba" <zvrba....@ieee-sb1.cc.fer.hr> wrote in message
> > news:slrnfjnt6l...@ieee-sb1.cc.fer.hr...
> >> On 2007-11-14, Chris Thomasson <cri...@comcast.net> wrote:
> >>>
> >>> If GCC performs the optimization that David Schwartz pointer out, your
> >>> basically screwed. AFAICT, GCC is totally busted if it allows stores to
> >>> escape a critical-section. This is a race-condition waiting to
> >>> happen. I am
> >>>
> >> How is the compiler supposed to know where a CS begins and ends? should
> >> it have a knowledge of every imaginable official and unofficial API?
> >
> > I was under the impression that POSIX puts some restrictions on
> > compilers. Humm... I can't really remember where I heard that right now,
> > but I sure think I did. Humm...
> The point is that POSIX puts restrictions on the behavior of a
> conforming system. That includes library, kernel, and compiler. If the
> RESULT doesn't behave like POSIX, then it's not POSIX.
>
> A compiler that's part of a conforming POSIX system environment can't
> generate code that breaks synchronization. How it and the rest of the
> system accomplish that is unspecified.
>
> Often, it means simply not performing risky optimizations. But if they
> are enabled, then the system needs to be able to detect and avoid
> performing them in "dangerous" areas of code. (A complicated problem,
> but nothing's impossible.)

Basically, the optimization can only be performed when the value
which controls the selection statement can be shown not to have
been derived from the result of a pthread function, such that the value
indicates whether the caller owns or does not own a lock.

This is very difficult.

Even a value scanned from a stream can be such a value:

int result = pthred_mutex_trylock(...);

FILE *f = fopen("foo.txt", "w");
fprintf(f, "%d\n", result);
fclose(f);
system("mv foo.txt bar.txt");

int x;
FILE *g = fopen("bar.txt", "r");
fscanf(g, "%d", &f);
fclose(g);

if (x == 0) {
a++;
}

A better angle on it would be not to pursue the analysis of x at all,
but concentrate on a. If the variable a isn't something that can be
thread shared, then the optimization is okay.

If a is a local variable whose address has never been taken (or
else has never escaped from this scope), then it's should be
to convert this to:

int __inc = (x == 0);
a += __inc;

If a is something potentially shared, then no.

Programs that want good optimization should concentrate on using
automatic (not static) local variables as much as possible, in such a
way that it's clear that those variables don't escape into other scopes.
Those kinds of variables can be aggressively optimized, threads or not.

--
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/16/2024 7:03 PM, Kaz Kylheku wrote:
> On 2024-01-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> On 1/16/2024 5:08 PM, Chris M. Thomasson wrote:
>>> On 1/16/2024 5:38 AM, David Brown wrote:
>>>> 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:
>>> [...]
>>>> 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).
>>>>
>>>
>>> I think I found it David!
>>>
>>> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>>>
>>>
>>>
>>>
>>
>> Here is a nice quote from Dave Butenhof in that thread:
>> ____________________________
>>
>> Dave Butenhof's profile photo
>> Dave Butenhof
>> Nov 15, 2007, 3:12:14 PM
>> to
>> Chris Thomasson wrote:
>>> "Zeljko Vrba" <zvrba....@ieee-sb1.cc.fer.hr> wrote in message
>>> news:slrnfjnt6l...@ieee-sb1.cc.fer.hr...
>>>> On 2007-11-14, Chris Thomasson <cri...@comcast.net> wrote:
>>>>>
>>>>> If GCC performs the optimization that David Schwartz pointer out, your
>>>>> basically screwed. AFAICT, GCC is totally busted if it allows stores to
>>>>> escape a critical-section. This is a race-condition waiting to
>>>>> happen. I am
>>>>>
>>>> How is the compiler supposed to know where a CS begins and ends? should
>>>> it have a knowledge of every imaginable official and unofficial API?
>>>
>>> I was under the impression that POSIX puts some restrictions on
>>> compilers. Humm... I can't really remember where I heard that right now,
>>> but I sure think I did. Humm...
>> The point is that POSIX puts restrictions on the behavior of a
>> conforming system. That includes library, kernel, and compiler. If the
>> RESULT doesn't behave like POSIX, then it's not POSIX.
>>
>> A compiler that's part of a conforming POSIX system environment can't
>> generate code that breaks synchronization. How it and the rest of the
>> system accomplish that is unspecified.
>>
>> Often, it means simply not performing risky optimizations. But if they
>> are enabled, then the system needs to be able to detect and avoid
>> performing them in "dangerous" areas of code. (A complicated problem,
>> but nothing's impossible.)
>
> Basically, the optimization can only be performed when the value
> which controls the selection statement can be shown not to have
> been derived from the result of a pthread function, such that the value
> indicates whether the caller owns or does not own a lock.
>
> This is very difficult.
>
> Even a value scanned from a stream can be such a value:
>
> int result = pthred_mutex_trylock(...);
>
> FILE *f = fopen("foo.txt", "w");
> fprintf(f, "%d\n", result);
> fclose(f);
> system("mv foo.txt bar.txt");
>
> int x;
> FILE *g = fopen("bar.txt", "r");
> fscanf(g, "%d", &f);
> fclose(g);
>
> if (x == 0) {
> a++;
> }
>
> A better angle on it would be not to pursue the analysis of x at all,
> but concentrate on a. If the variable a isn't something that can be
> thread shared, then the optimization is okay.
>
> If a is a local variable whose address has never been taken (or
> else has never escaped from this scope), then it's should be
> to convert this to:
>
> int __inc = (x == 0);
> a += __inc;
>
> If a is something potentially shared, then no.
>
> Programs that want good optimization should concentrate on using
> automatic (not static) local variables as much as possible, in such a
> way that it's clear that those variables don't escape into other scopes.
> Those kinds of variables can be aggressively optimized, threads or not.
>
>

Fwiw, I created my own externally assembled sync primitives to try to
get around a "rogue" compiler from altering anything within them. Link
time optimizations could get at my code... Turn them off? Well, this was
some years ago.

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

Exactly. I could get inline asm to work with my sync code, but since I
disliked inline asm and MS dropped support for it for 64-bit targets
around the time, I felt _much_ safer to implement my sync code in
external assembly, trying to isolate them from the meat hooks of the
compiler.

Also, I would check the generated asm from any of my inline asm to make
sure it was correct. This was a pain in the ass.

On 16.01.2024 16:45, David Brown wrote:
>
> Default fallthrough switch behaviour is different in that it is
> potentially counter-productive and dangerous. As someone who uses good
> tools, and knows how to use them, it is not an issue for my own code -
> but it can be a source of error in other people's code.

It can also just be a useful code pattern, as in Duff's Device.

> I can imagine bugs in real, released code as a result of default
> fallthrough in switches. [...]

Janis

On 16.01.2024 16:57, Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 16.01.2024 14:42, David Brown wrote:
>>> On 16/01/2024 12:54, bart wrote:
>>>>
>>>> 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. [...]
>>
>> I recall such a feature from a 35+ years old assembler project I did.
>> It was on the TI TMS320C25 DSP, and the instruction was called 'MAC'
>> (Multiply and ACcumulate). - Not sure it clarifies anything but just
>> as an amendment if someone is interested in searching for keywords
>> on such a function.
>
> Pretty much every modern architecture has multiply and accumulate
> instructions, even the ARM Cortex-M7 cores (MLA instruction).

Yeah, I inferred that already from David's response. At these days,
though, I hadn't seen 'MAC' in the common standard CPUs. (And since
that time I didn't do any assembler any more, so I don't know the
contemporary architectures.)

It's maybe noteworthy that despite such advanced CPU functions I
didn't make use of them, despite I had functions like sum(x[i]*y[i])
to implement. The reason was that an algorithmic transformation,
an optimization, made use of that 1-cycle MAC an inferior solution!

Janis

On 16.01.2024 18:46, David Brown wrote:
> On 16/01/2024 16:15, bart wrote:
>>
>> The need for assembly usually trumps whatever minor optimisation my
>> compiler might do.

The good thing is that compilers do also major optimizations.
(And the minor ones come for free.)

But the most important insight is that tackling complexity
algorithmically is what is most contributing for speed.

(This may be different for folks fiddling only on assembler
level, where _separate_ assembler projects serve better.
It's IMO more sensible for time critical stuff to just use
an assembler for such functions and embed them by a clean
function interface in any HLL than to inline assembler code.
YMMV.)

>
> Ah, there we differ. I use tools that do good optimisations. And
> perhaps 70% of the use-cases of inline assembly will be lost if the tool
> can't generate efficient code when there is inline assembly.

Janis

On 16.01.2024 19:03, David Brown wrote:
>
> [...], because they know that Norwegians are superior to Swedes in every way...

I just wanted to reply on that but then I saw your email address... :-)

Janis

On 1/1/2024 5:14 PM, Bart wrote:
[...]

If you have a recent version of MSVC installed, give vcpkg a go. It has
a lot of packages that will be automagically build and integrated into MSVC:

https://vcpkg.io/en/packages

On 17/01/2024 06:01, Janis Papanagnou wrote:
> On 16.01.2024 16:45, David Brown wrote:
>>
>> Default fallthrough switch behaviour is different in that it is
>> potentially counter-productive and dangerous. As someone who uses good
>> tools, and knows how to use them, it is not an issue for my own code -
>> but it can be a source of error in other people's code.
>
> It can also just be a useful code pattern, as in Duff's Device.
>

No.

Fallthrough switch behaviour can be useful (and not in the monstrosity
that is Duff's Device, but mostly when you have multiple switch cases
that are handled by the same code).

/Default/ fallthrough switch behaviour is not good.

If you want fallthrough, label it with "[[fallthrough]]", or a comment
or other technique recognised by your tools and by your fellow programmers.

>> I can imagine bugs in real, released code as a result of default
>> fallthrough in switches. [...]
>
> Janis
>

On 12/01/2024 16:50, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/01/2024 13:40, David Brown wrote:
>>> On 12/01/2024 00:20, bart wrote:
>>
>> But with 'as', it just sits there. I wonder what it's waiting for; for
>> me to type in ASM code live from the terminal?
>
> It does that so you can pipe the assembler source code in to the
> assembler.
>
> $ cat file.s | as
>
> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
> or, if you want, you can type in the assembler source directly.
>
> Or you can save it in a file and supply the file argument to the command.
>
> None of which your stuff supports, which makes it useless to me.

I had a spare 15 minutes so I got my scripting language to do this:

csource:=(
"#include <stdio.h>",
"int main(void) {",
" puts(""Fahrenheit 451"");",
"}")

csource -> mcc -> aa -> run

'mcc' turns a source string (or a list of strings as here) into a string
containing assembly code.

'aa' turns an assembly string into a string containing binary PE data.

'run' runs that PE data. Output is:

Fahrenheit 451

Those 3 functions are 40-50 lines. Here's another invocation:

readstrfile("/c/hello.c") -> mcc -> aa -> run

A shell seems to be a poor man's scripting language.

On 17.01.2024 11:44, David Brown wrote:
> On 17/01/2024 06:01, Janis Papanagnou wrote:
>> On 16.01.2024 16:45, David Brown wrote:
>>>
>>> Default fallthrough switch behaviour is different in that it is
>>> potentially counter-productive and dangerous. As someone who uses good
>>> tools, and knows how to use them, it is not an issue for my own code -
>>> but it can be a source of error in other people's code.
>>
>> It can also just be a useful code pattern, as in Duff's Device.
>>
>
> No.
>
> Fallthrough switch behaviour can be useful (and not in the monstrosity
> that is Duff's Device, but mostly when you have multiple switch cases
> that are handled by the same code).

I don't think that multiple case-labels are the interesting part;
they are just a bulky syntactic way to collect items - compare
that [syntactically] with case statements in other languages (e.g.
in Pascal). In many (most? all?) C based language, OTOH, you have
to identify every single value by a 'case' keyword, and you also
_have_ to use an explicit 'break' to not "fall through". The fall
through logic is interesting (sort of) if you want to "re-use"
code from other case labels. - Not that this feature would make
any program easier to maintain. (I would avoid that.)

The use of "code patterns" (like the mentioned Duff's Device) is
often an indication to support features that the language doesn't
natively support; I see them often (for example) in Awk. It's not
something I would strive for in cleanly written software. But it's
usable as an idiomatic expression for a subset of (specific) tasks.
YMMV.

>
> /Default/ fallthrough switch behaviour is not good.

But this is the case with C-based languages; we have to accept it,
and, again _idiomatically_, write an explicit 'break' after every
'case' statement sequence.

(But we're here in a C newsgroup and complaints make no sense.)

>
> If you want fallthrough, label it with "[[fallthrough]]", or a comment
> or other technique recognised by your tools and by your fellow programmers.

This is indeed what I do on these rare conditions where I use it.

In other languages it's even more hidden (than a missing 'break');
Kornshell for example uses ;; for a "break" logic and ;& for the
(fall-through) "continue" logic in its 'case' statements. (And
'break [N]' and 'continue [N]' have another logical context (used
only in loops).

>>> I can imagine bugs in real, released code as a result of default
>>> fallthrough in switches. [...]

Janis

On 16/01/2024 22:06, bart wrote:
> On 16/01/2024 20:09, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 15/01/2024 11:45, David Brown wrote:
>>>> On 12/01/2024 18:09, bart wrote:
>>
>>> (BTW that keyboard was a joy to use: it used a simple 8-bit port, with
>>> the top bit strobing when a key was ready. Compare with what's involved
>>> with using a USB keyboard today, if you didn't have a 10GB OS to take
>>> care of it.)
>>
>> If you ignore,  of course, the fact that a 64KB BIOS can easily handle
>> the entire USB stack sufficient to support both USB mass storage
>> devices, networking devices (PXE) and USB Human Interface Devices
>> (keyboards, mice).
>>
>> No 10GB OS involvement.
>>
>
> It seemed to take quite a few years before the early Linuxes I played
> around with 25+ years ago managed to support USB, among other things.

At that time, device support on Linux was very limited. But it took
off, and since perhaps 15 years ago it is rarely an issue in practice.
Out of the box support is certainly a world ahead of Windows, and new
buses (such as new USB speeds) are always supported first on Linux.

The last time I had trouble with USB and keyboards was something like 5
or 6 years ago - with Windows. It was a Dell server, where all the USB
ports were USB 3. The keyboard and mice were fine in the BIOS and Dell
setup stuff, but partway through the Windows Server installation,
Windows wanted to move to its own system and drivers - and did not have
USB 3 support out the box. It was an utterly absurd situation where the
installation process needed an extra drivers disk from Dell just to get
the keyboard working, even though it worked fine in the first part of
the installation. (And needless to say, Linux had no issues with it.)

>
> So it's only easy if you know how. Reading the current key on the Z80
> (already in ASCII) was one IN instruction.

Making support for USB keyboards (either as host or device) on modern
microcontrollers isn't bad, assuming you have basic USB libraries for
your device. It's certainly much more involved than it used to be - but
it is also more flexible.

On 17/01/2024 02:08, Chris M. Thomasson wrote:
> On 1/16/2024 5:38 AM, David Brown wrote:
>> 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:
> [...]
>> 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).
>>
>
> I think I found it David!
>
> https://groups.google.com/g/comp.programming.threads/c/Y_Y2DZOWErM/m/nuyEoKq0onUJ
>

Looking at the start of that thread:

int trylock()
{ int res;
res = pthread_mutex_trylock(&mutex);
if (res == 0)
++acquires_count;
return res;
}

It is perfectly reasonable for a pre-C11 C compiler to change that to:

int trylock()
{ int res;
res = pthread_mutex_trylock(&mutex);
int x = acquires_count;
if (res == 0)
++x;
acquires_count = x;
return res;
}

That's the way C was defined, prior to C11 support for multithreading
environments. The compiler could assume that it alone had full control
over all data, unless it was defined as volatile. So to make this code
"correct" (according to the user's hopes) in pre-C11, "acquires_count"
must be volatile.

C11 disabled such optimisations, because they could introduce data races
that did not exist before. But C11 was not around at that time. So
having this optimisation was not a gcc bug - unless POSIX precluded such
optimisations and gcc was used in a POSIX-compatibility mode. (I don't
know the details of POSIX requirements.)

On 17/01/2024 02:04, Chris M. Thomasson wrote:
> On 1/16/2024 6:06 AM, David Brown wrote:

>> 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.[...]
>
> As soon as you use inline assembler in a file, you sort of "need" to?

Nonsense.

How often do you use headers from the standard library, or third party
libraries, or other code? All the time, I'd assume. How often do you
read through these headers? Very rarely. How often do you edit them?
Never.

You do not need to read code of any kind, in order to use it.

Some kinds of code can be considered advanced, or ugly, or hard to
comprehend. inline assembly often falls into that category, as do
complicated macros, and some of the more cryptic corners of C++. That
code should be written by someone who knows what they are doing, tested
well, the interface described, and then the code is hidden away. Most
other people using the code never see it, and might not understand it
even if they did.

It is entirely reasonable to structure your headers like this:

// Return x + (y * z)
static inline int madd(int x, int y, int z);

...

// Implementation details
static inline int madd(int x, int y, int z) {
asm (...

On 17/01/2024 12:21, Janis Papanagnou wrote:
> On 17.01.2024 11:44, David Brown wrote:
>> On 17/01/2024 06:01, Janis Papanagnou wrote:
>>> On 16.01.2024 16:45, David Brown wrote:
>>>>
>>>> Default fallthrough switch behaviour is different in that it is
>>>> potentially counter-productive and dangerous. As someone who uses good
>>>> tools, and knows how to use them, it is not an issue for my own code -
>>>> but it can be a source of error in other people's code.
>>>
>>> It can also just be a useful code pattern, as in Duff's Device.
>>>
>>
>> No.
>>
>> Fallthrough switch behaviour can be useful (and not in the monstrosity
>> that is Duff's Device, but mostly when you have multiple switch cases
>> that are handled by the same code).
>
> I don't think that multiple case-labels are the interesting part;
> they are just a bulky syntactic way to collect items - compare
> that [syntactically] with case statements in other languages (e.g.
> in Pascal). In many (most? all?) C based language, OTOH, you have
> to identify every single value by a 'case' keyword, and you also
> _have_ to use an explicit 'break' to not "fall through". The fall
> through logic is interesting (sort of) if you want to "re-use"
> code from other case labels. - Not that this feature would make
> any program easier to maintain. (I would avoid that.)
>
> The use of "code patterns" (like the mentioned Duff's Device) is
> often an indication to support features that the language doesn't
> natively support; I see them often (for example) in Awk. It's not
> something I would strive for in cleanly written software. But it's
> usable as an idiomatic expression for a subset of (specific) tasks.
> YMMV.

Of course different people have different styles and needs. For my own
use, I vastly prefer to write the code as cleanly as possible and let
the optimiser generate code roughly like Duff's Device if that's the
most efficient. But other people have other requirements and preferences.

>
>>
>> /Default/ fallthrough switch behaviour is not good.
>
> But this is the case with C-based languages; we have to accept it,
> and, again _idiomatically_, write an explicit 'break' after every
> 'case' statement sequence.
>

I accept it, but dislike it and make sure my tools will warn me if there
is unintentional default fallthrough.

> (But we're here in a C newsgroup and complaints make no sense.)
>

Hey - without complaints, this newsgroup would be almost empty :-)

>>
>> If you want fallthrough, label it with "[[fallthrough]]", or a comment
>> or other technique recognised by your tools and by your fellow programmers.
>
> This is indeed what I do on these rare conditions where I use it.
>
> In other languages it's even more hidden (than a missing 'break');
> Kornshell for example uses ;; for a "break" logic and ;& for the
> (fall-through) "continue" logic in its 'case' statements. (And
> 'break [N]' and 'continue [N]' have another logical context (used
> only in loops).
>
>>>> I can imagine bugs in real, released code as a result of default
>>>> fallthrough in switches. [...]
>
> Janis
>

On 17/01/2024 07:11, Janis Papanagnou wrote:
> On 16.01.2024 19:03, David Brown wrote:
>>
>> [...], because they know that Norwegians are superior to Swedes in every way...
>
> I just wanted to reply on that but then I saw your email address... :-)
>

I'm Scottish by origin, but have lived in Norway for about 30 years. So
I am a Norwegian by practice (and citizenship) rather than birth.

(Norway and Sweden view each other as "brother" countries, with very
close ties and cooperation, but also good-natured rivalry and occasional
teasing.)

On 16/01/2024 23:42, bart wrote:
> On 16/01/2024 17:46, David Brown wrote:
>> On 16/01/2024 16:15, bart wrote:
>
>> void swap_lots(const uint32_t * restrict in, uint32_t * restrict out,
>> uint32_t n) {
>>      while (n--) {
>>          *out++ = swapEndian32(*in++);
>>          *out++ = swapEndian32(*in++);
>>          *out++ = swapEndian32(*in++);
>>          *out++ = swapEndian32(*in++);
>>      }
>> }
>
> What's 'n' here? Are 4n bytes being transformed, or 16n?

In this case, 4n 32-bit words. It's just example code to demonstrate a
point, not to be a particularly useful function in reality.

>
>>> My function would be this on x64 (although I don't support bswap):
>>>
>>>     fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
>>>
>>
>> And how efficient would your "swap_lots" function be?
>
> How do you measure efficiency? This task seems memory-bound anyway.
>

That will depend on the sizes, cache, etc., as well as the target. The
target I was using here is a Cortex M7 - with data in tightly-coupled
memory that runs at core speed, it would not be memory bound.

Efficiency is measured in clock cycles. (It can also be measured in
code size, but that's usually not as important. If it were, we would
not be doing manual loop unrolling here.)

> Using exactly that function (I now support 'bswap'), I can process a
> 100M-element u64 array (0.8GB) in .35 seconds, or 2.3GB/second.
>

On what target? Do you have an ARM Cortex-M microcontroller for testing
this?

Using a built-in bswap function kind of defeats the point of using
inline assembly. gcc has __builtin_bswap32 too, or it can be written
manually in C and optimised by the compiler to "rev" instructions. The
point is a demonstration of how gcc's inline assembly can work with the
optimiser for surrounding code, not how fast your PC can swap endianness!

On 17/01/2024 13:25, David Brown wrote:
> On 16/01/2024 23:42, bart wrote:
>> On 16/01/2024 17:46, David Brown wrote:
>>> On 16/01/2024 16:15, bart wrote:
>>
>>> void swap_lots(const uint32_t * restrict in, uint32_t * restrict out,
>>> uint32_t n) {
>>>      while (n--) {
>>>          *out++ = swapEndian32(*in++);
>>>          *out++ = swapEndian32(*in++);
>>>          *out++ = swapEndian32(*in++);
>>>          *out++ = swapEndian32(*in++);
>>>      }
>>> }
>>
>> What's 'n' here? Are 4n bytes being transformed, or 16n?
>
> In this case, 4n 32-bit words.  It's just example code to demonstrate a
> point, not to be a particularly useful function in reality.
>
>>
>>>> My function would be this on x64 (although I don't support bswap):
>>>>
>>>>     fun swapends64(u64 x)u64 = assem mov rax, [x]; bswap rax; end
>>>>
>>>
>>> And how efficient would your "swap_lots" function be?
>>
>> How do you measure efficiency? This task seems memory-bound anyway.
>>
>
> That will depend on the sizes, cache, etc., as well as the target.  The
> target I was using here is a Cortex M7 - with data in tightly-coupled
> memory that runs at core speed, it would not be memory bound.
>
> Efficiency is measured in clock cycles.  (It can also be measured in
> code size, but that's usually not as important.  If it were, we would
> not be doing manual loop unrolling here.)
>
>> Using exactly that function (I now support 'bswap'), I can process a
>> 100M-element u64 array (0.8GB) in .35 seconds, or 2.3GB/second.
>>
>
> On what target?  Do you have an ARM Cortex-M microcontroller for testing
> this?

I have an RPi4 somewhere; I only know it has a 64-bit ARM chip. ARM
processor and architecture models are mystery to me. My tests were done
on some AMD Ryzen device, probably bottom of the range.

(x64 processors are a bit of a mystery too! I just have little interest
beyond whether it's x64 or ARM64; I don't come across anything else.)

> Using a built-in bswap function kind of defeats the point of using
> inline assembly.

I didn't support 'bswap' at all. I first has to add it to my assembler,
then roll that out to the backend of my compiler.

This was necessary both to be able to use it in inline assembler, and
for the compiler backend to be able to deal with that instruction,
whatever had generated it.

So I wanted to know whether building it to the language in would be
worth doing, performance-wise (probably not). Although there are other
advantages of having it as an operator, since it could be used in-place
as 'bswap:=A[i]', and here it would be able to choose 32- and 64-bit
variations.

But it also highlighted issues with my inline assembler within macros
used to emulate inline functions, such as this:

macro byteswap(x) = assem mov rax, [x] ...

'x' can only be a simple variable at the invocation, not an arbitrary
expression like 'A[i]'. This suggested an enhancement:

assem (expr) ...

which first evaluates the expression to a known register. (I could just
do 'expr; assem ...' which /probably/ does the same, but it's risky.)

So doing the exercise helped in determining what might be a suitable
compromise. Although it would need explicit forms for 32- vs 64-bit
operations.

('assem(expr) ...' is also partway to doing what gcc asm{} does in
creating an interface, but retaining the same syntax.)

>  gcc has __builtin_bswap32 too, or it can be written
> manually in C and optimised by the compiler to "rev" instructions.  The
> point is a demonstration of how gcc's inline assembly can work with the
> optimiser for surrounding code, not how fast your PC can swap endianness!

It showed that using an actual function call, and not unrolling loops,
wasn't that slow, not on my PC.

bart <bc@freeuk.com> writes:
>On 16/01/2024 18:39, Kaz Kylheku wrote:
>> On 2024-01-16, bart <bc@freeuk.com> wrote:
>
>>> 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.
>>
>> Not reasonably so. The parser of every front end would have to have
>> a special case for that assembly language.
>>
>> The proposal does not pass a cost/benefit analysis, due to the
>> high cost and low benefit.
>>
>>> 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{...}.
>>
>> keywords and tokens are grammar.
>
>So how does the grammar of HTML work: does it also include the entire
>grammar of JavaScript?
>
>JS appears inside <script> ... </script> tags.

From the structured general markup language, or extensable markup
language (SGML/XML) perspective, anything between tags is completely
invisible. Semantics of any tag is Application dependent.

HTML (a non-proper subset of XML) applies semantics to
tags defined by HTML such as <script/>, <a/>, et alia.

An HTML interpreter interprets the tags and will pass the
data to the appropriate entity (in this case, a javascript
or ecmascript interpreter).