[mercury-users] dynamic linking, Guile

[Paul Bone]

On Tue, Feb 09, 2010 at 01:46:54PM +1100, Paul Bone wrote:
> 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.

*ahem* 16 + 1 = _17_  not 12.  Plus the 3 low tag bits = 20.  That's over one
million discrete values.

-------------- 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/28450bcf/attachment.sig>