Good point. Also * the high bits are free now, but they may not be free forever (though that's not a great reason to avoid using them in the meantime) * masking off the high bits when entering is rather expensive, at least in code size, compared to a simple "jmp *%rax" or especially "jmp *symb", which appears at the end of almost every Haskell function * modifying the low bits of a pointer will leave it pointing at the same cache line, so the hardware prefetcher may decide to prefetch the contents (hopefully at an appropriate time) while modifying the high bits will make it not look like a pointer at all. But it's hard to know how much we currently gain from hardware prefetching, if anything. Certainly these downsides are not necessarily deal-breakers, as demonstrated by NaN-boxing as used in major JavaScript engines. What did you intend to use the high bits for? Regards, Reid Barton On Wed, Sep 7, 2016 at 11:16 PM, Edward Kmett wrote:

Mostly just that GHC still works on 32 bit platforms.

-Edward

On Wed, Sep 7, 2016 at 5:32 PM, Ryan Newton wrote:

...

Our heap object header is one word -- an info table pointer.

Well, a 64 bit info table pointer leaves *at least* 16 high bits inside the object header for other purposes, right?

Is there any problem with using these other than having to mask the info table pointer each time it is dereferenced?

Thanks, -Ryan

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs