On Wednesday, 15 July 2020 at 09:10:10 UTC, rikki cattermole wrote:
> On 15/07/2020 8:17 PM, kinke wrote:
>> You're not up-to-date, LDC supports gdc/gcc-style inline asm since version 1.21.
>
> D's wiki needs updating then. I searched for this information there and it wasn't there.

I am struggling to find documentation regarding LDC. The runtime library for instance. Do please forgive me if it’s just me being useless. I’m on powerful drugs for pain which make me very woozy. A poor excuse :-)

Could someone hit me with some good urls for relevant LDC-specifics.

On 2020-07-15 09:34, Stefan Koch wrote:

> There is a workaround which I used and that involves runtime overhead on startup.
> You just write the bytes that make up your function into an executable page of memory.
> Set a function pointer to there, and you are done ;)

There are some platforms that don't allow that, like macOS (10.15 or later). But I'm guessing you don't care about macOS ;)

-- 
/Jacob Carlborg

On Wednesday, 15 July 2020 at 13:02:40 UTC, Cecil Ward wrote:
> On Wednesday, 15 July 2020 at 09:10:10 UTC, rikki cattermole wrote:
>> On 15/07/2020 8:17 PM, kinke wrote:
>>> You're not up-to-date, LDC supports gdc/gcc-style inline asm since version 1.21.
>>
>> D's wiki needs updating then. I searched for this information there and it wasn't there.
>
> I am struggling to find documentation regarding LDC. The runtime library for instance. Do please forgive me if it’s just me being useless. I’m on powerful drugs for pain which make me very woozy. A poor excuse :-)
>
> Could someone hit me with some good urls for relevant LDC-specifics.

I don't think there are any docs about druntime LDC-specifics - the only thing which should be of relevance for the user are some extra LDC modules in the `ldc` top-level 'package', in particular ldc.intrinsics for LLVM intrinsics, ldc.attributes for UDAs, ldc.llvmasm for LDC-specific __asm and __ir (inline asm and LLVM IR), ldc.dcompute for dcompute, and (auto-generated, depending on LLVM version) gccbuiltins_<arch> for GCC builtins compatibility.

https://wiki.dlang.org/LDC-specific_language_changes contains some infos, but the more interesting files (ldc.intrinsics, ldc.attributes) should be mostly self-explanatory.

We obviously try to employ any LLVM intrinsics wherever we can in regular druntime and Phobos (e.g., core.bitop and std.math), so that the user doesn't have to use them manually.

On 15/07/2020 14:51, Cecil Ward via Digitalmars-d wrote:
> On Wednesday, 15 July 2020 at 08:17:06 UTC, kinke wrote:
>> On Wednesday, 15 July 2020 at 00:26:13 UTC, Cecil Ward wrote:
>>> I have a fair amount of code written in D which uses GDC’s syntax for inline asm and currently it is therefore GDC-only. It would like people to be able to build it alternatively using LDC as well, and maybe even DMD.
>>>
>>> It’s a shame about the huge syntactic differences between the asm syntax of GDC and LDC; both have their merits, but GDC seems to me to be the most powerful, although I don’t pretend to have studied LDC’s approach just glanced at it once very briefly.
>>
>> You're not up-to-date, LDC supports gdc/gcc-style inline asm since version 1.21.
> 
> Thank you Kinke! I am indeed very much out of date. That’s such excellent news, very welcome.

I am open to improving the syntax if that helps with interoperability between GDC and LDC.

https://issues.dlang.org/show_bug.cgi?id=20594

I am aware that one of the pet peeves of LDC adopting GDC-style was that it's perhaps not the most intuitive or aesthetic syntax (stems back to before D 1.0, has changed very little since its introduction).

On Wednesday, 15 July 2020 at 08:17:06 UTC, kinke wrote:
> On Wednesday, 15 July 2020 at 00:26:13 UTC, Cecil Ward wrote:
>> I have a fair amount of code written in D which uses GDC’s syntax for inline asm and currently it is therefore GDC-only. It would like people to be able to build it alternatively using LDC as well, and maybe even DMD.
>>
>> It’s a shame about the huge syntactic differences between the asm syntax of GDC and LDC; both have their merits, but GDC seems to me to be the most powerful, although I don’t pretend to have studied LDC’s approach just glanced at it once very briefly.
>
> You're not up-to-date, LDC supports gdc/gcc-style inline asm since version 1.21.

Since you were kind enough to let me know about this, I gave it a try - built some D-asm with LDC instead of GDC. The first problem I had was that of being out of date "adjacent" " " "literal" " " "strings" do not get automatically concatenation any more. I wrote out each line of asm in its own literal string, with a second literal string at the end consisting of only "\n\t".

The serious problem though is the error
    "Error: symbolic names for operands in GCC-style assembly are not supported yet"
I use symbolic names for registers everywhere, for readability and for order-independence. So that means I am dead. Looks like I will be sticking to GDC for asm for a while yet.

Shame.

On Thursday, 16 July 2020 at 23:06:24 UTC, Cecil Ward wrote:
> The serious problem though is the error
>     "Error: symbolic names for operands in GCC-style assembly are not supported yet"
> I use symbolic names for registers everywhere, for readability and for order-independence. So that means I am dead.

Or hopefully motivated enough to open a PR with a little extension to [1] - all that should be needed from the LDC side is replacing all occurrences of the symbolic names in the template string by their according operand index (LLVM has no implicit support for these symbolic names). And of course getting rid of the error msg in [2].

[1] https://github.com/ldc-developers/ldc/blob/424064438ec7f3ab202da982227e95660eca7c3e/gen/asm-gcc.cpp#L24-L53
[2] https://github.com/ldc-developers/ldc/blob/424064438ec7f3ab202da982227e95660eca7c3e/gen/asm-gcc.cpp#L186-L194

On Friday, 17 July 2020 at 00:38:23 UTC, kinke wrote:
> On Thursday, 16 July 2020 at 23:06:24 UTC, Cecil Ward wrote:
>> The serious problem though is the error
>>     "Error: symbolic names for operands in GCC-style assembly are not supported yet"
>> I use symbolic names for registers everywhere, for readability and for order-independence. So that means I am dead.
>
> Or hopefully motivated enough to open a PR with a little extension to [1] - all that should be needed from the LDC side is replacing all occurrences of the symbolic names in the template string by their according operand index (LLVM has no implicit support for these symbolic names). And of course getting rid of the error msg in [2].
>
> [1] https://github.com/ldc-developers/ldc/blob/424064438ec7f3ab202da982227e95660eca7c3e/gen/asm-gcc.cpp#L24-L53
> [2] https://github.com/ldc-developers/ldc/blob/424064438ec7f3ab202da982227e95660eca7c3e/gen/asm-gcc.cpp#L186-L194

Grave health difficulties mean that my abilities are very limited just now so I will have to hope that those with the required experience will have this on their things to do list at some point.

Thank you for pointing me at the right place,

On Thursday, 16 July 2020 at 15:08:39 UTC, Iain Buclaw wrote:
> I am open to improving the syntax if that helps with interoperability between GDC and LDC.
>
> https://issues.dlang.org/show_bug.cgi?id=20594

Some very interesting ideas brought up there, Iain. Good stuff. I would very much welcome some of those developments. Would it be possible to be possible to have multiple alternative syntaxes so we don’t have to deprecate anything just because of its age?

I must say I do like the power of the GCC/GDC asm binding interface / ‘glue’ system that connects the high level language to the asm. The notation is hard to understand in places though and your ideas provide a way to go even further and make big improvements in readability and learning curve. I keep having to reread the docs concerning returned / modified input registers and so on.

Idea. Perhaps someone could write an asm binding system notation -> english decoder, a tool that you could run to tell you what your asm binding interface definition is doing. Output in long-winded and explicit english and including things such as lists of possibilities for registers you are selecting or restricting an operand to bind to. I haven’t expressed myself very well here but I hope someone gets the drift.

Perhaps I should do binding definitions for every x86-64 instruction. That would keep me busy.

On 17/07/2020 05:14, Cecil Ward via Digitalmars-d wrote:
> On Friday, 17 July 2020 at 00:38:23 UTC, kinke wrote:
>> On Thursday, 16 July 2020 at 23:06:24 UTC, Cecil Ward wrote:
>>> The serious problem though is the error
>>>     "Error: symbolic names for operands in GCC-style assembly are not supported yet"
>>> I use symbolic names for registers everywhere, for readability and for order-independence. So that means I am dead.
>>
>> Or hopefully motivated enough to open a PR with a little extension to [1] - all that should be needed from the LDC side is replacing all occurrences of the symbolic names in the template string by their according operand index (LLVM has no implicit support for these symbolic names). And of course getting rid of the error msg in [2].
>>
>> [1] https://github.com/ldc-developers/ldc/blob/424064438ec7f3ab202da982227e95660eca7c3e/gen/asm-gcc.cpp#L24-L53 [2] https://github.com/ldc-developers/ldc/blob/424064438ec7f3ab202da982227e95660eca7c3e/gen/asm-gcc.cpp#L186-L194
> 
> Grave health difficulties mean that my abilities are very limited just now so I will have to hope that those with the required experience will have this on their things to do list at some point.
> 
> Thank you for pointing me at the right place,

There's nothing magical going on in order to resolve symbolic names.  Each output, input and label operand has an index value from 0 to N, and you just need to replace "%[symbol]" with "%3".

https://github.com/gcc-mirror/gcc/blob/f1b6e46c417224887c2f21baa6d4c538a25fe9fb/gcc/stmt.c#L528-L603 https://github.com/gcc-mirror/gcc/blob/f1b6e46c417224887c2f21baa6d4c538a25fe9fb/gcc/stmt.c#L605-L663

This could even be done in the semantic pass of GccAsmStatement (dmd/iasmgcc.d), so no need for LDC to duplicate this locally (plus, you are in the safe land of D to do the required string manipulation).

On 17/07/2020 05:34, Cecil Ward via Digitalmars-d wrote:
> On Thursday, 16 July 2020 at 15:08:39 UTC, Iain Buclaw wrote:
>> I am open to improving the syntax if that helps with interoperability between GDC and LDC.
>>
>> https://issues.dlang.org/show_bug.cgi?id=20594
> 
> Some very interesting ideas brought up there, Iain. Good stuff. I would very much welcome some of those developments. Would it be possible to be possible to have multiple alternative syntaxes so we don’t have to deprecate anything just because of its age?
> 

Yes, if the proposed style is adopted, you can immediately tell which style you should be parsing as during or after the first parsed expression.

e.g:

  asm {
    insn: "foo";  // Seen a label -> consume insn string and parse rest as new style.
  }

  asm {
    "bar",        // Seen a comma (,) instead of a colon (:) after insn, parse rest as new style.
  }

I'm sure there's a few more things that need to be ironed out first though before I seriously consider any work on it.


> I must say I do like the power of the GCC/GDC asm binding interface / ‘glue’ system that connects the high level language to the asm. The notation is hard to understand in places though and your ideas provide a way to go even further and make big improvements in readability and learning curve. I keep having to reread the docs concerning returned / modified input registers and so on.
> 

It's a pretty brute tool.  I prefer to call it a glorified asm_printf(), where the onus is on you to tell the compiler what is happening, rather than the compiler trying to understand what you mean (which is what you get with DMD-style iasm).

> Idea. Perhaps someone could write an asm binding system notation -> english decoder, a tool that you could run to tell you what your asm binding interface definition is doing. Output in long-winded and explicit english and including things such as lists of possibilities for registers you are selecting or restricting an operand to bind to. I haven’t expressed myself very well here but I hope someone gets the drift.
> 
> Perhaps I should do binding definitions for every x86-64 instruction. That would keep me busy.

You mean, like in compiler-explorer?

https://explore.dgnu.org/z/LWqJdi

Hover over the asm instructions to see explanations.