source: project/release/4/numbers/trunk/TODO @ 31578

Last change on this file since 31578 was 31578, checked in by sjamaan, 6 years ago

numbers: Remove TODO: inlining bignum ops into integer ops just makes it less readable and generally messier. Slower, too!

File size: 3.7 KB
Line 
1-*- org -*-   
2* See if it's possible to move variadic procedures into C
3  This could be kind of tricky considering we have to allocate
4  bignums.  Maybe use a destructive operation where possible?  But the
5  initial allocation still needs to happen (we don't want to clobber
6  input args).  Perhaps moving allocation to the heap makes it easier,
7  but I kind of doubt that, considering we need to pass a GC
8  continuation in case the heap is full.
9
10* Integration into core
11  For integration into core, a few more things need to happen,
12  approximately in this order:
13** Add serialization/deserialization of bignums to C
14   Structs are already serialized correctly by core.  This fact is
15   already exploited by the numbers-syntax hack.  But to make the
16   resulting C code portable across architectures, we'll need some way
17   to serialize bignums (eg, a 40-bit number would be a bignum on a
18   32-bit system, but a fixnum on a 64-bit system).  We could simply
19   use a string-based solution, but I don't know how well that plays
20   with the GC & allocator: I think the total memory size needed for
21   all literals is calculated up front. 
22
23   If all else fails, we could make a pessimistic estimate based on
24   the size on a 32-bit system, or use #ifdef.  But a better solution
25   would be to have some sort of "packed" blob representation.  Then
26   the number of words could be pretty easily calculated (total bits
27   in the blob divided by this platform's bignum digit size).
28** Hardwired rewrite-rules must be reviewed and updated
29   Besides the specialization types database (which we already have an
30   updated version of), there's the weird rewrite-rules in
31   c-platform.scm These need to be checked whether they still rewrite
32   to any C numops that don't exist anymore, and whether the
33   inline_allocate sizes are still correct.
34*** Question: (How) does this interfere with bootstrapping ability?
35    I assume that an old compiler will still apply these rewrite-rules
36    when compiling a CHICKEN with bignum support.  If this is correct,
37    we'll probably need to tag an intermediate version which still has
38    all the old deprecated C functions, so that it can be compiled
39    with an old CHICKEN, and it itself can compile the new CHICKEN
40    which has only the new functions.
41** Add bignum support to the FFI
42   One of the current problems with core is that 63 and 64-bit
43   integers get precision loss when converting back and forth to
44   Scheme due to flonum conversion.  The FFI should raise an exception
45   when trying to pass a flonum to an "int" argument, and if you pass
46   a bignum, it should attempt to fit it into the native integer.  If
47   that fails, an exception should be raised (much like we do with the
48   embedded NUL check for strings).  Returning from C (and retrieving
49   a value from a locative) is always possible, but may result in a
50   bignum being allocated.  This may mean we need to move some stuff
51   around.  Foreign calls currently are probably "allocating
52   inline".  This may still work, because the maximum size of such a
53   FFI int->bignum conversion is fixed, but it needs some additional
54   thought to make it work correctly.
55*** Question: should implicit ratnum->float conversion be done?
56** Integrate into the scrutinizer
57   At the very least, bignums will need to be added to the scrutinizer
58   because they'll be a new distinct type.  The strange "number" type
59   will need to be changed (or removed) as well.  Compnums and ratnums
60   could be added, but is probably not necessary.
61** Compiler code for "fixnum", "float" and "generic" mode must be reviewed and updated
62   Maybe a new "integer" mode should be added, so that
63   performance-critical code can finally use bignums.
Note: See TracBrowser for help on using the repository browser.