Selecting the Algorithm for BrickOS Memory Management Allocation

jaspersugarlandΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

66 εμφανίσεις




Selecting the Algorithm for BrickOS

Memory Management Allocation



Software Design Description



Michael Martelli, Jr.



Originally Submitted: October 21, 2003

Modifications: December 7, 2003



Submitted in partial fulfillment of the req
uirement of

CMPS 490


Computer Projects

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

2

Table of Contents

Software Design Description

................................
...............................

1

1.

Introduction

................................
................................
................................
.................

3

1.1

Purpose

................................
................................
................................
................

3

1.2

Scope

................................
................................
................................
...................

3

1.3

Glossary

................................
................................
................................
..............

4

1.4

References

................................
................................
................................
...........

5

1.5

Overview of this Document

................................
................................
................

5

2.

Deployment Diagram

................................
................................
................................
..

7

3.

Architectural Design

................................
................................
................................
...

8

3.1.

Abstract Specification and Interface Design Documentation

...........................

10

3.1.1.

New Memory Management Facili
ty

................................
.........................

10

4.

Data Structure

................................
................................
................................
...........

14

5.

Use Case Realizations

................................
................................
...............................

15

5.1.

Compile OS

with First Fit Method

................................
................................
...

15

5.2.

Compile OS with Next Fit Method

................................
................................
...

15

5.3.

Compile OS with Best Fit Method
................................
................................
....

16

5.4.

Compile OS with Worst Fit Method

................................
................................
.

16

5.5.

Compile OS with First Fit Method (Default)

................................
....................

17

5.6.

User Downloads Compiled OS to RCX (With Desired Memory Management
Algorithm) Then They Use the OS

................................
................................
...............

18

6.

Real
-
Time Design

................................
................................
................................
.....

19

7.

User

Interface Design

................................
................................
...............................

20

7.1.

Compile OS with First Fit Method

................................
................................
...

20

7.2.

Compile OS with Next Fit Method

................................
................................
...

20

7.3.

Compile OS with Best Fit Method
................................
................................
....

21

7.4.

Compile OS with Worst Fit Method

................................
................................
.

21

7.5.

Compile OS wit
h First Fit Method (Default)

................................
....................

22

7.6.

User Downloads Compiled OS to RCX (With Desired Memory Management
Algorithm) Then They Use the OS

................................
................................
...............

22

8.

Help System Design

................................
................................
................................
..

23

Index

................................
................................
................................
................................
.

24

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

3


1.

Introduction

1.1

Purpose

The purpose of this document is to address all the design issues prior to and during
implementation
of my new version of the BrickOS

memory management facility.
This document will serve as the guidelines for implementation by following the
design as stated in this document.


The primary audience for this document is for the individual
who will be
implementing this system, me


the software developer, Michael Martelli. My
classmates in CMPS 490 Senior Projects, Professor Plishka, and Dr. Bi are also
members of the audience that might find it useful to read this document.

1.2

Scope

This Soft
ware Design Document provides a complete description of the design of
my contribution to the new BrickOS

release, all apparent in the memory
management facility. My aspect of the project is the memory management
algorithms used by BrickOS
to allocate new memory blocks. This new Operating
System release is for the intended use of University of Scranton students engaging
in the Real
-
Time Systems class and the general community who also builds robots
using the Lego RCX

computer.


Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

4

The core architecture of my changes to the memory management facility of
BrickOS

follows a standard operating system design. It consists of additions and
modifications to key header and kernel files, specifically stdlib.h and mm.c, which
are found in the most recent release of the Operating System (0.2.6.10). The user
will accesses this new system via the make facility in Cygwin or ignore the changes
and use the Operating System like it has been used in the past


without noticing
any cha
nges to the environment.

1.3

Glossary

Best Fit

Algorithm

-

An MM algorithm that selects the free block in memory that is just
big enough and will result in the smallest amount of extra memory.


BrickOS

-

A new version of the LegOS operating system


An OS used to program the
Lego RCX

without using the GUI provided by Lego. It is based on the C programming
language.


BrickOS Task and Memory Monitor (BTMM)


-

Charles Mancinelli’s project that will
be used to monitor task and memory in the BrickOS

environment.


First Fit

Algorithm

-

An MM algorithm that selects the first free block of

memory from
the beginning or RAM that is big enough.


IR Tower

-

The device used to communicate from PC to RCX

and is used to send
programs the code to the RCX computer.


Kernel



The code that is the “brains”
of the operating system and provides all functions
that allows the OS to run.


Memory Management Facility

-

The facility of an operating system that provides
memory allocation and file protection.


Next Fit

Algorithm

-

An MM algorithm that is the same as first fit, but instead of
starting at the start of RAM, it starts looking for a free block form the last block of
memory used.


Users



Any person who uses BrickOS

to install and run programs on the RCX

robot.


Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

5

Worst Fit

Algorithm



An MM algorithm that selects the
largest free block that is big
enough hoping that there will be lots of extra space hence, av
oiding having little holes
that will be unable to be used in the future.

1.4

References

Dr. Martin’s Document Guide:
www.cs.scranton.edu/~dmartin/dsindex.html

Cygwin

website:
http://cygwin.com/

Lugnet
.com:
www.lugnet.com

BrickOS

Homepage:
http://brickos.sourceforge.net/

BrickOS

Release:
http://sourceforge.net/projects/brickos/

lugnet.robotics.rcx.legos newsgroup
http://www.lugnet.com/robotics/rcx/

Dr Bi’
s BrickOS
/RCX

references:
http://www.cs.scranton.edu/~bi/2003s
-
html/cs358/index.htm


Various papers my team submitted in the CMPS 374 course.

Martelli
, Jr., Michael C.
Selecting the Algorithm for BrickOS

Memory Management
Allocation
, Software Requirements Specification.

University of Scranton, 2003.

1.5

Overview of this Document

This Software Requirement Specifications document contains many

additional
chapters to aid in the understanding of my software endeavor. The former, Chapter
2, is called Deployment Diagram, and it defines and
shows the physical layout of
the system
. Its purpose is to help the customer understand the software design an
d
how it will perform (specifications). The next, Chapter 3, is called Architecture
Design and

is the “meat and potatoes” of the document. The Data Structure Design
is Chapter 4 and it discusses in detail the data structures used and how they are
implemen
ted. This document also contains the Use Case Realizations
, Chapter 5,
Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

6

and discusses the use cases step
-
by
-
step that were first mentioned in the Software
Requirement Specification. The next, Chapter 6, is the User Interface and mentions
the method by whi
ch the user will interact with the system. The second to last
chapter, Chapter 7, is the Help Structure of my changes to BrickOS

that will
hopefully be present in the next release. The final chapter will be the Index chapter
so a reader c
an more easily navigate through this document. These chapters, when
combined, work together to create the foundation that the software designer and
developer both need to ensure they share the correct vision of this product and it can
be completed properl
y.


Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

7

2.

Deployment Diagram


The Deployment Diagram

shows the physical layout of the system. The Operating
System code is first sent to from the user’s PC to the Lego RCX via IR Tower. The
user then downloads programs he/she wishes

to run on Lego RCX by again sending
the code from their PC to Lego RCX via IR Tower.



Figure 2.1

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

8

3.

Architectural Design


The Architectural Design

describes each entity of the system and their relationships
with each other a
nd their relationships to the actors of the system. Pictured here is the
BrickOS

kernel file that is going to be modified by me, mm.c. Of the many functions
and declaration in mm.c I will only be modifying one of them and then I will also

be
adding a few functions to the memory management facility. I will be including the
abstract specification of all mm.c functions that will be present in the final version of
BrickOS.

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

9


Figure 3.1


Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

10

3.1.

Abstract Specification and Interface Design Documenta
tion

3.1.1.

New Memory Management Facility

Name
:
malloc()


First Fit version (mmFirst.c)

Type
: Function.

Description
:

This is the same function that was originally called
malloc()
. T
he code had
to be re
-
named because each algorithm version of malloc needed to become
its own function. This function will return the address of the free block of the
requested size using the First Fit algorithm.

Operations
:

Name
:
malloc()
.

Arguments
: The
size of the block to be allocated.

Returns
: Returns the address of a free block that matched the requested
size.

Pre
-
Condition
: None.

Post
-
Condition
: The value returned is the address of the free block of the
requested size, if there was extra memory, it w
as removed from the block
and is now a separate block.

Exception
: If there is no available memory then a
NULL

value is returned.

Flow of Events
:

1.

Beginning at the first block of user memory search for a free block.

2.

If a block is found it checks to see if it

is big enough.

3.

If it is big enough it will set the pid of the block to the process that
requested the block.

4.

If the block has extra room, then it will try and split the block.

5.

If there are free blocks after the portion we split off then we try and join
al
l those blocks.

6.

The next free block is then searched for in memory by an external
function.

7.

The address of the block that was just allocated is returned.

8.

If a block is not allocated, then a
NULL

value is returned.

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

11

Name
:
malloc()


Next Fit version (mmNext
.c)

Type
: Function.

Description
:

This function performs the same task as the original malloc() except that
instead of always searching from the start of memory for free blocks it
searches from the last block alloca
ted. This function will return the address of
the free block of the requested size using the Next Fit algorithm.

Operations
:

Name
:
malloc()
.

Arguments
: The size of the block to be allocated.

Returns
: Returns the address of a free block that most closely m
atched the
requested size.


Pre
-
Condition
: None.

Post
-
Condition
: The value returned is the address of the free block of the
requested size, if there was extra memory, it was removed from the block
and is now a separate block.

Exception
: If there is no avai
lable memory then a
NULL

value is returned.

Flow of Events
:

1.

Beginning at the last block allocated it starts to search for a free block.

2.

If a block is found it checks to see if it is big enough.

3.

If it is big enough it will set the pid of the block to the pr
ocess that
requested the block.

4.

If the block has extra room, then we try and split the block.

5.

If there are free blocks after the portion we split off then we try and join
all those blocks.

6.

The next free block is then searched for in memory by an external
f
unction.

7.

Return the address of the block that was just allocated.

8.

If a block is not allocated, then a
NULL

value is returned.

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

12

Name
:
malloc()


Best Fit version (mmBest.c)

Type
: Function.

Description
:

This function

performs the same task as the original malloc() except that
instead of selecting the first free block of ample size, it searches for the
smallest free block of ample size available. This function will return the
address of the free block of the requested

size using the Best Fit algorithm.

Operations
:

Name
:
malloc()
.

Arguments
: The size of the block to be allocated.

Returns
: Returns the address of a free block that is of the smallest ample
size.

Pre
-
Condition
: None.

Post
-
Condition
: The value returned is th
e address of the free block of the
requested size, if there was extra memory, it was removed from the block
and is now a separate block.

Exception
: If there is no available memory then a
NULL

value is returned.

Flow of Events
:

1.

Beginning at the first block
of user memory search for a free block.

2.

If a block is found it checks to see if it is big enough.

3.

If it is big enough, it records the size of the block in the “size” variable.

4.

It continues to search memory for more free blocks and compares the size
of the
block found to the smallest, yet adequately sized, block it currently
found. The smallest (but with at least the same size that was requested)
block size value is then recorded in the “size” variable.

5.

After the smallest free block in memory is found, it
will set the pid of the
block to the process that requested the block.

6.

If the block has extra room, then we try and split the block.

7.

If there are free blocks after the portion we split off then we try and join
all those blocks.

8.

The next free block is then
searched for in memory by an external
function.

9.

Return the address of the block that was just allocated.

10.

If a block is not allocated, then a
NULL

value is returned.

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

13

Name
:
malloc()


Worst Fit version (mmWorst.c)

Type
: Function.

Description
:

This function performs the same task as the original malloc() except that
instead of selecting the first free block of ample size, it searches for the largest
free block available. This function will return the address of the
free block of
the requested size using the Worst Fit algorithm.

Operations
:


Name
:
malloc()
.


Arguments
: The size of the block to be allocated.


Returns
: Returns the address of a free block that is of the biggest size.


Pre
-
Condition
: None.

Post
-
Condition
:

The value returned is the address of the free block of the
requested size, if there was extra memory, it was removed from the block
and is now a separate block.


Exception
: If there is no available memory then a
NULL

value is returned.

Flow of Events
:

1.

Beg
inning at the first block of user memory search for a free block.

2.

If a block is found it checks to see if it is big enough.

3.

If it is big enough, it records the size of the block in the “size” variable.

4.

It continues to search memory for more free blocks and

compares the size
of the block found to the biggest block it currently found. The biggest
block size value is then recorded in the “size” variable.

5.

After the largest free block in memory is found, it will set the pid of the
block to the process that req
uested the block.

6.

If the block has extra room, then we try and split the block.

7.

If there are free blocks after the portion we split off then we try and join
all those blocks.

8.

The next free block is then searched for in memory by an external
function.

9.

Retur
n the address of the block that was just allocated.

10.

If a block is not allocated, then a
NULL

value is returned.


Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

14

4.

Data Structure


There are no data structures

or databases used in this project.


Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

15

5.

Use Case Realizations

5.1.

Compile OS with

First Fit Method



Figure 5.1


5.2.

Compile OS with Next Fit Method



Figure 5.2

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

16

5.3.

Compile OS with Best Fit Method



Figure 5.3

5.4.

Compile OS

with Worst Fit Method



Figure 5.4

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

17

5.5.

Compile OS with First Fit Method
(Default)


Figure 5.5

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

18

5.6.

User Downloads Compiled OS to RCX (With Desired Memory
Management Algorit
hm) Then They Use the OS


Figure 5.6



Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

19

6.

Real
-
Time Design


My project is one that involves modifying of kernel code of the BrickOS

Operating
System. BrickOS is a real
-
time operating system so real
-
time timing const
raints must
be meet constantly. I however, am not really adding any code or functions that add a
great amount of delay, if any, to this system. My contribution to the memory
management facility will be major but will only be in the form of additional
alg
orithms that, hopefully, will speed up the allocation of memory and should also
result in the ability to use more of the memory available on the RCX. Because this
operating system is a real
-
time system all timing constraints will be meet and I have
had th
at issue in mind since day on as one of the biggest issues I dealt with.
Currently, after studying and performing great amounts of research on BrickOS along
with coding, thus far, all timing constraints will be meet with ease.


Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

20

7.

User Interface Design


7.1.

Com
pile OS with First Fit Method


If the user enters
make first

instead of
make

when they compile the
Operating System the first fit algorithm will be used. This command is entered
while in the main BrickOS direc
tory.


Figure 7.1


7.2.

Compile OS with Next Fit Method


If the user enters
make next

instead of
make

when they compile the Operating
System the next fit algorithm will be used. This command is entered while in th
e
main BrickOS directory.


Figure 7.2







Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

21






7.3.

Compile OS with Best Fit Method


If the user enters
make best

instead of
make

when they compile the Operating
System the best fit algorithm will be used. This
command is entered while in the
main BrickOS directory.


Figure 7.3


7.4.

Compile OS with Worst Fit Method


If the user enters
make worst

instead of
make

when they compile the
Operating System the worst fit algorit
hm will be used. This command is entered
while in the main BrickOS directory.


Figure 7.4

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

22

7.5.

Compile OS with First Fit Method
(Default)

If the user enters
make
when they compile the Operating System the first f
it
algorithm will be used, by default. This command is entered while in the main
BrickOS directory.


Figure 7.5



7.6.

User Downloads Compiled OS to RCX (With Desired Memory
Management Algorithm) Then They Use the OS

After the use has compiled they OS with th
e desired memory management
algorithm they now have to download it to the RCX
. This must be done from the
/util directory. After it is downloaded then can also download their user programs
if they wish.


Figure 7.6



Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

23

8.

Help System Design

The Help System
for my new version of the BrickOS

memory management facility
will be very minimal. The only help feature will be a few lines of comments in the
top of the mm.c file that is apart of the kernel system files. I will not
provide too
much help on this system because most users should be very familiar with current
versions of BrickOS and the only main different between this new release ands
previous ones is that way which you compile the OS. All the details of how to use
th
e system will mention in detail in the User Manual. User who do not know how to
use the system will still be able to use brickos0.2.6.10mm because the default
algorithm feature that was added. If the user does not specify which memory
management algorith
m they wish to use, first fit will be chosen by default. I will also
have detailed instructions on my Senior Project website,
http://www.cs.scranton.edu/~mcm6/SrProj.html

explaining the changes

made to the
kernel and how to use them.

Selec
ting the Algorithm for BrickOS Memory Management Allocation

Software Design Document



Modified: December 7, 2003

24

Index

Architectural Design, 8

BrickOS, 1, 3, 4, 5, 6, 8, 19, 23

BrickOS Task and Memory Monitor
(BTMM), 4

Cygwin, 5

Data Structure, 14

deployment diagram, 7

Help System, 23

Kernel, 4

Lugn
et, 5

Memory Management Algorithm

Best Fit, 4

First Fit, 4

Next Fit, 4

Worst Fit, 5

Memory Management Facility, 4, 10

RCX, 3, 4, 5

Real
-
Time Design, 19

Specification

malloc()


first fit, 10

malloc()


best fit, 12

malloc()


next fit, 11

malloc()


worst
fit, 13

USB Tower, 4

Use Case

User Choosing Bext Fit, 16

User Choosing First Fit, 15

User Choosing Invalid Algorithm, 17

User Choosing Next Fit, 15

User Choosing Worst Fit, 16

User Inteface

User Choosing First Fit, 20, 21, 22