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

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

numbers: Marking numbers as mutable isn't going to work

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