Add parser and some semantic support for gdc extended asm statements

[ibuclaw]

You'll never accept this, as it's not used anywhere except in gdc.

But, is a revival nonetheless of #4472 which came from #2194 originally.

[dlang-bot]

Thanks for your pull request, @ibuclaw!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#7562"

[PetarKirov]

I wonder if there exists a common subset between the GDC and LDC (non-IR) inline asm (https://wiki.dlang.org/LDC_inline_assembly_expressions), which we can agree on and add to the language, though I guess the main difficulty would be integration with dmd's backend.

[ibuclaw]

I wonder if there exists a common subset between the GDC and LDC (non-IR) inline asm

Changing syntax would break existing code though.

main difficulty would be integration with dmd's backend.

It's just a glorified printf, with some more bells and whistles.

[jacob-carlborg]

I'm not sure which syntax LDC and GDC are using but Clang is compatible with GCC [1].

[1] https://clang.llvm.org/compatibility.html#inline-asm

[JinShil]

Forgive my ignorance, but I don't understand the motivation for this PR other than to elicit discussion.

It appears that this PR has only a parser and partial semantic support, but ultimately does nothing. Furthermore it's only ever used in GCC. Eventually, do we want to merge code like this so there is one code base shared between the 3 main compilers?

Personally, I would love to have one rich ASM syntax to use for all 3 compilers, but that doesn't seem to be the objective of this PR

You'll never accept this, as it's not used anywhere except in gdc.

I suspect that is an honest comment; not facetious.

As I've been reviving PRs, my goal has been to give those PRs a quick path to acceptance or a quick path to closure. What's the goal of this PR?

[wilzbach]

As I've been reviving PRs, my goal has been to give those PRs a quick path to acceptance or a quick path to closure. What's the goal of this PR?

@ibuclaw why did you revive this?

[ibuclaw]

I split the mega gdc diff pr into separate patches. From a maintenance standpoint there should be no difference between gdc and dmd frontends... But there is.

This is a problem, and dmd needs to be fixed or improved to allow support for these discrepancies to be implemented without touching the frontend.

[JinShil]

This is a problem, and dmd needs to be fixed or improved to allow support for these discrepancies to be implemented without touching the frontend.

If the plan is to have a single front-end code-base with compiler differences versioned, that's fine with me, but I'd like to hear from @WalterBright to ensure he's on board with that, and also @kinke @redstar @klickverbot and whoever else is on the LDC team.

[WalterBright]

You'll never accept this, but the dmd inline asm code is all Boost licensed now, so you can use it!! :-)

[WalterBright]

If the plan is to have a single front-end code-base with compiler differences versioned, that's fine with me, but I'd like to hear from @WalterBright to ensure he's on board with that, and also @kinke @redstar @klickverbot and whoever else is on the LDC team.

I'm on board with it, provided it is properly encapsulated. When support for it is distributed across numerous files, it is not encapsulated and will be an ongoing problem. There should be 4 files:

iasm.d         // the generic interface
iasmdmd.d  // the dmd version
iasmgcc.d    // the gcc version
iasmldc.d    // the ldc version

There should be minimal to no need for version if iasm.d is set up right.

As an example of what I mean, take a look at scanelf.d, scanomf.d, scanmach.d, and scanmscoff.d. Another example is libelf.d, libomf.d, libmach.d, libmscoff.d. Look, ma, no versions! I am pretty happy with how these have worked out, there has been little trouble with them, and the extra work in coming up with a generic interface turned out to be far less work in the end.

As an example of failure, look at cgobj.c, machobj.c, elfobj.c, mscoffobj.c. Well, sort of failure. I've been slowly moving to a generic interface, and it's getting better.

If we can do it with these files, we can do it with the inline assembler.

[jacob-carlborg]

There should be minimal to no need for version if iasm.d is set up right.

I'm not sure if it's possible, but I would prefer a single check in code over special casing the makefile.

[ibuclaw]

There should be minimal to no need for version if iasm.d is set up right.

As an example of what I mean, take a look at scanelf.d, scanomf.d, scanmach.d, and scanmscoff.d. Another example is libelf.d, libomf.d, libmach.d, libmscoff.d. Look, ma, no versions! I am pretty happy with how these have worked out, there has been little trouble with them, and the extra work in coming up with a generic interface turned out to be far less work in the end

Ahem, packages (iasm/, scan/, lib/ :-)

[ibuclaw]

I'm not sure if it's possible, but I would prefer a single check in code over special casing the makefile.

Well preferably, I, as a user of dmd frontend, should be able to omit including dmd and ldc iasm implementations in my local mirror without any compiler or build problems.

Runtime checks won't satisfy this requirement unless unsightly stubs are added.

[wilzbach]

Ahem, packages

I absolutely agree, but Walter doesn't like packages. I tried:

• dmd.ir
• dmd.visitors

Though everyone else noticing these PRs was in favor of those changes...

[wilzbach]

As an example of what I mean, take a look at scanelf.d, scanomf.d, scanmach.d, and scanmscoff.d. Another example is libelf.d, libomf.d, libmach.d, libmscoff.d. Look, ma, no versions! I am pretty happy with how these have worked out, there has been little trouble with them, and the extra work in coming up with a generic interface turned out to be far less work in the end.

To be fair these files use a version at the top as this makes it a lot easier for the various build setups (Dub, Ddox build, Ddoc build, Rdmd build, ...).

Well preferably, I, as a user of dmd frontend, should be able to omit including dmd and ldc iasm implementations in my local mirror without any compiler or build problems.

Yes. The following already works

rdmd myfrontendtool.d -I<dlang/dmd>/src -version=NoBackend -version=GC -version=NoMain

See #7782 and it would be cool if that continues to be the case ;-)

[wilzbach]

Looks like this was accidentally closed?

[ibuclaw]

Nope, closing was deliberate. The PR in #8538 replaced this.

[ibuclaw]

If I'm right, the diff between gdc and dmd frontend is now no more than 12 lines!

...

Ignoring the modules that I do not include in gdc (inline.d, builtins.d, target.d, etc...)