[mercury-users] dynamic linking, Guile

Paul Bone pbone at csse.unimelb.edu.au
Tue Feb 9 13:46:54 AEDT 2010


On Tue, Feb 09, 2010 at 01:41:22PM +1100, Paul Bone wrote:
> On Tue, Feb 09, 2010 at 12:58:17PM +1100, Peter Wang wrote:
> > On 2010-02-09, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> > > On 09-Feb-2010, Peter Wang <novalazy at gmail.com> wrote:
> > > > The changes are not extensive and are not crucial; search for "mercury"
> > > > (case insensitive) in the boehm_gc directory.
> > > 
> > > At least one change from the default is crucial. By default, boehm considers
> > > only pointers to the first byte of a heap cell to be a reference to it,
> > > but due to our use of tagged pointers, any version used with Mercury programs
> > > has to consider any reference to any byte in the first word of heap cell
> > > to be a reference to it.
> > 
> > No, that is handled by calling GC_REGISTER_DISPLACEMENT(i) in
> > mercury_wrapper.c.  It is a standard Boehm GC feature, since before
> > version 2.2, judging by the change log.
> > 
> > Peter
> > 
> > P.S. I also came across the POINTER_MASK and POINTER_SHIFT macros.
> > If set, Boehm GC will preprocess candidate pointers using those values.
> > I wonder if there is any benefit to using that instead.
> 
> It could allow you to use high tag bits in a 64 bit pointer if you can prove
> that your heap will never point into certain high addresses.
> 
> Current AMD64 chips support a 48 bit address space, meaning that the 16 high
> order bits are unused (but must contain the same value is the 47th bit to be
> valid addresses.[1] Additionally Linux (and probably most other 64bit OSs) use
> a memory map divided in half by the 48th bit where the top half is kernel
> memory that userspace can't address anyway, See below.  Therefore there are 16
> high order bits available for our use in any pointer on Linux amd64.
> 
> 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
> hole caused by [48:63] sign extension
> ffff800000000000 - ffffffffffffffff (=47 bits) kernel space. here be dragons.
> 
>     1. http://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details
> 

Oh,  Furthermore, because we know that the 47th bit (if bit 0 is the first bit)
will allways be 0, then we get 13 high bits and the usual 3 low bits.

It feels like christmas.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/users/attachments/20100209/35271f2b/attachment.sig>


More information about the users mailing list