[racket] 80-bit precision in Racket

I've adjusted the bytecode compiler so that it can deal with more local
types. To exercise the changes, fixnum results are tracked like flonum
results, although the JIT doesn't currently take advantage of fixnum
annotations.

Now, it should be easy to add

 #define SCHEME_LOCAL_TYPE_EXTNUM   3

and fill in the extnum consumers and producers in
wants_local_type_arguments() and produces_local_type(). Then the JIT
changes should go the way you expect.

I plan to clean up the JIT a little bit to make it easier to add extnum
unboxing, but that's a smaller set of changes. Let me know when you
start working, and I'll try to not change anything that would make it
difficult to merge. I imagine that we'll be happy to merge your changes
into the distribution.


At Fri, 9 Nov 2012 09:40:17 -0700, Matthew Flatt wrote:
> At Fri, 09 Nov 2012 19:34:00 +0400, Dmitry Pavlov wrote:
> > Matthew,
> > 
> >  > Your plan sounds workable, but I wonder whether you'll want the JIT to
> > > unbox extnums in the same way that it unboxes flonums. That's not as
> > > easy as the rest of the plan, but generalizing Racket's unboxing
> > > machinery to deal with more types is something that we can consider.
> > 
> > Surely we will need the JIT to unbox extnums. Could you please tell
> > why it is harder than the rest of the plan? Ten bytes worse than
> > eight? Alignment issues?
> 
> Unboxing is a collaboration between the JIT and the bytecode compiler.
> There are various "value is known to be a flonum" flags that are
> threaded through the compiler, bytecode, validator, and JIT. In some of
> those places, there's room for an extra bit of information, but in
> other places, we'll have to adjust representations to make room for
> more bits.
> 
> I'll look into this more. It would be nice to have fixnum unboxing, and
> maybe that would be a good experiment toward unboxing for other types
> as well.
> 
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users