[Sbcl-devel] Removing the cross-float-infinity-kludge

[Douglas K. <do...@go...>]

Hi all,

I have a patch (somewhat still in progress) which will achieve the
following goals with respect to building SBCL under any host:
* eliminate use of the host's CL:TYPE-OF on floats/complex numbers, thereby
removing the WARN-POSSIBLE-CROSS-TYPE-FLOAT-INFO-LOSS and related code
* eliminate all occurrences of dual code paths for #+/-sb-xc-host in regard
to accepting signed zeros and infinities such as at
SCALE-FLOAT-DERIVE-TYPE-AUX

This change models target floating-point numbers as a DEFSTRUCT in the
host. I've put wrappers around all math functions to ensure that they
accept the wrapper object and do not receive host-native floats/complex,
and then for certain symbols which name the type specifiers, I fixed
UNCROSS to never do the wrong thing.
The last point is important: since SINGLE-FLOAT etc are used as symbols for
their identity, it would be really horrible to have the duality that exists
for SB-XC:thing and CL:thing, because it would be a logistical nightmare to
go through the code and make sure we didn't mean (EQ ZOT 'SB-XC:FLOAT)
everywhere we had (EQ ZOT 'CL:FLOAT).
This is all the more true for '* which is not only the multiply operator
but also the placeholder in type specifiers and nearly impossible to
shadow, unless you really like spelling your type specifiers as
(simple-array cl:* (cl:*)).
A final point, all float/complex structs are hash-consed so that at most
one which represents a given numerical value can exist. Therefore EQL = EQ
and the CL functions which implicitly use EQL on numbers are ok - like
ASSOC, FIND, EQUAL - despite that structures are not descended into by any
standard predicate other than EQUALP.

I believe that with this patch applied, we can begin to remove all the
reader conditionals and cruft. With a bit more testing I'll know for
certain.
Moreover, the cross-float support is intended to operate in one of two
modes (not done yet):
- use the host to perform math and write the results to a journal file, or
- use the journal to inform the host of the correct result of any math
operation.
This way if we have a host that can't answer correctly, we can just feed in
the response file from an SBCL-hosted build.

One thing that is slightly annoying, but I think necessary, is that I never
permit the host to so much as parse a floating-point literal.  Instead
every literal has to be written with $ in front so that it invokes a reader
macro. In this manner, if the host were to treat the exponent marker
differently than we do, we will get the right subtype of float.

Please let me know if there are major concerns regarding the syntax change.
I'm thinking of doing that as one commit all by itself since it essentially
a no-op: we can just put the macro in, just do the syntax change, and the
the actual substance of the patch will be a follow-on.

Doug