Inline assembler in D and LDC, round 2

[Walter Bright]

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.