[racket] 80-bit precision in Racket

As much as I love Racket, there are certainly times I miss 'C' and it's
ability to write code pretty much in assembler. As co-creator of the first
commercial fractal generation software (FracTools, FracInt was free not
commercial) I found the need to code down to the bare metal and a bit
beyond chasing yet more and more resolution :) </sigh> Now back to the
regular discussion...

--hsm


On Fri, Nov 9, 2012 at 9:40 AM, Matthew Flatt <mflatt at cs.utah.edu> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121109/dc8561e0/attachment.html>