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.

Janis

On 15/01/2024 21:41, Scott Lurndal wrote:
> 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?
>

It would be a little surprising, but certainly possible. Sweden has had
been quite significant in the compiler world - IAR is a big name in
embedded toolchains, and they are Swedish.

You are sure you are not just one of these ignorant parochial Merican's
who think Norway is the capital of Sweden? :-)

On 15/01/2024 15:23, David Brown wrote:

> Let's look at an actual example from my own code, in an older project. I
> wanted an endian swap function on an ARM microcontroller, and for
> reasons that escape me for now, I did not want to use gcc's
> __builtin_bswap32, or an intrinsic from a header, or just plain C code
> (which modern gcc could optimise to a single "rev" instruction).  The
> code was probably originally written for quite an old version of the
> compiler.  So I wrote the function:
>
> static inline uint32_t swapEndian32(uint32_t x) {
>         uint32_t y;
>         asm ("rev %[y], %[x]" : [y] "=r" (y) : [x] "r" (x) : );
>         return y;
> }
>
> This is, IMHO, quite clear once you know that gcc assembly consists of
> the assembly template, the outputs, then the inputs.

Well, you've explained it. But I'm none the wiser. Let's break it down
better:

rev %[y], %[x] # rev appears to be an ARM instruction:
# rev Rdest, Rsource
[y] "=r" (y) # Outputs?
[x] "r" (x) # Inputs?

You're telling gcc that somehow, the value of x needs to get into a
register (since rev doesn't work on memory, or immediates). And that the
new value of y needs to come from a register.

The compiler will decide which registers to use, and insert them into
that instruction. And it will ensure that x is loaded into its register,
if it is not already in one; and that y is loaded from its register, if
it is not already in the prefered one.

Since this is a return value, it will likely use R0 anyway.

But I'm inferring this from the way I know that 'rev' must work, and
from your comments. You seem to be expending a lot of effort however
into explaining it to gcc.

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

This could have been shorter if 'bswap' had a separate dest register.
Here, knowing that x is always going to be rcx, I could have copied
straight from there, but would be bad form.

I think a useful enhancement to my scheme would be allow 'x' for example
to exist in static memory, stackframe, or in a register. The register
allocator for locals can be made to work with the assembly: it will only
choose registers that have not been used for anything else.

So, there are plenty of opportunities to make my scheme even better.

>  And it generates
> the code optimally - when used in an expression, there will be no extra
> moves, or data put on the stack, or wasted registers.  The compiler can
> move the code back and forth while optimising, eliminate calls when the
> result is used, and generally do its job just as well with this function
> as any other inline function or built in operator.
>
>>
>> You need to tell me, because I will otherwise not have a clue.
>
> It's clear that you haven't a clue.  So how can you justify ranting and
> raving against something you don't understand?

I'm been familiar with x86 assembly for 40 years, so I should expect to
understand it! But the answer is simple: what gcc provides is little to
do with x86, and 90% of it seems made up.

>> From what I've seen of gcc inline asm:
>>
>>   * Code has to be written within string literals,
>
> Yes, obviously.  Assembly is not C, so writing assembly mixed in your C
> requires it to be in a format that is acceptable in C syntax (or at
> least close enough to C syntax to be a non-invasive extension).  String
> literals are also quite amenable to generation by macros, for those that
> want to write something complicated.

So, how did I manage to get Intel-style assembly into my language? I
didn't need to use strings.

gcc should try harder!

>> in dreadfil AT&T
>>     syntax.
>
> "Dreadful" is, again, /your/ opinion - not shared by everyone.  (I
> personally don't care either way.)

This is the first hit for "at&t versus intel syntax":
https://imada.sdu.dk/u/kslarsen/dm546/Material/IntelnATT.htm

Its opinion is:

"The AT&T form for instructions involving complex operations is very
obscure compared to Intel syntax."

The second hit is from stackexchange and has the remark: "I personally
find "Intel syntax" much more readable, so that's why it surpises me."

The third hit is from stackoverflow, and starts: "To me, Intel syntax is
much easier to read."

The fourth hit offered no opinion (but chose to go with Intel).

The fifth is from Reddit and starts: "I'm curious whether more people
use Intel or AT&T syntax for x86_64 assembly language programming? I've
tried to use GNU GAS but found it a bit counterintuitive. On the other
hand, I used NASM, and it felt a lot better."

So, it's not just my opinion.

> It only applies to x86, not any
> other targets, and is easily changed by the "-masm=intel" flag

That's usually how I view gcc assembly output. But it still manages to
make it look terrible. Godbolt is much better as it filters out stuff
that is not relevant.

>> And apparently even with embedded \n line breaks. (Good
>>     grief - I think early 80s BASICs had more sophisticated facilities!)
>
> That is an inevitability for string literals.  And it doesn't matter
> much in practice, since most inline assembly (IME) consists of a single
> statement - gcc handles any moves that might be needed.

I'm sorry, but that is not writing 'assembly'.

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

I wonder how many times people here have updated just 'as'? In any case,
there are a number of ways around it, but as you have pointed out, you
don't make serious use of assembly so it doesn't matter.

> Of course it would be /possible/ to extend gcc with a built-in
> assembler.  But what would that give you?  Lots of duplicate work to
> support C, C++, Fortran, Ada, and other languages?

On top of the duplicate work you already need to support C, C++, Fortran
and Ada?

Well, you can forget the last two. But a lower level language like C,
which is already known as a 'portable assembler', you'd think would have
better facilities.

I have a better idea: how about you take an existing, proper assembler,
and build a C compiler around it?

>  The assembler
> already handles assembly - why make an HLL do it?  It's a lot better to
> put the effort into reducing the number of times you actually need to
> write inline assembly, by improving the optimiser and builtin functions.
>
>>
>>   * You mostly use offsets to get at local variables
>
> You never do that.  You are imagining things.  Or you are looking at
> some very odd inline assembly examples.
>
>>
>>   * You apparently aren't allowed to use just any registers as you need
>>     to negotiate with gcc so as not to interfere with /its/ use of
>>     registers. So most examples I saw seemed to deal with this.
>
> Or, as sane people would say, you don't need to mess around trying to
> figure out what different registers are used for different purposes, or
> where your input data is, or where your output data should go - gcc will
> handle it all for you.

As I've said repeatedly, this not assembly. You have to ask exactly why
you need to use assembly. If it is in rare, special situations, then it
is not a big deal to think about how it will work with registers.

>>
>> I consider that when writing assembly, YOU are in charge not the
>> compiler. As you can see from mine:
>>
>>   * It is written just as it would be in an actual ASM file
>
> Yes - and that's why it is so limited, and requires so much more
> assembly.  I prefer to let the compiler do what the compiler is good at.

I do that when I write HLL code. But when I need ASM, it should be as
simple as possible:

a := asm rdtsc # low 32 bit of time stamp counter
println a

>>
>>   * You can refer to variables directly (the compiler will add what is
>>     needed to access locals or statics)
>
> I can refer to all the variables I want to - and coordinate with the
> compiler so that it knows what I am doing.  Cooperation works far better
> than some arrogant pompous fool claiming they know better, and ruining
> the optimiser's work.  Mind you, you wrote your compiler, so I suppose
> you /do/ know better than your compiler.
>
>>
>> If a function uses inline ASM, variables are kept in memory not
>> registers.
>
> What a terrible pessimation.

On 15/01/2024 20:16, David Brown wrote:
> On 15/01/2024 19:41, bart wrote:

[gcc writing.out/a.ext output executables by default.]

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

Sure. The same way that the fallthrough behaviour of C's switch
statement is considered an advantage by some. Meanwhile, 99% of the time ...

On 16/01/2024 13:26, bart wrote:
> 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.

No. But I prefer it that way - I am much happier with a compiler that
has a (fairly) precise way to express the interaction between inline
assembly and the rest of the compiler, than one that leaves you guessing
and hoping that your use of registers will not conflict with the compiler's.

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

I want to be /able/ to do that, but I very much don't want to /have/ to
do that. I certainly don't want to have to mess around with the donkey
work of moving data around and in and out of registers when the compiler
can do that for me! I use inline assembly when the compiler can't do
the job or use the particular instruction(s) by itself - and no more
than that.

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

You are misunderstanding the gcc syntax here. Now that I see what you
mean, I realise I should probably have explained it earlier.

Basically, gcc inline assembly statements look like this :

asm(<asm template> : <outputs> : <inputs> : <clobbers>);

The <asm template> is a string (often written using C string
concatenation if it spans multiple lines). This is a /template/ - it
contains special characters and sequences that get filled in before it
is written out to the assembler. In particular, each input and output
operand is replaced.

The <inputs> and <outputs> are lists of input and output constraints for
data that is passed into and out of the assembly expression. A
constraint consists of an optional symbolic name inside square brackets,
an operand constraint string, and a C expression inside parentheses.

Inside the assembly template, you can refer to these operands by
positional number (%0 for the first, %1 for the next, etc.), or by the
symbolic name using the format %[name]. That is what the "%[c]", etc.,
means in the code I wrote. (The symbolic name does not have to bear any
connection to the variable name in C - indeed, the input and output
expressions do not have to refer to C variables. But /if/ they refer to
variables, then I often pick the same name.) Some people prefer to use
parameter numbers, others (like me) prefer names.

When the compiler is handling the inline assembly line, it first matches
the input and output operands to their constraints. A constraint "r"
means "any general-purpose register". "m" means "addressable memory",
"i" means "immediate value", and "g" means "general - any of r, m or i".
There are a great many other constraint codes available, most of which
are specific for specific targets.

So if the data that is to go into an input with constraint "r" is
already in a register - say "r8" - then any use of that operand in the
assembly template will be replaced by "r8" - or "%r8" or whatever format
is needed by the assembler. If the input data happens to be known at
compile-time (as is the case for your local variables here), then the
compiler will first pick a free register - say, "rbx" - and then
generate whatever code is needed to load that register with the known
number. That might be a "load" instruction, a "move" instruction, or a
bunch of instructions needed to access constant data from a store
relative to the current PC - whatever the target processor needs. If
the input expression is "foo() + 3 * xs[43]", it will evaluate that
expression and store the result in the free register.

If the constraint is "g", then it can be a lot more flexible - that's
suitable for x86 assembly, where many instructions can handle a memory
reference, an immediate, or a register. And if it is a memory
reference, the compiler will replace the operand in the assembly
template with whatever format suits the target - whether that be
"[rsi+4]", "16(si)", "*0x1234" or anything else suitable for the target.

Outputs are similarly matched with free registers, memory addresses, or
whatever suits the constraint (an "i" constraint is obviously not
helpful here). And after the assembly has been executed, this output
will then be assigned to the expression given in the output operand
list. For simple cases where the output operand is a local variable,
usually nothing will be needed because the compiler would match the
output operand to a register and use that for the local variable
afterwards. But the expression could be any lvalue, and need assignment
afterwards.

The "+g" (which would actually have been better as "+r") says that the
operand is an input as well as an output.

All in all, it means the compiler handles register allocation and moving
data into and out of registers - if needed.

The syntax can cover a lot more than this - modifiers for the operands
(very useful if you have, say, a 16-bit target and want to access the
high and low halves of a 32-bit operand), constraints of all sorts, flag
register changes, assembly templates that adjust automatically for Intel
and AT&T syntax, and so on. But that's too much for a Usenet post!

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

On 16/01/2024 16:24, bart wrote:
> On 15/01/2024 20:16, David Brown wrote:
>> On 15/01/2024 19:41, bart wrote:
>
> [gcc writing.out/a.ext output executables by default.]
>
>>> 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?
>
> Sure. The same way that the fallthrough behaviour of C's switch
> statement is considered an advantage by some. Meanwhile, 99% of the time

A default a.out filename is of no advantage to /me/, but Gabriel says
he/she finds it useful, and I've no reason to doubt him/her.

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.

I can imagine bugs in real, released code as a result of default
fallthrough in switches. I cannot imagine problems caused by default
output filenames - it is, at most, an extremely minor inconvenience for
a few people.

bart <bc@freeuk.com> writes:
>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

It doesn't bother me at all. Every assembler I used was from->to
from the PDP-11 through Burroughs mainframes.

Only the intel assembler (and arm, which copied intel) reverses that.

AT&T chose from->to to match the PDP-11 (and later VAX-11) assembler
behavior. It made no sense to use the intel variety when they ported
to intel.

On 16/01/2024 15:08, Janis Papanagnou wrote:
> 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.
>

I was too blind to notice that this completely synthetic example
expression actually is a useful function that is a single accelerated
instruction on many architectures. (And I've just recently finished a
project that uses MAC's in a filter.) Now I feel /really/ silly!

Of course many architectures have multiply-accumulate instructions, in
all sorts of variants, because they are key operations in many DSP
algorithms and filters. They can be integer, floating point, saturated
integer, scaled integer. In DSPs they are often very complex, such as
having operands via pointer registers that scan through buffers (perhaps
circular buffers), all in a single cycle.

They are also sometimes known as "FMA" (fused multiply add).

x86-64 has some SIMD/AVX512 MAC instructions, I believe.

bart <bc@freeuk.com> writes:
>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?

What leads you to the belief that anyone is 'prioritizing' the
appearance of intermediate code?

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

David Brown <david.brown@hesbynett.no> writes:
>On 15/01/2024 21:41, Scott Lurndal wrote:
>> 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?
>>
>
>It would be a little surprising, but certainly possible. Sweden has had
>been quite significant in the compiler world - IAR is a big name in
>embedded toolchains, and they are Swedish.
>
>You are sure you are not just one of these ignorant parochial Merican's
>who think Norway is the capital of Sweden? :-)]

No, I'm 7/8th norwegian, with a bit of swiss. While I haven't visited (yet),
I do have relatives there. Think Luren dal.

Granted it's been three decades since were were using diab compilers (1993ish)...

On 16/01/2024 16:15, bart wrote:
> On 15/01/2024 15:23, David Brown wrote:
>
>> Let's look at an actual example from my own code, in an older project.
>> I wanted an endian swap function on an ARM microcontroller, and for
>> reasons that escape me for now, I did not want to use gcc's
>> __builtin_bswap32, or an intrinsic from a header, or just plain C code
>> (which modern gcc could optimise to a single "rev" instruction).  The
>> code was probably originally written for quite an old version of the
>> compiler.  So I wrote the function:
>>
>> static inline uint32_t swapEndian32(uint32_t x) {
>>          uint32_t y;
>>          asm ("rev %[y], %[x]" : [y] "=r" (y) : [x] "r" (x) : );
>>          return y;
>> }
>>
>> This is, IMHO, quite clear once you know that gcc assembly consists of
>> the assembly template, the outputs, then the inputs.
>
> Well, you've explained it. But I'm none the wiser. Let's break it down
> better:
>
>     rev  %[y], %[x]           # rev appears to be an ARM instruction:

Yes.

>                               # rev Rdest, Rsource

Yes.

>     [y] "=r" (y)              # Outputs?

Yes.

>     [x] "r" (x)               # Inputs?

Yes.

>
> You're telling gcc that somehow, the value of x needs to get into a
> register (since rev doesn't work on memory, or immediates). And that the
> new value of y needs to come from a register.

Yes.

>
> The compiler will decide which registers to use, and insert them into
> that instruction.

Yes.

> And it will ensure that x is loaded into its register,
> if it is not already in one; and that y is loaded from its register, if
> it is not already in the prefered one.
>

Yes.

All good here!

> Since this is a return value, it will likely use R0 anyway.

Well, that would be the case if "swapEndian32" were generated as a
stand-alone function. (Both x and y would use r0.) But as a small
static inline function, this would normally be inlined directly in
functions that use it :

#include <stdint.h>

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

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

ARM GCC 13.2.0 with options "-O2 -Wall -Wextra -mcpu=cortex-m7" :

swapEndian32:
rev r0, r0
bx lr
swap_lots:
cbz r2, .L11
add ip, r2, #-1
adds r0, r0, #16
adds r1, r1, #16
push {r4, r5}
..L5:
add ip, ip, #-1
adds r1, r1, #16
cmp ip, #-1
ldrd r5, r4, [r0, #-16]
ldrd r2, r3, [r0, #-8]
rev r5, r5
rev r4, r4
rev r2, r2
rev r3, r3
add r0, r0, #16
strd r5, r4, [r1, #-32]
strd r2, r3, [r1, #-24]
bne .L5
pop {r4, r5}
bx lr
..L11:
bx lr

>
> But I'm inferring this from the way I know that 'rev' must work, and
> from your comments. You seem to be expending a lot of effort however
> into explaining it to gcc.

If you look at the "swap_lots" function above, you can see the
advantage. The compiler can use double-register loads and stores for
twice the memory efficiency (the Cortex-M7 has some 64-bit internal
buses), and it can schedule the instructions better (that core is
dual-issue and pipelined, but not OOO). This means the results are many
times faster than if everything were pushed sequentially through "rev
r0, r0".

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

Here you can also see the massive advantage of gcc's use of string
assembly templates that it passes on to the assembler - you never get
the situation where the compiler doesn't support a particular assembly
instruction.

> This could have been shorter if 'bswap' had a separate dest register.
> Here, knowing that x is always going to be rcx, I could have copied
> straight from there, but would be bad form.

I agree that would be bad form, unless you know for sure that it would
always be in the one particular register. Again, gcc's syntax shines -
gcc will sort this out for you, generating any register moves that are
needed and skipping any that are unnecessary.

>
> I think a useful enhancement to my scheme would be allow 'x' for example
> to exist in static memory, stackframe, or in a register. The register
> allocator for locals can be made to work with the assembly: it will only
> choose registers that have not been used for anything else.
>
> So, there are plenty of opportunities to make my scheme even better.
>

Sure.

>
>
>>   And it generates the code optimally - when used in an expression,
>> there will be no extra moves, or data put on the stack, or wasted
>> registers.  The compiler can move the code back and forth while
>> optimising, eliminate calls when the result is used, and generally do
>> its job just as well with this function as any other inline function
>> or built in operator.
>>
>>>
>>> You need to tell me, because I will otherwise not have a clue.
>>
>> It's clear that you haven't a clue.  So how can you justify ranting
>> and raving against something you don't understand?
>
> I'm been familiar with x86 assembly for 40 years, so I should expect to
> understand it! But the answer is simple: what gcc provides is little to
> do with x86, and 90% of it seems made up.

Oh, I know you understand x86 assembly. It's the gcc inline assembly
you didn't understand at all. (Now you understand a good deal about it.)

>
>
>>> From what I've seen of gcc inline asm:
>>>
>>>   * Code has to be written within string literals,
>>
>> Yes, obviously.  Assembly is not C, so writing assembly mixed in your
>> C requires it to be in a format that is acceptable in C syntax (or at
>> least close enough to C syntax to be a non-invasive extension).
>> String literals are also quite amenable to generation by macros, for
>> those that want to write something complicated.
>
> So, how did I manage to get Intel-style assembly into my language? I
> didn't need to use strings.

Your language is not C either.

>
> gcc should try harder!

No, it has a solution that works fine. It needs somewhat more
punctuation than optimal, but otherwise it's good enough for the purpose.

Of course it would always be possible to do better. But mixing in a
completely different kind of language in the middle of a high level
language is not helpful. You'd need to make huge changes to the parsers
just to handle the mix of line-oriented assembly and non-line-oriented
main code (in all the languages that gcc supports - in the main tree,
and all the extra ones run as separate projects). You'd need to deal
with the dozens of different mainline targets (and the other targets
that are separate projects). You'd need to keep updating this for every
little change to every processor target - duplicating work done already
by binutils and other assemblers. You'd then want to change clang, icc,
CodeWarrior, and other C compilers (and their C++ counterparts, and
their Rust, D, Pascal, and anything else that supports inline assembly)
- or you'd lose compatibility. Oh, and then you'd want to change all
the existing uses of inline gcc in user code.

It would be an enormous effort, merely to give a minor convenience
improvement to the tiny proportion of gcc users who ever write inline
assembly. (Many /use/ it, with pre-written code in headers, but they
don't /write/ it themselves.)

>
>
>>> in dreadfil AT&T
>>>     syntax.
>>
>> "Dreadful" is, again, /your/ opinion - not shared by everyone.  (I
>> personally don't care either way.)
>
> This is the first hit for "at&t versus intel syntax":
> https://imada.sdu.dk/u/kslarsen/dm546/Material/IntelnATT.htm
>
> Its opinion is:
>
> "The AT&T form for instructions involving complex operations is very
> obscure compared to Intel syntax."

On 16/01/2024 17:02, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 15/01/2024 21:41, Scott Lurndal wrote:
>>> 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?
>>>
>>
>> It would be a little surprising, but certainly possible. Sweden has had
>> been quite significant in the compiler world - IAR is a big name in
>> embedded toolchains, and they are Swedish.
>>
>> You are sure you are not just one of these ignorant parochial Merican's
>> who think Norway is the capital of Sweden? :-)]
>

I hope you noticed the smiley :-)

> No, I'm 7/8th norwegian, with a bit of swiss. While I haven't visited (yet),
> I do have relatives there. Think Luren dal.
>

I would say you are of Norwegian decent, or have Norwegian family roots
- it's not the same as being Norwegian. You need to at least visit the
country! Alternatively, you need to eat a /lot/ of brunost to improve
your credentials.

I looked up "Lurendal" on Google maps. It's in Sweden :-) Maybe your
parents told you they were Norwegian, because they know that Norwegians
are superior to Swedes in every way...

(There are a few place names in Norway with "Luren" in them, and of
course spellings change over time between family names and place names.)

> Granted it's been three decades since were were using diab compilers (1993ish)...

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

The the assembly language is whitespace sensitive. It requires
the newlines; and possibly also the leading indentation.

Chances are good you will look at the assembly output while
debugging.

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

Support for a multi-line string literal which allows literal
newlines to denote themselves would also work.

> 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* refer to registers directly in GCC inline assembly.

You just usually don't *want* to.

There has to be a good reason for that, like using a certain instruction
that only takes specific register as a source or destination operand.

(When you use a specific register in the template, you must inform the
compiler by including it in the list of "clobbers". Clobbers
are the last argument:

asm ("template" : outputs : inputs : clobbers)

if we clobber rax and rdx the clobbers might look like "rax", "rdx".

Then the compiler knows that if some variable is held in any of those
registers, it must be spilled to memory before that code can be executed
(or some other strategy must be taken, like not allocating those
registers).

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

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.

A reasonable compromise would be to have some multi-line literal.

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

That's quite literally fallacious. A big project worked on by many
people and widely used simply cannot do anything that a tiny one-person
project can do. Not at the process level, nor the code change level.

For that matter, in a one-person compiler that targets twelve
architectures, we wouldn't necessarily approach inline assembly the same
way as one which targets only x86.

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

Why don't you educate the GCC mailing list?

In the GNU C inline assembly (called "Extended Assembly") you do call
the shots. The instructions in your template are used verbatim: no
instructions are added, deleted or renamed. You just have to
coordinate with the compiler. If you don't inform the compiler about
what you are doing, things will go wrong. Optionally, you can request
that the compiler prepare operands for you and give you registers.

> It's not just more natural syntax, but better integration within the

No man-made syntax is natural.

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

I don't know whether GCC inline assembly can do that or not. While
you probably can't refer to an ordinary C goto label, GCC does have
computed labels. Ther is a way to capture a label as a void * value
I think. If you can get that as an operand into an asm block, it may
be possible to jump to it.

It doesn't strike me as a great idea, honestly.

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

Yes it is; it uses assembly language instructions, which are integrated
into assembly language output, fed into an assembler.

The fact that operands like %1 are replaced by registers just means
that it's a kind of macro assembly language.

> Mine is; it
> looks exactly line normal assembly, and it is written inline to the HLL.

Yes, and you do get points, from other programmers who have access to
the code, for it looking nice, and paying homage to Intel.

The machine running the end result and the users don't care so much.

The GNU "Extended Asm" as the documentation calls it has fantastic
functionality though, due to the way you can declare contracts between
the assembly fragment and the compiler.

How things look does become important when you are writing tens of
thousands of lines of code. Extended Asm isn't used for even hundreds of
lines of code. In a typical project that needs any inline assembly at
all, it's a very small amount of code.

A large block of assembly will more likely be written as a .S file,
not inline.

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

David Brown <david.brown@hesbynett.no> writes:
>On 16/01/2024 17:02, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 15/01/2024 21:41, Scott Lurndal wrote:
>>>> 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?
>>>>
>>>
>>> It would be a little surprising, but certainly possible. Sweden has had
>>> been quite significant in the compiler world - IAR is a big name in
>>> embedded toolchains, and they are Swedish.
>>>
>>> You are sure you are not just one of these ignorant parochial Merican's
>>> who think Norway is the capital of Sweden? :-)]
>>
>
>I hope you noticed the smiley :-)
>
>> No, I'm 7/8th norwegian, with a bit of swiss. While I haven't visited (yet),
>> I do have relatives there. Think Luren dal.
>>
>
>I would say you are of Norwegian decent, or have Norwegian family roots
>- it's not the same as being Norwegian.

Point.

> You need to at least visit the Country!

My folks have been there a couple of times, and looked
up distant relatives from both sides (the other side
was from the Bergen area, IIRC).

> Alternatively, you need to eat a /lot/ of brunost to improve
>your credentials.

Does lutefisk and lefse count? Had a small earthquake while
typing this. Probably less than M3.

>
>I looked up "Lurendal" on Google maps. It's in Sweden :-)

Blame my great great grandfather who changed his name from
Olson to Johnson to Lurndal shortly after immigrating here,
and shortly before serving in the Union army.

> Maybe your
>parents told you they were Norwegian, because they know that Norwegians
>are superior to Swedes in every way...

The area where they settled (western wisconsin) was Norwegian, with
a fair bit of competition from Swedish and German immigrants. The
small (Pop. 50) town near my grandfathers farm had two churches,
both Lutheran, one for the German population and one for the
Norwegians (the Swedes were in the next village over).

>
>(There are a few place names in Norway with "Luren" in them, and of
>course spellings change over time between family names and place names.)

On 2024-01-16, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> 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.

It is obviously useful for evaluating polynomials via Horner's rule,
which involves multiplying the accumulator by a coefficient, and then
adding a term.

Ax^3 + Bx^2 + Cx + D -> x(Ax^2 + Bx + c) + D
-> x(x(Ax + B) + C) + D

O is output/accumuator:

O = A
O *= x; O += B; // multiply + add steps
O *= x; O += C;
O *= x: O += D;

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

>> 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.
>
> That can sometimes happen, for particular kinds of code.  It is not
> often that hand-written assembly will be so significantly faster than
> gcc unless there are close matches for unusual instructions that the
> compiler does not generate.  But it can certainly happen.
>
> Often the C code can be improved in various ways - perhaps using
> extensions (such as gcc attributes).  Getting the very best out of a
> compiler for key performance-critical code is rarely just a matter of
> writing "-O3" and hoping for the best.
>
> If you can boil this down to a short and manageable piece of code, then
> it might be fun to look at ways of improving the speed using either pure
> standard C, or gcc extensions, and compare it to the hand-generated
> assembly.  I realise that making such as small sample that keeps the
> effect is unlikely to be a trivial task.  (And if you do this, put it in
> a new thread :-) )

I have done experiments that comprise under 100 lines of code and that
test a very small number of bytecodes, maybe just one.

But I don't believe you can extract useful conclusions that will scale.

gcc's agressive optimiser is likely to reduce such a simple program to
nothing, or it will be able to infer things are not possible when spread
over 20,000 lines of code over multiple modules, and where the test
bytecode is a runtime input, not set up in a data structure.

I've worked with four main kinds of bytecode dispatcher:

(1) Using a table of function pointers. The dispatcher is then a simple
3-line loop

(2) Using a large switch statement. Each case can be either inline code
or can call a function. gcc likes this one because it can inline
function calls

(3) Using computed-goto. In C, this would need gcc's extension to use
label pointers

(4) Using a threaded-code dispatcher, making extensive use of inline
assembly, which is an overlay over (1): when a bytecode can't be
fully handled here, it calls one of the handlers from (1).

These are progressively faster. I no longer use (2) or (3); there's no
point if I have (4).

The C version used (1), compared with (4) using my compiler and language.

I have in the past compared C versions of (2) and (3) with (4), and (4)
was still faster, although that was some time ago.

When I lookat at CPython sources a decade ago, they used method (3) when
compiled on Linux. On Windows however, they used method (2), since it
needs MSVC to build, which does not have the needed extension.

(My language also has label pointers, but it also has a built-in feature
for computed-goto: you only have to tweak one line to change a regular
switch-loop into one that uses computed-goto. That is, using multiple
loop-back points so that each can have its own branch prediction.

I don't use that in this product, only in a separate project.)

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

My (4) dispatcher uses thread-code functions that try and keep execution
within a tight, register-based environment:

* Essential globals are kept in registers

* There is no function entry/exit code: each handler jumps directly to
the next, without any loops

* ABI considerations are put aside (eg. all non-volatiles are saved once
at the beginning, and restored at the end)

* Most handlers use inline assembly

* When it is necessary to call a normal HLL handler, the environment
must be saved and restored.

This an example of a very simple handler that uses inline assembly:

threadedproc j_jump*=
assem
mov Dprog,[Dprog+kopnda]
*jumpnext
end
end

And this is one which uses the HLL handler:

threadedproc j_jumpptr*=
saveregs
k_jumpptr()
loadregs
jumpnext
end

saveregs/loadregs are macros. In both cases, 'jumpnext' is this macro
(it needs * to invoke it from assembly):

macro jumpnext = asm jmp [Dprog]

So, the overheads of executing 'goto L' in the interpreted language are
two machine instructions.

On 15/01/2024 11:45, David Brown wrote:
> On 12/01/2024 18:09, bart wrote:

>>>>> download to a target board via a debugger,
>>
>> (Hey, I used to do that! Not a makefile in sight either; how is that
>> possible?
>>
>
> Grow up.
>
>> I used to do that with no special tools, no external software and no
>> external languages. I had to write assemblers for any new devices I
>> has to use.)
>>
>
> Yes, I've heard it before.  If you wanted a keyboard, you had to carve
> it out of a rock with your teeth.

No. I bought a keyboard for £12. I didn't try and make one (I was
unemployed and broke) but it was hopeless.

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

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

You need to get it right:

* I built a machine that could only be programmed in actual binary

* That binary code was used to write a hex editor

* The hex editor was used to write an assembler

* The assembler was used to write the compiler for my first language.
(Which was then used for areas of interest which included 3D graphics,
image processing and frame-grabbing, also using my hardware)

* Later this compiler was rebooted on a better machine (with actual
floppy disks!), and eventually it was self-hosted.

(This is when I first looked at the K&R book - it cost me £12, £2 more
than my Z80 processor - and dismissed it.)

* Among many other tasks, the tool was used to write comprehensive
assemblers for the 80188, and an Intel controller, 8035 or 8051.

The point is, getting an entirely different, self-sufficient perspective
compared with those who even then were using traditional tools.

I had to solve the problem for example of combining multiple object
files (in my own format of course) into one executable. Everybody else
used a complex bit of software called TaskBuilder, or Linker. I just
dashed together a program which could do the job as fast as it could
read from disk.

Task accomplished. But people are still messing about with object files
and linkers now (and those mysterious .a and .lib files even when it's
going to be using shared library anyway).

They are taking those traditional tools and making them bigger and more
complex.

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.

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.

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

On 16/01/2024 19:45, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 16/01/2024 17:02, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 15/01/2024 21:41, Scott Lurndal wrote:
>>>>> 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?
>>>>>
>>>>
>>>> It would be a little surprising, but certainly possible. Sweden has had
>>>> been quite significant in the compiler world - IAR is a big name in
>>>> embedded toolchains, and they are Swedish.
>>>>
>>>> You are sure you are not just one of these ignorant parochial Merican's
>>>> who think Norway is the capital of Sweden? :-)]
>>>
>>
>> I hope you noticed the smiley :-)
>>
>>> No, I'm 7/8th norwegian, with a bit of swiss. While I haven't visited (yet),
>>> I do have relatives there. Think Luren dal.
>>>
>>
>> I would say you are of Norwegian decent, or have Norwegian family roots
>> - it's not the same as being Norwegian.
>
> Point.
>
>> You need to at least visit the Country!
>
> My folks have been there a couple of times, and looked
> up distant relatives from both sides (the other side
> was from the Bergen area, IIRC).

Bergen's a nice city. It rains a lot, but otherwise it's a pleasant place.

>
>> Alternatively, you need to eat a /lot/ of brunost to improve
>> your credentials.
>
> Does lutefisk and lefse count?

Everyone likes lefser, but if you can claim to like lutefisk with a
straight face, you must be Norwegian!

(For those that don't know, "lutefisk" is made by drying cod completely,
then soaking it in draincleaner, then washing it, then boiling it. It
doesn't beat the Swedish canned fermented fish or Icelandic sharks
buried for months in the sand, but it's definitely not something to be
eaten lightly.)

David Brown <david.brown@hesbynett.no> writes:
>On 16/01/2024 19:45, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:

>>> Alternatively, you need to eat a /lot/ of brunost to improve
>>> your credentials.
>>
>> Does lutefisk and lefse count?
>
>Everyone likes lefser, but if you can claim to like lutefisk with a
>straight face, you must be Norwegian!

Eat? Yes. Holiday tradition.
Like? One can eat anything if it is drowned in enough butter.

The feeling of that gelatinous mass sliding down the back
of your throat is unforgettable.

>
>(For those that don't know, "lutefisk" is made by drying cod completely,
>then soaking it in draincleaner, then washing it, then boiling it. It
>doesn't beat the Swedish canned fermented fish or Icelandic sharks
>buried for months in the sand, but it's definitely not something to be
>eaten lightly.)
>

David is not exaggerating about the drain cleaner....

On 16/01/2024 22:00, David Brown wrote:
>
> (For those that don't know, "lutefisk" is made by drying cod completely,
> then soaking it in draincleaner, then washing it, then boiling it.  It
> doesn't beat the Swedish canned fermented fish or Icelandic sharks
> buried for months in the sand, but it's definitely not something to be
> eaten lightly.)
>

Local: It's a delicacy
Jeremy Clarkson: Haven't you people heard of chocolate?

On 16/01/2024 20:21, bart wrote:
> On 16/01/2024 15:29, David Brown wrote:
>> On 16/01/2024 13:26, bart wrote:
>
>>> 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.
>>
>> That can sometimes happen, for particular kinds of code.  It is not
>> often that hand-written assembly will be so significantly faster than
>> gcc unless there are close matches for unusual instructions that the
>> compiler does not generate.  But it can certainly happen.
>>
>> Often the C code can be improved in various ways - perhaps using
>> extensions (such as gcc attributes).  Getting the very best out of a
>> compiler for key performance-critical code is rarely just a matter of
>> writing "-O3" and hoping for the best.
>>
>> If you can boil this down to a short and manageable piece of code,
>> then it might be fun to look at ways of improving the speed using
>> either pure standard C, or gcc extensions, and compare it to the
>> hand-generated assembly.  I realise that making such as small sample
>> that keeps the effect is unlikely to be a trivial task.  (And if you
>> do this, put it in a new thread :-) )
>
> I have done experiments that comprise under 100 lines of code and that
> test a very small number of bytecodes, maybe just one.
>
> But I don't believe you can extract useful conclusions that will scale.
>

That is sometimes the case.

> gcc's agressive optimiser is likely to reduce such a simple program to
> nothing, or it will be able to infer things are not possible when spread
> over 20,000 lines of code over multiple modules, and where the test
> bytecode is a runtime input, not set up in a data structure.
>

A trick here is to make your source data "volatile" - or make it depend
on a volatile (so that you are not affecting the access to the data
itself). And put the results into a volatile.

volatile int nothing = 0;
volatile int result;

void foo(void) {
int test_data = 1234;
double more_data = 3.14;

test_data += nothing;

// or

if (nothing) {
test_data = nothing;
more_data = nothing;
}

// Start timer
int x = run_tests(test_data, more_data);
// Stop timer
result = x;
}

It doesn't really matter how you use "nothing", just that the value of
the inputs could be affected by it.

(I can show you an alternative trick using target-independent inline
assembly, if you like.)

> I've worked with four main kinds of bytecode dispatcher:
>
> (1)  Using a table of function pointers. The dispatcher is then a simple
>      3-line loop
>

OK.

> (2)  Using a large switch statement. Each case can be either inline code
>      or can call a function. gcc likes this one because it can inline
>      function calls
>

I prefer switches to jump tables - I avoid function pointers where I
can, because they make it so much harder to analyse call trees.

> (3)  Using computed-goto. In C, this would need gcc's extension to use
>      label pointers

That is also sometimes used for such code. Again, I prefer the switch here.

>
> (4)  Using a threaded-code dispatcher, making extensive use of inline
>      assembly, which is an overlay over (1): when a bytecode can't be
>      fully handled here, it calls one of the handlers from (1).
>
> These are progressively faster. I no longer use (2) or (3); there's no
> point if I have (4).
>
> The C version used (1), compared with (4) using my compiler and language.
>

It is perhaps a bit unfair to compare a slow algorithm in C with a fast
algorithm in a different language!

Much will depend on cache usage, branch prediction, and if you can
arrange for common cases to be checked first. And also remember that
"-O3" is not always faster than "-O2", and that sometimes there are
other flags that make a significant difference.

> I have in the past compared C versions of (2) and (3) with (4), and (4)
> was still faster, although that was some time ago.

Depending on your value of "some", that might make a difference - gcc
has improved over time.

>
> When I lookat at CPython sources a decade ago, they used method (3) when
> compiled on Linux. On Windows however, they used method (2), since it
> needs MSVC to build, which does not have the needed extension.
>

There's a lot of work been done on such bytecode interpreters. One of
the best-known experts, Anton Ertl, is the author of the GForth bytecode
interpreter. His code is all in gcc-extended C. (He gets really worked
up about some gcc optimisations "breaking" his "correct" code - we've
had a few disagreements of opinion on that topic. You'd like him :-) )
You may find some interesting papers on his webpage:

<http://www.complang.tuwien.ac.at/projects/interpreters.html>

He hangs out in comp.arch, and possibly other newsgroups.

> (My language also has label pointers, but it also has a built-in feature
> for computed-goto: you only have to tweak one line to change a regular
> switch-loop into one that uses computed-goto. That is, using multiple
> loop-back points so that each can have its own branch prediction.
>
> I don't use that in this product, only in a separate project.)
>
> -------------
>
> My (4) dispatcher uses thread-code functions that try and keep execution
> within a tight, register-based environment:
>
> * Essential globals are kept in registers
>
> * There is no function entry/exit code: each handler jumps directly to
>   the next, without any loops
>
> * ABI considerations are put aside (eg. all non-volatiles are saved once
>   at the beginning, and restored at the end)
>
> * Most handlers use inline assembly
>
> * When it is necessary to call a normal HLL handler, the environment
>   must be saved and restored.
>
> This an example of a very simple handler that uses inline assembly:
>
>     threadedproc j_jump*=
>         assem
>             mov Dprog,[Dprog+kopnda]
>             *jumpnext
>         end
>     end
>
> And this is one which uses the HLL handler:
>
>     threadedproc j_jumpptr*=
>         saveregs
>         k_jumpptr()
>         loadregs
>         jumpnext
>     end
>
> saveregs/loadregs are macros. In both cases, 'jumpnext' is this macro
> (it needs * to invoke it from assembly):
>
>     macro jumpnext = asm jmp [Dprog]
>
> So, the overheads of executing 'goto L' in the interpreted language are
> two machine instructions.
>

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?

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

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.

Using an inlining macro didn't make much difference.

I then tried adding 'byteswap' as an intrinsic operator within my
language. Then that 2.3GB/s became 3.4GB/s. I used a simple loop with no
unrolling.

I can't run your code directly, as a I don't have 'rev'. But adjusting
that swap function to instead apply '~', processing a 200M-element u32
array (also 0.8GB), took 0.22 seconds or 3.6GB/s. (This was doing n/4
iterations of your unrolled loop.)

But this is not really about inline assembly any more, but ways to make
best use of memory bandwidth.

(I have an advantage in working 64 bits at a time, but you'd think gcc
would be able to take care of that; wasn't that your point?)