[Openmcl-devel] addenda RE: non-consing short float trap parameters

[Gary Byers]

A value in a PPC floating-point register is maintained as a 64-bit
double float (regardless of how it got there, e.g., whether it
was loaded from a 32-bit or a 64-bit memory location or whether it's
the result of a single- or double-precision arithmetic operation.)
Valid values that are loaded as IEEE single floats (or which are
the results of single-precision arithmetic operations) will have
exponents in the IEEE single float range and will not have as
much precision in their mantissas as will valid values loaded
as IEEE double-floats or the results of double-precision operations.

For example:

? (defppclapfunction foo ((x arg_y) (y arg_z))
   (get-single-float fp1 x)
   (get-double-float fp2 y)
   (bkpt)
   (blr))
FOO
? (foo 0.1 0.1d0)
Lisp Breakpoint
  While executing: #<Function FOO #x0000000104b81bfc>
? for help
[460] OpenMCL kernel debugger: f
f00 : 0x3FF0000000000000 (1.000000)
f01 : 0x3FB99999A0000000 (0.100000)
f02 : 0x3FB999999999999A (0.100000)

Floating-point registers f1 and f2 both contain 64-bit values that
approximate 0.1; the value (f1) that was loaded as a single float is a
much less precise approximation of 0.1 than the value that had been
produced/maintained as a "true" double-float is.

In general, you can't just "look at" a value in a PPC FPR and reliably
know whether it represents an IEEE single or double; in particular,
a C function can't reliably know this about any of its incoming FP
arguments, and the C convention on OSX states that the first 13 FP
arguments to a function are passed in FPRs.

A C function and does declare how it intends to use its floating-point
arguments, especially the magnitude and precision that it expects them
to have.  I think that it's therefore at least slightly better for an
FFI to be anal-retentive about insisting that FP args are of the
right type than it would be to be casual/sloppy about that, the
argument being that it's better to get a lisp error at FF-CALL
time than it would be to get mysterious misbehavior because the
C function's expectations were violated.  (The counterargument 
might be that it often doesn't matter that much and that it's
better to silently do the mostly-right thing than it is to be
finicky for potentially obscure reasons.)

I would not expect the nature of existing PPC floating point hardware
to change significantly in the future, though I could imagine that the
Cell and future PPC variants might offer additional ways of doing
floating-point (in the same sense that AltiVec has.)  I'd be equally
surprised if Apple decided to change their PPC ABI and (for instance)
pass all FP arguments in memory.

On Tue, 7 Mar 2006, James Anderson wrote:

>
> hello again;
>
> ?3 i observe that, if doubles are passed where the interface specifies singles,
> (some of) the operations (appear to) work. that is for something like
>
> (mach-o-function CGContextMoveToPoint
>                 (POINTER FLOAT FLOAT)
>                 VOID
>                 "ApplicationServices.framework#CGContextMoveToPoint")
>
> it appears to work to treat it as
>
> (mach-o-function CGContextMoveToPoint
>                 (POINTER DOUBLE DOUBLE)
>                 VOID
>                 "ApplicationServices.framework#CGContextMoveToPoint")
>
>
> hmm...
>
> the ppc linkage documentation seems to imply that, in some cases, this should
> actually be "ok". because a small number of single and double arguments are
> passed in the same way - in float registers.
>
> ?3.1 is that the way that the ppc trap operations really handle floats?
>
> ?3.2 will this necessarily stay that way (for the life of the ppc)?
>
> ?3.3 is there any general consensus about whether this is "the right thing to
> do"? is "short-sighted"? is "unsupported"?
>
> ...
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>