[MLton-devel] Int.precision is 32 bits?

[Jesper Louis Andersen]

Now, I would like to know the trick behind this. First follows what I do
know.

We have problem instructing the garbage collector what is pointers and
what is integers, so most implementations I know about does this by
using tagged arithmetic, since most pointers are aligned on at least a
4-byte boundary. I suspect this is what leads the Int.precision to be
SOME 31 on SML/NJ and Mosml for instance. 

Now, MLton has SOME 32 in this place. But how is that being managed?
Using 2 words per integer? Probably not since that would result in
integers being quite hard to work with since we need to copy a lot more
data each time we want to throw integers around. 

The best bet I've got up until now is that MLton instances every
polymorphic function, reaching a monomorphic language from which we
can decide the type of all values. By preserving this type, we can
instruct the GC to know exactly what is pointers and what is not.

What nags me is that poly->mono instantiaion like this can result in
code explosion so I do not really think it is the way it is done.

But enough betting, what is _really_ done here? What is the trick to
avoid tagged arithmetic on integers?

-- 
j. 



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel