www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Inter-compiler portability of asm between gdc and ldc2 (and dmd)

reply Cecil Ward <cecil cecilward.com> writes:
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.

I wish that the two could converge on a syntax that has the best 
features of each. Alternatively perhaps I should be building 
something that writes out the correct source code according to 
which compiler is being used. There are rather too many ways of 
going about such a thing.

Could anyone give me some advice about the pros and cons of the 
various ways of dealing with this?

Has anyone for example done something using templates or 
mixin-ful goodness generating code on-the fly?

Alternatively I could just give up and be forced to maintain two 
parallel implementations of certain modules forever more, 
provided there is zero runtime overhead, no cost in terms of 
speed or bloat.
Jul 14 2020
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 15 July 2020 at 00:26:13 UTC, Cecil Ward wrote:

 Has anyone for example done something using templates or 
 mixin-ful goodness generating code on-the fly?

 Alternatively I could just give up and be forced to maintain 
 two parallel implementations of certain modules forever more, 
 provided there is zero runtime overhead, no cost in terms of 
 speed or bloat.


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 ;)
Jul 15 2020
next sibling parent reply claptrap <clap trap.com> writes:
On Wednesday, 15 July 2020 at 07:34:08 UTC, Stefan Koch wrote:

 On Wednesday, 15 July 2020 at 00:26:13 UTC, Cecil Ward wrote:

 Has anyone for example done something using templates or 
 mixin-ful goodness generating code on-the fly?

 Alternatively I could just give up and be forced to maintain 
 two parallel implementations of certain modules forever more, 
 provided there is zero runtime overhead, no cost in terms of 
 speed or bloat.


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


Do you pull them out manually or is there a way to get the start 
and end address of a function in a running program? So could I 
make an exe that when run dumps the bytes of one of its functions?
Jul 15 2020
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 15/07/2020 9:38 PM, claptrap wrote:

 
 Do you pull them out manually or is there a way to get the start and end 
 address of a function in a running program? So could I make an exe that 
 when run dumps the bytes of one of its functions?


Another option: 
https://stackoverflow.com/questions/1647359/is-there-a-way-to-get-gcc-to-output-raw-binary

Get gcc to dump the function (which doesn't use globals or other 
functions ext.) as a raw binary file. Then you can do a string import at 
compile time :)
Jul 15 2020
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 15 July 2020 at 09:38:38 UTC, claptrap wrote:

 On Wednesday, 15 July 2020 at 07:34:08 UTC, Stefan Koch wrote:

 On Wednesday, 15 July 2020 at 00:26:13 UTC, Cecil Ward 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 ;)


 Do you pull them out manually or is there a way to get the 
 start and end address of a function in a running program? So 
 could I make an exe that when run dumps the bytes of one of its 
 functions?


I dump em out using objdump.
I guess you could automate that.
Jul 15 2020
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Jul 15 2020
prev sibling next sibling parent reply kinke <noone nowhere.com> writes:
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.
Jul 15 2020
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Jul 15 2020
parent reply Cecil Ward <cecil cecilward.com> writes:
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.
Jul 15 2020
parent kinke <kinke gmx.net> writes:
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.
Jul 15 2020
prev sibling next sibling parent reply Cecil Ward <cecil cecilward.com> writes:
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.
Jul 15 2020
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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).
Jul 16 2020
parent reply Cecil Ward <cecil cecilward.com> writes:
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.
Jul 16 2020
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Jul 17 2020
parent reply Cecil Ward <cecil cecilward.com> writes:
On Friday, 17 July 2020 at 21:36:52 UTC, Iain Buclaw wrote:n (:)

On Friday, 17 July 2020 at 21:36:52 UTC, Iain Buclaw wrote:

 You mean, like in compiler-explorer?

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

 Hover over the asm instructions to see explanations.


I’ve used this website a lot. Matt Godbolt told me he isn’t the 
maintainer of it. It’s excellent. I’ve used Matt’s own high level 
multi-language website too. I just noticed the instruction 
definitions for the first time the other day. I am using an ipad 
so I can’t hover, and I can’t remember now how I managed to be 
able to see an instruction definition note. (I should explain - 
I’m (effectively) confined to bed due to illness so I don’t use a 
laptop or desktop PC any more, just the iPad.)
Jul 18 2020
next sibling parent reply Cecil Ward <cecil cecilward.com> writes:
On Saturday, 18 July 2020 at 23:10:22 UTC, Cecil Ward wrote:

 On Friday, 17 July 2020 at 21:36:52 UTC, Iain Buclaw wrote:n (:)

 On Friday, 17 July 2020 at 21:36:52 UTC, Iain Buclaw wrote:

 You mean, like in compiler-explorer?

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

 Hover over the asm instructions to see explanations.


 I’ve used this website a lot. Matt Godbolt told me he isn’t the 
 maintainer of it. It’s excellent. I’ve used Matt’s own high 
 level multi-language website too. I just noticed the 
 instruction definitions for the first time the other day. I am 
 using an ipad so I can’t hover, and I can’t remember now how I 
 managed to be able to see an instruction definition note. (I 
 should explain - I’m (effectively) confined to bed due to 
 illness so I don’t use a laptop or desktop PC any more, just 
 the iPad.)


I’ve just worked it out : on ipad a "long-press" on a particular 
line of asm brings up a context menu (I presume this is what the 
right mouse button produces) and the good stuff is in that menu, 
including x6 insn definitions. Many thanks
Jul 18 2020
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 19/07/2020 02:28, Cecil Ward via Digitalmars-d wrote:

 On Saturday, 18 July 2020 at 23:10:22 UTC, Cecil Ward wrote:

 On Friday, 17 July 2020 at 21:36:52 UTC, Iain Buclaw wrote:n (:)

 On Friday, 17 July 2020 at 21:36:52 UTC, Iain Buclaw wrote:

 You mean, like in compiler-explorer?

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

 Hover over the asm instructions to see explanations.


 I’ve used this website a lot. Matt Godbolt told me he isn’t the maintainer
of it. It’s excellent. I’ve used Matt’s own high level multi-language
website too. I just noticed the instruction definitions for the first time the
other day. I am using an ipad so I can’t hover, and I can’t remember now
how I managed to be able to see an instruction definition note. (I should
explain - I’m (effectively) confined to bed due to illness so I don’t use a
laptop or desktop PC any more, just the iPad.)


 
 I’ve just worked it out : on ipad a "long-press" on a particular line of asm
brings up a context menu (I presume this is what the right mouse button
produces) and the good stuff is in that menu, including x6 insn definitions.
Many thanks


They pull it all from the Intel software developers manual.

https://www.felixcloutier.com/x86/

https://github.com/compiler-explorer/compiler-explorer/blob/master/etc/scripts/docenizer.py
Jul 18 2020
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 19/07/2020 01:10, Cecil Ward via Digitalmars-d wrote:

 On Friday, 17 July 2020 at 21:36:52 UTC, Iain Buclaw wrote:n (:)
 
 On Friday, 17 July 2020 at 21:36:52 UTC, Iain Buclaw wrote:

 You mean, like in compiler-explorer?

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

 Hover over the asm instructions to see explanations.


 
 I’ve used this website a lot. Matt Godbolt told me he isn’t the maintainer
of it. It’s excellent. I’ve used Matt’s own high level multi-language
website too. I just noticed the instruction definitions for the first time the
other day. I am using an ipad so I can’t hover, and I can’t remember now
how I managed to be able to see an instruction definition note. (I should
explain - I’m (effectively) confined to bed due to illness so I don’t use a
laptop or desktop PC any more, just the iPad.)


Yes, I maintain it (and build the hundreds of gdc cross compilers that are used
on it :-)
Jul 18 2020
prev sibling parent reply Cecil Ward <cecil cecilward.com> writes:
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.
Jul 16 2020
parent reply kinke <noone nowhere.com> writes:
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
Jul 16 2020
parent reply Cecil Ward <cecil cecilward.com> writes:
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,
Jul 16 2020
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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).
Jul 17 2020
parent Cecil Ward <cecil cecilward.com> writes:
On Friday, 17 July 2020 at 21:03:46 UTC, Iain Buclaw wrote:

 On 17/07/2020 05:14, Cecil Ward via Digitalmars-d wrote:

 [...]


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


Many thanks Iain, that’s good of you. Your work is much 
appreciated as always.
Jul 17 2020
prev sibling next sibling parent Guillaume Piolat <first.name gmail.com> writes:
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. I 
 would like people to be able to build it alternatively using 
 LDC as well, and maybe even DMD.


If it's x86 assembly, perhaps consider moving it to 
intel-intrinsics. The same code should build on all 3 D compilers.
- It may also be faster than assembly when using LDC (don't know 
about GDC)
- and it will also build slower than assembly
Jul 15 2020
prev sibling next sibling parent Cecil Ward <cecil cecilward.com> writes:
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.

 I wish that the two could converge on a syntax that has the 
 best features of each. Alternatively perhaps I should be 
 building something that writes out the correct source code 
 according to which compiler is being used. There are rather too 
 many ways of going about such a thing.

 Could anyone give me some advice about the pros and cons of the 
 various ways of dealing with this?

 Has anyone for example done something using templates or 
 mixin-ful goodness generating code on-the fly?

 Alternatively I could just give up and be forced to maintain 
 two parallel implementations of certain modules forever more, 
 provided there is zero runtime overhead, no cost in terms of 
 speed or bloat.


Sorry, I should have explained - I meant writing out D sourcecode 
on the fly with mixin or whatever it is - still getting my head 
around that wondrous technology. I can definitely see the day 
coming when I no longer miss #defines.

As for writing out machine code at runtime - now there’s another 
question of mine some day - for another thread, would be better.

—
Jul 15 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/14/2020 5:26 PM, 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.


DMD's inline assembler syntax is what is used in Intel's CPU manuals. I 
sometimes wonder why other compilers don't do the same. It can be a bit wacky, 
but it's not that much code to implement and it makes following the code along 
with the manuals much easier.
Oct 02 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 2 October 2020 at 22:01:53 UTC, Walter Bright wrote:

 On 7/14/2020 5:26 PM, 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.


 DMD's inline assembler syntax is what is used in Intel's CPU 
 manuals. I sometimes wonder why other compilers don't do the 
 same. It can be a bit wacky, but it's not that much code to 
 implement and it makes following the code along with the 
 manuals much easier.


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.

Having studied compiler design as part of my major subjects, I 
say that the inline Assembly parser could build that information 
just as easily.
Oct 03 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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...
Oct 03 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
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);
}
Oct 03 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Oct 03 2020
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Oct 03 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Oct 03 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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...)
Oct 03 2020
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Oct 03 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 3 October 2020 at 22:38:45 UTC, Iain Buclaw wrote:

 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.


Gdc should for obvious reasons do whatever gcc does, don't get me 
wrong.

(There are provers that do can make inference from machine 
language at the bit level, but that is expensive to maintain. Not 
very open source friendly.)
Oct 03 2020
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Oct 03 2020
prev sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
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 ^^
Oct 03 2020
parent Guillaume Piolat <first.name gmail.com> writes:
On Saturday, 3 October 2020 at 22:37:05 UTC, Guillaume Piolat 
wrote:

 If anything, optimising a bottleneck with intrinsics takes 3x


without*
Oct 03 2020
prev sibling parent reply kinke <noone nowhere.com> writes:
On Saturday, 3 October 2020 at 08:51:58 UTC, Paulo Pinto wrote:

 On Friday, 2 October 2020 at 22:01:53 UTC, Walter Bright wrote:

 On 7/14/2020 5:26 PM, 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.


 DMD's inline assembler syntax is what is used in Intel's CPU 
 manuals. I sometimes wonder why other compilers don't do the 
 same. It can be a bit wacky, but it's not that much code to 
 implement and it makes following the code along with the 
 manuals much easier.


 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.

 Having studied compiler design as part of my major subjects, I 
 say that the inline Assembly parser could build that 
 information just as easily.


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.
Oct 03 2020
parent reply IGotD- <nise nise.com> writes:
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?
Oct 03 2020
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Oct 03 2020