Comments on: Ready, Set, Allocate! (Part 2) Hi Oodar, No worries. I should probably have re-iterated that information in Part 2. I'm still learning what works in blogs and what doesn't, considering this is only my 4th, I'm encouraged by the positive responses I've gotten so far. ;) Cheers, -Paul Hi Oodar,

No worries. I should probably have re-iterated that information in Part 2. I’m still learning what works in blogs and what doesn’t, considering this is only my 4th, I’m encouraged by the positive responses I’ve gotten so far. ;)

Cheers,
-Paul

]]>
By: Oodar/2011/04/26/ready-set-allocate-part-2/#comment-3386 Oodar Thu, 28 Apr 2011 23:01:14 +0000 Hi Oodar, Yes, on a 64-bit platform, a size_t would be a 64-bit unsigned integer. I specified the platform I am using in <a href="http://altdevblogaday.org/2011/04/11/ready-set-allocate-part-1/" rel="nofollow">Part 1</a> to try and avoid any confusion on the issue. Also, when I initially started writing my own memory allocators, I was working on the PSP, which is a 32-bit system, so my observations are probably colored by where I started. ;) Just another note about 64-bit systems is memory addresses will also be 64-bit (8 bytes), and not 32-bit (4-bytes). Cheers, -Paul Hi Oodar,

Yes, on a 64-bit platform, a size_t would be a 64-bit unsigned integer. I specified the platform I am using in Part 1 to try and avoid any confusion on the issue. Also, when I initially started writing my own memory allocators, I was working on the PSP, which is a 32-bit system, so my observations are probably colored by where I started. ;)

Just another note about 64-bit systems is memory addresses will also be 64-bit (8 bytes), and not 32-bit (4-bytes).

Cheers,
-Paul

]]>
By: Oodar/2011/04/26/ready-set-allocate-part-2/#comment-3373 Oodar Thu, 28 Apr 2011 11:26:09 +0000 Hi Garett, I store the alignment for a couple reasons. If any padding is added to align the allocation header, the offset to the begining of the allocation header can be calculated in the my_free method; this won't apply to the code as shown, unless someone takes the example and modifies the allocation header for their own purposes. Since the memory address returned from my_malloc begins at the start of the memory for the calling method to use, the size of the allocation must be known or calculated to be able to free all the memory, even in a situation where padding is added. Also in my realloc, I check to see if the requested alignment has changed from the original alignment. Cheers, -Paul Hi Garett,

I store the alignment for a couple reasons.

If any padding is added to align the allocation header, the offset to the begining of the allocation header can be calculated in the my_free method; this won’t apply to the code as shown, unless someone takes the example and modifies the allocation header for their own purposes. Since the memory address returned from my_malloc begins at the start of the memory for the calling method to use, the size of the allocation must be known or calculated to be able to free all the memory, even in a situation where padding is added.

Also in my realloc, I check to see if the requested alignment has changed from the original alignment.

Cheers,
-Paul

]]>
By: Garett Bass/2011/04/26/ready-set-allocate-part-2/#comment-3257 Garett Bass Tue, 26 Apr 2011 20:40:33 +0000 Always sweet to read allocation articles. Every article have a something new (or something I have forgotten) ;) Thanks for pleasant reading! Always sweet to read allocation articles. Every article have a something new (or something I have forgotten) ;)

Thanks for pleasant reading!

]]>
By: Paul Laska/2011/04/26/ready-set-allocate-part-2/#comment-3251 Paul Laska Tue, 26 Apr 2011 18:09:47 +0000 Actually, since alignment is always a power-of-two, you only need 4 bits to represent almost all reasonable alignments (by storing the exponent). Actually, since alignment is always a power-of-two, you only need 4 bits to represent almost all reasonable alignments (by storing the exponent).

]]>
By: Paul Laska/2011/04/26/ready-set-allocate-part-2/#comment-3248 Paul Laska Tue, 26 Apr 2011 17:25:25 +0000 <blockquote>Now, technically, a size_t, or 32-bit unsigned integer, for the uSize member is overkill for a 32MB memory heap (2^25 would suffice), but trying to go smaller isn’t possible with the current data types</blockquote> Actually 23 bits suffice if you require your allocations to be at least 4-byte aligned. That leaves 9 bits where you could store the alignment. Therefore if you're fine with allowing alignments of no more than 512 bytes your header can be 4 bytes, a single 32 bit integer bitfield.

Now, technically, a size_t, or 32-bit unsigned integer, for the uSize member is overkill for a 32MB memory heap (2^25 would suffice), but trying to go smaller isn’t possible with the current data types

Actually 23 bits suffice if you require your allocations to be at least 4-byte aligned. That leaves 9 bits where you could store the alignment. Therefore if you’re fine with allowing alignments of no more than 512 bytes your header can be 4 bytes, a single 32 bit integer bitfield.

]]>
By: Martin/2011/04/26/ready-set-allocate-part-2/#comment-3235 Martin Tue, 26 Apr 2011 10:11:43 +0000