Frits van Bommel wrote:
Luckily, inline asm is treated as a function literal in LLVM, and it can return one or more values to the caller if the constraints string specifies which registers will contain them. So if LDC just specifies (e.g.) EAX/EDX:EAX/ST(0) to contain the result of the inline asm, it can get the value in the register(s) in question as an LLVM value that can be returned without any problem. The only really tricky bits are (a) figuring out how the constraints string works, exactly[1] and (b) figuring out which register(s) the return value should be in.
You understand the LLVM better than anyone else here <g>, so I suggest that you pick what you think will work best, and leave it at that for now. I don't think there's a good reason to get too stuck on this. If a better solution emerges during testing, it can be corrected.
For example, in my work on the OSX version of dmd, it turns out that OSX requires that the stack be aligned on 16 bytes whenever a function gets called. (If it isn't so aligned, the program crashes with a misaligned stack fault exception.) This naturally affects all 'naked' inline assembly, as well as all function calls made from inline assembly. I don't think there's any hope for the compiler automatically fixing this, and more importantly, the compiler *should not* automatically fix it. When you use inline assembler, you've got to expect that it won't be very portable.
I've gone through and corrected all the inline assembler in Phobos for this. There isn't much of it, and the fixes aren't difficult. It just comes with the territory of using inline assembler.
Another ABI difference is that on windows, reals take up 10 bytes. On linux, it's 12. On OSX, it's 16. The hardware operands still take up only 10, the rest is padding.
What is expected from the inline assembler, however, is that the syntax of the instructions remains the same, and it looks like you've got that one nailed.
