Re: [Patch] bitmap_allocator.

[Dhruv Matani <dhruvbird at gmx dot net>]

On Wed, 2004-10-13 at 23:23, Paolo Carlini wrote:
> Dhruv Matani wrote:
> 
> >>"- Still *lots* of warning about insufficient alignment on ia64: it 
> >>seems you are
> >>still using casts to <unsigned int> and this is definitely not ok: 
> >>    
> >>
> >Ok, I have added a macro _BALLOC_ALIGN_BYTES by which you can set the
> >alignment in bytes at compile time itself. However, I don't think that I
> >can do away entirely with those reinterpret_casts to unsigned int. What
> >I have done is that whenever I do perform those casts, I make sure that
> >the memory is aligned to _BALLOC_ALIGN_BYTES.
> >  
> >
> I'm not sure to understand what you are trying to accomplish, but definitely
> doesn't work and now the code is littered with series of *three* consecutive
> reinterpret_cast!
> 
> Please send me a patch only removing those macros trigerring warnings at
> compile time and rethink the whole alignment issue at your ease: 

Sure thing!

> I 
> suggest just
> studying pool_alloc and mt_alloc about that, if you are careful 
> everything is
> rather simple and you don't need loads of casts.

Ok. Let me explain what I am trying to do: 
I have a pointer to some type T which is not the one parameterizing the
allocator. Now, it is guaranteed by the allocator that all pointers to T
are aligned to _BALLOC_ALIGN_BYTES.
Now, given a pointer T*, I want to find the corresponding bitmap for
that pointer, or perform the reverse operation of finding the memory
location T* for a given bit in the bitmap. These operations are all O(1)
only because there is a formula for each of them, which is expressed by
way of of those casts. What I'm basically doing is moving forward or
backward a specified number of bytes from a given location which I know
is aligned suitably for type T. How would I go about doing that without
casts? Moreover, I move forward/backward a number of bytes which is a
multiple of the alignment size, so I should be safe there. And in cases
where the number of bytes moved is not a multiple of the alignment size,
it is equivalent to accessing an array in C of that type.

Consider: on IA64. Alignment = 16-bytes?
unsigned int uiarray[2];
sizeof(uiarray) == ? (2*sizeof(unsigned int))?

Now, would accessing uiarray[1] break alignment requirements?

> 
> Anyway, let's assume that we are not going to fix that issue in this commit,
> we have already a big improvement wrt the existing situation and suffices
> for now.

Yes, I'll send the patch without the alignment issues fixed.

BTW, currently(with the alignment patch), does it fail on IA64? or just
the alignment warnings like before?

-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

The price of freedom is responsibility, but it's a bargain, because
freedom is priceless. ~ Hugh Downs