Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs Books & Kits Visualisation Ecosystem Training Contact & Support




Last site update Jan 14 2014

Loading

less RAM space then we are using A_BLOCK_LINK

Posted by Dmitriy on November 14, 2007
We can use less RAM space then we are using A_BLOCK_LINK in heap_2.c
Look!!!!!!


typedef struct A_BLOCK_LINK
{
struct A_BLOCK_LINK *pxNextFreeBlock;/*<< The next free block in the list. */
size_t xBlockSize;/*<< The size of the free block. */
} xBlockLink;

Let's change to

typedef struct A_BLOCK_LINK
{
size_t xBlockSize;/*<< The size of the free block. */
struct A_BLOCK_LINK *pxNextFreeBlock;/*<< The next free block in the list. */
} xBlockLink;

We do not need to save RAM space to pxNextFreeBlock;
Let return not pxPreviousBlock->pxNextFreeBlock + heapSTRUCT_SIZE
Just we need to return pxPreviousBlock->pxNextFreeBlock + size_of (size_t)

And also wanted space not xWantedSize += heapSTRUCT_SIZE;

just xWantedSize += + size_of (size_t);


RE: less RAM space then we are using A_BLOCK_LINK

Posted by Richard on November 18, 2007
Thanks for your suggestion. I need to understand this a bit better:

>typedef struct A_BLOCK_LINK
>{
>struct A_BLOCK_LINK *pxNextFreeBlock; /*<< The next free block in the list. */
>size_t xBlockSize;/*<< The size of the free block. */
>} xBlockLink;
>
>Let's change to
>
>typedef struct A_BLOCK_LINK
>{
>size_t xBlockSize;/*<< The size of the free block. */
>struct A_BLOCK_LINK *pxNextFreeBlock; /*<< The next free block in the list. */
>} xBlockLink;


So you have switched the xBlockSize and pxNextFreeBlock within the structure.

>We do not need to save RAM space to pxNextFreeBlock;
>Let return not pxPreviousBlock->pxNextFreeBlock + heapSTRUCT_SIZE
>Just we need to return pxPreviousBlock->pxNextFreeBlock + size_of (size_t)

This is where I am not sure.

pxPreviousBlock->pxNextFreeBlock + heapSTRUCT_SIZE

is returned so that there is a xBlockLink structure at the start of the memory block. This must be there so the memory block can then be freed again if necessary.

Returning pxPreviousBlock->pxNextFreeBlock + size_of (size_t) would return the address of the next block pointer of the following block. Would this not then get written over by the task using the memory?

Can you please explain this to me a little more - thanks.

Regards.


RE: less RAM space then we are using A_BLOCK_

Posted by Dmitriy on November 19, 2007
>pxPreviousBlock->pxNextFreeBlock + heapSTRUCT_SIZE

>is returned so that there is a xBlockLink structure at the start of the memory block. This must be there so the memory >block can then be freed again if necessary.

It is necessary to save only size in memory block. There is no need to save all xBlockLink structure.


>Returning pxPreviousBlock->pxNextFreeBlock + size_of (size_t) would return the address of the next block pointer of the >following block. Would this not then get written over by the task using the memory?

Yes you are right.
It would be written over by the task using memory block. But then you will call memory free().
The space that was used for memory block will be used to store the other part of xBlockLink structure.
You will found a new vallue of pxNextFreeBlock and put it in the place after xBlockSize
You will put it in the space there task has been hold its data.

All we need is to save the fist element of structure - the size of memory block


P. S. Here I do not pay attention on Aligment. Let alignment_mask be 1 for the first time.



RE: less RAM space then we are using A_BLOCK_

Posted by Richard on November 19, 2007
Right - I understand. Because the pxNextFreeBlock is only used when then block is not allocated it can be overwritten when the block is allocated.

The alignment issue can be easily fixed by returning the address of the pxNextFreeBlock which is going to be overwritten, rather than just jumping over sizeof( size_t ) bytes. This way the alignment will be taken care of by the compiler when it lays out the structures.

Regards.

RE: less RAM space then we are using A_BLOCK_

Posted by Dmitriy A. Cherepanov on November 19, 2007
:-)

Well, I do not exactly understand about alignment

does it mean that I can do only this xWantedSize += sizeof( size_t )
or I need to do in that way xWantedSize += ( sizeof( size_t ) + ( sizeof( size_t ) % portBYTE_ALIGNMENT ) )
instead of xWantedSize += sizeof( xBlockLink )


And how about this lines of code

pvReturn = ( void * ) ( ( ( unsigned portCHAR * ) pxPreviousBlock->pxNextFreeBlock ) + ( sizeof( size_t ) + ( sizeof( size_t ) % portBYTE_ALIGNMENT ));

or just

pvReturn = ( void * ) ( ( ( unsigned portCHAR * ) pxPreviousBlock->pxNextFreeBlock ) + sizeof( size_t ) );

instead of
pvReturn = ( void * ) ( ( ( unsigned portCHAR * ) pxPreviousBlock->pxNextFreeBlock ) + sizeof( xBlockLink ));

RE: less RAM space then we are using A_BLOCK_LINK

Posted by Richard on November 20, 2007
In the structure:

typedef struct A_BLOCK_LINK
{
size_t xBlockSize;
struct A_BLOCK_LINK *pxNextFreeBlock;
} xBlockLink;

the compiler will ensure that pxNextFreeBlock has the correct alignment. If necessary it will put pad bytes between xBlockSize and pxNextFreeBlock. As you have pointed out, pxNextFreeBlock is not required by the task using the RAM and can be overwritten by such a task.

The xBlockLink structure is at the start of the RAM block. If you return [(start of RAM block) + sizeof( pxNextFreeBlock)] then if you have single byte alignment you will return the address of the pxNextFreeBlock structure member. However, if there are pad bytes between the xBlockSize and pxNextFreeBlock members then this will not be the case - you will instead return the address of one of the pad bytes.

Instead, if you return the address of the pxNextFreeBlock variable then you will also jump over the pad bytes. Probably something like this:

&( pxPreviousBlock->pxNextFreeBlock->pxNextFreeBlock )

although I have not tried this.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2013 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.