On Saturday, 3 October 2020 at 14:21:25 UTC, Paulo Pinto wrote:
> The PC / Amiga way of
[…]
> Versus the clunky way of
>
> void myfunc (int data)
> {
>    asm("weird Assembly pseudo syntax", data);
> }

Yes, yes, I totally agree! I haven't found the desire to write much assembly in many years now as intrinsics are good enough for me at this point, but when I did I would rather just write a function in C, disassemble it and modify the code. It was more pleasant and flexible than dealing with the "clunky way". (Besides the built compiler-assembler didn't support the new SIMD instructions I wanted to use anyway.)

What I meant was, why do they think that it difficult to integrate non-AT&T syntax with the compiler? Makes no sense to me.

Also, assembly is usually defined with the intent to be easy to parse. If you don't have to support macros (or other advanced features) one can write the core parts of an assembly parser in a weekend and having fun while doing it.

On Saturday, 3 October 2020 at 15:16:21 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 3 October 2020 at 14:21:25 UTC, Paulo Pinto wrote:
>> The PC / Amiga way of
> […]
>> Versus the clunky way of
>>
>> void myfunc (int data)
>> {
>>    asm("weird Assembly pseudo syntax", data);
>> }
>
> Yes, yes, I totally agree! I haven't found the desire to write much assembly in many years now as intrinsics are good enough for me at this point, but when I did I would rather just write a function in C, disassemble it and modify the code. It was more pleasant and flexible than dealing with the "clunky way". (Besides the built compiler-assembler didn't support the new SIMD instructions I wanted to use anyway.)
>
> What I meant was, why do they think that it difficult to integrate non-AT&T syntax with the compiler? Makes no sense to me.
>

-masm=intel

> Also, assembly is usually defined with the intent to be easy to parse. If you don't have to support macros (or other advanced features) one can write the core parts of an assembly parser in a weekend and having fun while doing it.

This question of why dmd-style iasm isn't done has already been answered a little earlier today.  If you think you can implement all supported targets (that is about 50 distinct CPUs) in a weekend, be my guest.  You'll soon learn every reason why it is unfeasible, impractical, and in many cases not possible within the llvm and gcc compiler frameworks.

On Saturday, 3 October 2020 at 21:52:10 UTC, Iain Buclaw wrote:
> This question of why dmd-style iasm isn't done has already been answered a little earlier today.  If you think you can implement all supported targets (that is about 50 distinct CPUs) in a weekend, be my guest.  You'll soon learn every reason why it is unfeasible, impractical, and in many cases not possible within the llvm and gcc compiler frameworks.

The parsing is a drop in the ocean when supporting a new CPU. It is a matter of infrastucure for it in the code base and culture.  Syntax is not a big challenge.

On Saturday, 3 October 2020 at 14:21:25 UTC, Paulo Pinto wrote:
> On Saturday, 3 October 2020 at 09:52:56 UTC, Ola Fosheim Grøstad wrote:
>> On Saturday, 3 October 2020 at 08:51:58 UTC, Paulo Pinto wrote:
>>> It is also what I favour, the excuse those other compilers vendor give is that the clunky syntax they use is easier to integrate with the compiler backend for the optimiser's understanding of what is going on.
>>
>> Huh? How come?
>>
>> I think the only reason for this is that AT&T engineers had a preference for PDP11 syntax which they were used to and that it therefore became the default syntax on Unix and thus become associated with C compilers...
>
> The PC / Amiga way of
>
> void myfunc (int data)
> {
>    asm {
>      mov bx, data
>      int 21h
>    }
> }
>
> Versus the clunky way of
>
> void myfunc (int data)
> {
>    asm("weird Assembly pseudo syntax", data);
> }

This is comparing apples and oranges.  The second example of myfunc() is just a glorified printf() statement, the contents of the string is sent to the assembler along with the rest of the assembly code.  That style of asm does not fit the model in dmd, as you don't have the ability of outputting assembly code, the assembler step is skipped and instead it goes straight to object file.

On Saturday, 3 October 2020 at 13:27:23 UTC, kinke wrote:
>
> Yeah sure. See https://github.com/ldc-developers/ldc/blob/master/gen/asm-x86.h for an incomplete x86 implementation. And now imagine something like this for every ISA supported by GCC and LLVM, and keeping it up-to-date. - The whole point of the GCC/GDC-style assembly is genericity - an instructions template provided by the user as a string to be forwarded to the assembler (opaque for the optimizer), and outputs/inputs/clobbers provided separately because that's the only thing the pre-assembler stages need to know.
>
> Considering inline asm is mostly used as a last resort for some very low-level stuff, extending the front-end by a full-blown parser for every ISA would be an absolutely improportionate effort.

One thing that has puzzled me for some time with the GCC syntax is the necessity to include the clobber information. Can't that process be automated, for example the assembler returns information to the compiler about this?

On Saturday, 3 October 2020 at 22:14:02 UTC, Ola Fosheim Grøstad wrote:
> The parsing is a drop in the ocean when supporting a new CPU. It is a matter of infrastucure for it in the code base and culture.  Syntax is not a big challenge.

( I am talking about gcc, not gdc...)

On Saturday, 3 October 2020 at 14:21:25 UTC, Paulo Pinto wrote:
> The PC / Amiga way of
>
> void myfunc (int data)
> {
>    asm {
>      mov bx, data
>      int 21h
>    }
> }
>
> Versus the clunky way of
>
> void myfunc (int data)
> {
>    asm("weird Assembly pseudo syntax", data);
> }

Yes, but...
Assembly use case is just very low now.

I wrote a lot of assembly and since the modern backends like in ICC, LLVM or GCC since v4 it doesn't make a lot of sense to have code that doesn't perform better, is much harder to maintain, read and write.

If anything, optimising a bottleneck with intrinsics takes 3x more time, translating it back once the truth unfold is error-prone too.

The **inlinable** GCC-style assembly is actually more suitable to create the low-level abstracted things that can be used instead of assembly. That is, if you manage to write it ^^

On Saturday, 3 October 2020 at 22:37:05 UTC, Guillaume Piolat wrote:
> If anything, optimising a bottleneck with intrinsics takes 3x

without*

On Saturday, 3 October 2020 at 22:14:02 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 3 October 2020 at 21:52:10 UTC, Iain Buclaw wrote:
>> This question of why dmd-style iasm isn't done has already been answered a little earlier today.  If you think you can implement all supported targets (that is about 50 distinct CPUs) in a weekend, be my guest.  You'll soon learn every reason why it is unfeasible, impractical, and in many cases not possible within the llvm and gcc compiler frameworks.
>
> The parsing is a drop in the ocean when supporting a new CPU. It is a matter of infrastucure for it in the code base and culture.  Syntax is not a big challenge.

And the infrastructure present is zero.  The compiler is a producer of assembly, not a consumer.  It doesn't understand assembly constructs, and all the better if it remains that way.

On Saturday, 3 October 2020 at 22:33:03 UTC, IGotD- wrote:
> On Saturday, 3 October 2020 at 13:27:23 UTC, kinke wrote:
>>
>> Yeah sure. See https://github.com/ldc-developers/ldc/blob/master/gen/asm-x86.h for an incomplete x86 implementation. And now imagine something like this for every ISA supported by GCC and LLVM, and keeping it up-to-date. - The whole point of the GCC/GDC-style assembly is genericity - an instructions template provided by the user as a string to be forwarded to the assembler (opaque for the optimizer), and outputs/inputs/clobbers provided separately because that's the only thing the pre-assembler stages need to know.
>>
>> Considering inline asm is mostly used as a last resort for some very low-level stuff, extending the front-end by a full-blown parser for every ISA would be an absolutely improportionate effort.
>
> One thing that has puzzled me for some time with the GCC syntax is the necessity to include the clobber information. Can't that process be automated, for example the assembler returns information to the compiler about this?

That would require actually parsing the instruction string, and having a built-in understanding of what every instruction does.  The compilation process can be thought of as a series of pipes, each part is ran in a separate process.  For gcc C code the steps would look something like: `cpp main.c | cc | as | ld -o main.exe`.  There is no bidirectional communication between each layer.