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 <mfl...@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 >
____________________ Racket Users list: http://lists.racket-lang.org/users
