On Saturday, 6 March 2021 at 15:40:56 UTC, Rumbu wrote:
> On Saturday, 6 March 2021 at 12:15:43 UTC, Mike Parker wrote:
>> [...]
>
> Where exactly is documented the extern(D) x86-64 calling convention? Because currently seems like a mess according to the dissasembly. First X parameters on stack from left to right, last 4 in registers. But wait, if you have less than 4 parameters, they are passed in register. Again, WTF?

Reading this, I'm experiencing true fear for the first time in my life.

On Saturday, 6 March 2021 at 16:09:03 UTC, Imperatorn wrote:
> On Saturday, 6 March 2021 at 15:40:56 UTC, Rumbu wrote:
>> On Saturday, 6 March 2021 at 12:15:43 UTC, Mike Parker wrote:
>>> [...]
>>
>> Where exactly is documented the extern(D) x86-64 calling convention? Because currently seems like a mess according to the dissasembly. First X parameters on stack from left to right, last 4 in registers. But wait, if you have less than 4 parameters, they are passed in register. Again, WTF?
>
> Reading this, I'm experiencing true fear for the first time in my life.

I'm also learning that extern(D) is different across compilers in some cases, but it isn't that bad.

Preferred ABI boundaries across executables is extern(C).
If you deal with static librariries, then they are likely built from the same compiler too.

When LDC change the extern(D) ABI, it is rightfully a minor change as everything will get rebuilt. https://github.com/ldc-developers/ldc/releases/tag/v1.25.0

Besides, such changes are there for efficiency :)

On Friday, 5 March 2021 at 12:57:43 UTC, z wrote:
> ...

Then it seems the only way to get AVX-compatible inline assembly(ldc.llvmasm excluded) is to use an external assembler.

For example :
>import std.stdio;
>extern(C) void vxorps_d(ubyte[32]*);
>
>void main() {
>	ubyte[32] a = 2;
>	writefln!"Contents of a before : %( %s %)"(a);
>	vxorps_d(&a);
>	writefln!"Contents of a after  : %( %s %)"(a);
>}



>BITS 64
>
>global vxorps_d
>
>section .text2
>vxorps_d:
>	vmovups ymm0, [rcx];
>	mov rdx, zerofilled
>	vbroadcastss ymm1, [rdx]
>	vxorps ymm0, ymm0, ymm1
>	vmovups [rcx], ymm0
>	ret
>zerofilled:
>db 0xFF,0xFF,0xFF,0xFF

>nasm -g -f win64 asmfile.asm

>dmd vxorpstest.d asmfile.obj -m64
>ldc vxorpstest.d asmfile.obj -m64

>vxorpstest.exe
>Contents of a before :  2  2  2... (0x02/0b0000_0010)
>Contents of a after  :  253  253  253...(0xFD/0b1111_1101)

On Tuesday, 9 March 2021 at 20:23:48 UTC, z wrote:
> On Friday, 5 March 2021 at 12:57:43 UTC, z wrote:
>> ...
>
> Then it seems the only way to get AVX-compatible inline assembly(ldc.llvmasm excluded) is to use an external assembler.
>
> For example :
>>...
But i'm not really sure how to integrate that into a dub project, it seems «lflags "filename.obj"» and preGenerateCommands/preBuildCommands would work but i haven't tested that.(«dflags "filename.obj"» doesn't work for sure)

On Tuesday, 9 March 2021 at 20:33:01 UTC, z wrote:
> On Tuesday, 9 March 2021 at 20:23:48 UTC, z wrote:
>> On Friday, 5 March 2021 at 12:57:43 UTC, z wrote:
>>> ...
>>
>> Then it seems the only way to get AVX-compatible inline assembly(ldc.llvmasm excluded) is to use an external assembler.
>>
>> For example :
>>>...
> But i'm not really sure how to integrate that into a dub project, it seems «lflags "filename.obj"» and preGenerateCommands/preBuildCommands would work but i haven't tested that.(«dflags "filename.obj"» doesn't work for sure)

In dub.sdl :
>lflags "source/asmfunctions.obj"
>preGenerateCommands " cd source && *command or bat/sh file that builds the asm object file(s)*"


It works, but if the package is being imported by another then it will fail because the way lflags work mean that the linker will try to find source/asmfunctions.obj from the working directory of the importer.
This is circumventable with relative paths(if possible).
>lflags "../importedpackagesname/source/asmfunctions.obj"