nullary _ffi's

[Matthew Fluet]

> There is a difference between the way the C and native backends are handling
> nullary ffi's, and an inconsistency (in my eyes) in how the native backend is
> handling them.  
>
> Any clues?

The bug was it x86-mlton.fun.  Here's the patch for the applyPrim
function:

	    | FFI s 
	    => (case Prim.numArgs oper
		  of NONE 
		   => let
			val (dst,dstsize) = getDst ()

			val memloc
			  = makeContents 
			    {base = Immediate.label (Label.fromString s),
			     size = dstsize,
			     commit = MemLoc.Commit {isTemp = false,
						     onFlush = true},
			     class = MemLoc.Runtime}
		      in
			[Block.T'
			 {label = NONE,
			  statements
			  = [case Size.class dstsize
			       of Size.INT 
				=> Assembly.instruction_pmov 
				   {oper = Instruction.Normal,
				    dst = dst,
				    src = Operand.memloc memloc,
				    size = dstsize}
				| Size.FLT 
				=> Assembly.instruction_pfmov
				   {oper = Instruction.Normal,
				    dst = dst,
				    src = Operand.memloc memloc,
				    size = dstsize}
				| _ => Error.bug "applyPrim: FFI"],
			  transfer = NONE}]
		      end
	           | SOME _ => applyFF {label = Label.fromString s,
					args = args,
					dst = dst,
					entersRuntime = false})


In the old way, it was a move from a label to a destination; in the new
way it is a move from a memory location to a destination.  The difference
shows up in the register allocator.  For floating point, there is no
notion of pushing an immediate value onto the stack; so the label was
automatically "upgraded" to an address.  On the other hand, for
non-floating-point moves, it's reasonable to move the immediate value of a
label to a destination (e.g., when storing the return address on the
stack), so labels weren't "upgraded."  That's what was happening with the
old version.

Now, the translation is move the memory location marked by the label to
the destination.  That will work for both fp and non-fp moves.

At some future time, I might actually completely cut the Label variant of
the x86.Operand.t datatype.  It's confusing sometimes to know whether you
want the immediate form of the label or the address form of the label.
The x86.Operand.t datatype has an Immediate variant (which in turn has a
Label variant) and also a MemLoc/Address variant, which can index off of
an Immediate (i.e., we get back to the label through the immediate).  I'll
add it to my think-about/todo list.