To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 3446
3445  |  3447
Subject: 
Re: Question about mm.C in BrickOS
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Mon, 15 Sep 2003 20:06:16 GMT
Viewed: 
2967 times
  
Michael Martelli wrote:

I don't understand what is meant by pointing behind the block.

Here is the original block of code:
============
1      if(*ptr>=size) {    // big enough?
2        *(ptr-1)=(size_t)ctid;  // set owner
3
4              // split this block?
5        if((*ptr-size)>=MM_SPLIT_THRESH) {
6          next=ptr+size+1;
7          *(next++)=MM_FREE;
8          *(next)=*ptr-size-MM_HEADER_SIZE;
9          mm_try_join(next);
10
11          *ptr=size;
12        }
===========

+---- +------+---------------------------+-----+------+--------
| pid | size | data.....                 | pid | size | data...
*-----+------+---------------------------+-----+------+--------
          ^
          +--------- ptr points to that address.

This is the memory layout for the data allocation pool. Pid is the
process id of the owner process, size is the size of the data block in
words. A free block gets the pid MM_FREE to indicate it could be used.

Now we allocate a block of 4 bytes for process #5:

+---------+-----+----------------------------+-----+------+--------
| MM_FREE | 500 | .....                      | pid | size | data...
*---------+-----+----------------------------+-----+------+--------
              ^
              +--------- ptr points to that address.


We find a free block of 500 words, 1000 bytes. Our 4 bytes will fit so
we first set the pid to or actual process id:

+-- +-----+----------------------------+-----+------+--------
| 5 | 500 | .....                      | pid | size | data...
*---+-----+----------------------------+-----+------+--------
        ^
        +--------- ptr points to that address.


We only need 4 bytes, we must split the block to a 4 bytes block and the
rest. We calculate the address of "pid" after the 4 bytes block:

next = (adress ptr points to) + 2 will point to the last word of our
block, adding 1 to it will point directly after the last byte. This is
the position for the new pid.

+-- +-----+----------------------------+-----+------+--------
| 5 | 500 | .....                      | pid | size | data...
*---+-----+----------------------------+-----+------+--------
        ^                                  ^
        |                                  +- next points to this address
        +--------- ptr points to that address.

Now we set pid to MM_FREE

+-- +-----+----------------------------+---------+------+--------
| 5 | 500 | ........                   | MM_FREE | size | data...
*---+-----+----------------------------+---------+------+--------
        ^                                  ^
        |                                  +- next points to this address
        +--------- ptr points to that address.


and we inc next:

+-- +-----+----------------------------+---------+------+--------
| 5 | 500 | .....                      | MM_FREE | size | data...
*---+-----+----------------------------+---------+------+--------
        ^                                            ^
        |             next points to this address----+
        +--------- ptr points to that address.


Ok. What is the amount of free mem? In the example:

    *ptr is 500;
    we took 4 bytes ( 2 words ) and the header takes 2 words, too. The
rest is *ptr - size - MM_HEADER_SIZE = 496. Insert at *next:

+-- +-----+----------------------------+---------+-----+--------
| 5 | 500 | .....                      | MM_FREE | 496 | data...
*---+-----+----------------------------+---------+-----+--------
        ^                                            ^
        |             next points to this address----+
        +--------- ptr points to that address

If the next block is a free block, too, we could join both, this is
checked in mm_try_join();

The last step is to insert the size for the memory block for process #5:

+-- +---+----------------------------+---------+-----+--------
| 5 | 2 | .....                      | MM_FREE | 496 | data...
*---+---+----------------------------+---------+-----+--------
       ^                                          ^
       |           next points to this address----+
       +--------- ptr points to that address

2 means two words, 4 bytes. The calling process has no idea of the
overhead for the OS, it expects to get the first address of the usable
area, i.e. the address after ptr. Therefore, ptr+1 is returned.

Hope it makes things clearer,

Regards,

Michael



Message has 1 Reply:
  Re: Question about mm.C in BrickOS
 
(...) Yes it does, thank you very much Michael, you helped me out again. I just wasnt thinking of next as being a ptr like that. i just always thought it pointed to the address of the location of the memory that it can use next. thanks again... Mike (21 years ago, 15-Sep-03, to lugnet.robotics.rcx.legos)

Message is in Reply To:
  Re: Question about mm.C in BrickOS
 
(...) Michael I was reading through your reply you sent me a while back and I don't understand what that line in the code does and you explaination of it. I don't understand what is meant by pointing behind the block. Any help would be great thanks. (...) (21 years ago, 14-Sep-03, to lugnet.robotics.rcx.legos)

7 Messages in This Thread:



Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR