How to deal with inline asm functions in Phobos/druntime?

Johan Engelen via digitalmars-d-ldc digitalmars-d-ldc at
Tue Apr 7 11:15:56 PDT 2015

Hi all,
   I've hit on a problem that I know how to fix, but I do not know 
how to properly do it. Thanks for your help.

A number of functions have inline assembly implementations in 
Phobos, e.g. std.math.ilogb(). I don't know why exactly they have 
asm implementations for Windows. The default path 
"core.stdc.math.ilogbl(x);" would be fine on Windows. The problem 
is that LDC would take that same assembly code, although it 
assumes DMD calling conventions. Also, _much_ better code is 
generated when ldc.llvmasm inline assembly code is used for 
non-naked asm functions: for D-style naked asm, the generated 
code contains huge function pro-/epilogues. The LDC 
implementation without assumptions about calling conventions for 
MSVC-compatible ilogb would be:

         import ldc.llvmasm;
         return __asm!int(
            `fldl     $1         ;
             fxam                ;
             fstsw   %AX         ;
             and     $$0x45, %AH ;
             cmp     $$0x40, %AH ;
             jz      Lzeronan    ;
             cmp     $$5, %AH    ;
             jz      Linfinity   ;
             cmp     $$1, %AH    ;
             jz      Lzeronan    ;
             fxtract             ;
             fstp    %ST(0)      ;
             fistpl  (%RSP)      ;
             mov     (%RSP), $0  ;
             jmp     Ldone       ;
             mov     $$0x80000000, $0 ;
             fstp    %ST(0)           ;
             jmp     Ldone            ;

             mov     $$0x7FFFFFFF, $0 ;
             fstp    %ST(0)           ;

         Ldone: ;`, "=r,*m,~{ax},~{memory}", &x);

I think it'd be relatively straightforward to write the code such 
that it works for 80-bit and 64-bit reals.

My question: how do I fix our fork of Phobos? Do we just want to 
pass the call to core.stdc.math.ilogbl, and disregard the 
'optimized' inline asm? Or do we add "version(LDC) version 
(Win64)" or similar and add our own asm implementations?

It is fun to write these small asm blobs, but I am not sure how 
maintainable all this will be.

Confused :S


More information about the digitalmars-d-ldc mailing list