Question about inline assembly in LDC

kinke noone at nowhere.com
Tue Aug 22 12:24:41 UTC 2023


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


More information about the digitalmars-d-ldc mailing list