Question about inline assembly in LDC
Cecil Ward
cecil at cecilward.com
Tue Aug 22 16:54:34 UTC 2023
On Tuesday, 22 August 2023 at 12:24:41 UTC, kinke wrote:
> On Monday, 21 August 2023 at 23:18:50 UTC, Cecil Ward wrote:
>> Does that mean that in principle LDC could understand
>> intel-style syntax but only if it knew in advance which type
>> of syntax was being used in the _whole_ thing, ie as opposed
>> to being told too late by a .intel_syntax directive? To get
>> interoperability between GDC and LDC then perhaps the two
>> compilers could have an external ‘dialect’ parameter that is
>> available before we get into the statements-body. Failing
>> that, LDC would need to look ahead for the likes of a
>> .intel_syntax directive with an auto detect-type initial
>> regex. Seeing as presumably no one ever switches dialects
>> other than at the start, then that would certainly work well.
>> I’m very good at proposing work for others. :-)
>
> Heh :D - sure, could be done, but don't count on me. AFAIK, 2
> different asm dialects only exist for x86[_64], one of many
> targets, so adding support for such an inherited legacy mess is
> not on my TODO list. And by the looks of it, you're an asm
> afficionado, but I don't recommend working at such a low level
> (in D) unless it can't be done otherwise (very few cases,
> druntime has some examples). Some reasons: readability,
> portability, poor compiler support for troubleshooting as
> you've seen (asm fragments are mostly a black box, for both LDC
> and the main LLVM passes), and premature optimization (asm
> fragments are a black box for the LLVM optimization passes, so
> using intrinsics and inline IR is much better, not just for
> portability to different archs, but also to let the optimizer
> know what you're doing).
I’m aware of the disadvantages. I would never recommend using
inline asm unless it’s either essential or it gives otherwise
unachievable performance benefits. I’m writing library functions
to make available instructions that you cannot access without
wrappers. I would never recommend using inline asm unless it’s
either essential or it gives otherwise unachievable performance
benefits. I’m writing libIt’s also a D learning project for me. I
was a very experienced professional asm programmer, a long long
time ago, before compilers became way too good. The GDC/LDC
implementation is so fantastically efficient, unlike the DMD
inline asm, that you can get literally zero-overhead asm fully
integrated into your code. It can even adapt an instruction’s
operands to handle memory accesses directly without needing to
make use of a register as an intermediate location where
applicable. LDC and GDC generate code with fs:addr operands when
the argument is a static in thread-local-storage. To me that’s
amazing sophistication from the compilers. In my little project,
I give pure D equivalents when I have not been able to offer
instructions for whatever the CPU is.
The prefetch case is one perfect example. Only experts should use
such a thing and then D cannot achieve the benefits on offer
without the CPU’s special instructions. Also using it and getting
the placement and usage wrong will certainly make performance
worse, so measurement before and after is needed to check that
you’re doing it right. And even then, changes to the code can
mess things up; the performance benefits are very fragile.
I do wish that D could handle Intel syntax as the ATT stuff hurts
my brain after years of doing things the standard way for that
processor. Is ARM code going to have the operands backwards way
round? (Actually I think the ATT order is preferable as it reads
better, but it’s down to what you have spent years doing and down
to having to read the CPUs’ documentation in a different syntax.)
I recently wrote something to fix the problem of LDC not being
able to handle named asm arguments. I was trying to avoid
conditional compilation and duplicated code form GDC and LDC, but
now I find that’s only one problem in the way of success, the
ATT-only thing being much worse.
Does GCC for C handle Intel syntax inline asm?
More information about the digitalmars-d-ldc
mailing list