HCMC University Of Technology

Faculty of Computer Science & Engineering

Course: Op era ting Systems
Assignment - Si mpl e Op er ating System
March 9, 2025
Goal:
The ob jective of this assignment is the simulation of ma jor comp onents in a simple op erating system,
for example, scheduler, synchronization, related op erations of physical memory and virtual memory.
Content:
In detail, student will practice with three ma jor mo dules: scheduler, synchronization, mechanism
of memory allo cation from virtual-to-physical memory.
‹
scheduler
‹
synchronization
‹
the op erations of mem-allo cation from virtual-to-physical
Besides, student will practice the design and implementation of Sim ple Op erating System programming
interface via system call.
Result:
After this assignment, student can understand partly the principle of a simple OS. They can
understand and draw the role of OS key mo dule s.
1
CONTENTS
CONTENTS
Contents
1 Intro duction
3
1.1 An overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2 Source Co de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3 Pro cesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4 How to Create a Pro cess? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.5 How to Run the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2 Implementation
7
2.1 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2 Memory Manag ement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1 The virtual memory mapping in each pro cess . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.2 The system's physical memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.3 Paging-based address translation scheme . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.4 Wrapping-up all paging-oriented implementations . . . . . . . . . . . . . . . . . . . . .
13
2.3 System Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.1 Des cription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.2 Adding a system call to Simple Op erating System . . . . . . . . . . . . . . . . . . . .
16
2.4 Put It All Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3 Submission
20
3.1 Source co de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3 Rep ort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.4 Grading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.5 Co de of ethics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
Page 2 of 21
1 INTRODUCTION
1 Intro duction
1.1 An overview
The assignment is ab out s imulating a simple op erating system to help student understand the fundame ntal
concepts of scheduling, synchronization and memory management. Figure 1 shows the overall architecture
of the
operating system
we are going to implement. Generally, the OS has to manage two
virtual
resources:
CPU(s) and RAM using two core comp onents:
‹
Scheduler (and Dispatcher): determines which pro cess is allowed to run on which CPU.
‹
Virtual memory: isolates the memory space of each pro cess from other. The physical RAM is shared
by multiple pro cesses but each pro cess do not know the existence of other. This is done by letting each
pro cess has its own virtual memory space and the Virtual memory engine will map and translate the
virtual addresses provided by pro cesses to corresp onding physical addresses.
Figure 1: The general view of key mo dules in this assignme nt
Through those mo dules, the OS allows multi-pro ce sses created by users to share and use the
virtual
com-
puting resources. Therefore, in this assignment, we fo cus on implementing scheduler/dispatcher and virtual
memory engine.
1.2 Source Co de
After downloading the source co de of the assignment in the
Resource
section on the p ortal platform and
extracting it, you will see the source co de organized as follows.
‹
Header
les
{
timer.h
: de
ne the timer for the whole system.
{
cpu.h
: de
ne functions used to implement the virtual CPU.
{
queue.h
: de
ne functions used to implement queue which holds the PCB of pro cesses.
{
sched.h
: de
ne functions used by the scheduler
{
mem.h
: de
ne unctions used by Virtual Memory Engine.
Page 3 of 21
1.3 Pro cesses 1 INTRODUCTION
{
loader.h
: (obsoleted) de
ne functions used by the loader which load the program from disk to
memory.
{
common.h
: de
ne structs and functions used everywhere in the OS.
{
bitopts.h
: de
ne op erations on bit data.
{
os-mm.h, mm.h
: de
ne the structure and basic data for Paging-based Memory Management.
{
os-cfg.h
: (Optional) de
ne the constants used to switch the so ftware con
guration.
‹
Source
les
{
timer.c
: implement the timer.
{
cpu.c
: implem ent the virtual CPU.
{
queue.c
: implement op erations on (priority) queues.
{
paging.c
: (obsolete d) use to check the functionality of Virtual Memory Engine.
{
os.c
: contain the main function to start the whole OS system .
{
loader.c
: impleme nt the loader
{
sched.c
: implement the scheduler
{
mem.c
: (obsolete d) implement the previous obsoleted version RAM and Virtual Memory.
{
mm.c, mm-vm.c, mm-memphy.c
: implement Paging-based Me mory Management
‹
Makefile
‹
input
the folder contains a se t of inputs used for veri
cation
‹
output
sample outputs of the system.
1.3 Pro cesses
1.3 Pro cesses 1 INTRODUCTION
‹
priority
: Pro ces s priority, the lower value the higher priority the pro cess has. This legacy priority
dep end on the pro cess 's prop erties and is
xed over execution session.
‹
co de
: Text segment of the pro cess (To simplify the simulation, we do not put the text segment in
RAM).
‹
regs
: Registe rs , each pro cess could use up to 10 registers numb ered from 0 to 9.
‹
pc
: The current p osition of program counter.
‹
page
table
: The translation from virtual addre sses to phys ic al addresses (obsoleted, do not use).
‹
bp
: Break p ointer, use to manage the heap segment.
‹
prio
: Priority on execution (if supp orted), and this value overwrites the default priority.
Similar to the real pro cess, each pro cess in this simulation is just a list of instructions executed by the CPU
one by one from the b eginning to the e nd (we do not imple ment jump instructions here). There are
ve
instructions a pro cess could p erform:
‹
CALC
: do some calculation using the CPU. This instruction do es not have argument.
Annotation of Memory region
: A sto rage area where we al locate the storage space for a variable,
this term is actual ly associated with an index of SYMBOL TABLE and usual ly supports human-readable
through variable name and a mapping mechanism. Unfortunately, this mapping is out-of-scope of this
Operating System course. It might belong another couse which explains how the compiler do its job and
map the label to its associated index. For simplicity, we refer here a memory region through its index
and it has a limit on the number of variables in each program/process.
‹
ALLOC
: Allo cate s ome chunk of bytes on the main me mory (RAM). Instruction's syntax:
alloc [size] [reg]
where
size
is the numb er of bytes the pro cess want to allo cate from RAM and
reg
is the numb er of
register which will save the address of the
rs t byte of the allo cated memory region. For example, the
instruction
allo c 124 7
will allo cate 124 bytes from the OS and the address of the
rst of those 124
bytes with b e stored at register #7.
‹
FREE
Free allo cated memory. Syntax:
free [reg]
where
reg
is the numb er of registers holding the address of the
1.4 How to Create a Pro cess ? 1 INTRODUCTION
The instruction writes
data
to the address which equal to the value of register
destination
+
o
set
.
For exam ple, assume that the value of register #1 is
0x123
then the instruction
write 10 1 20
will
write 10 to the memory at the address of
0x123 + 14
(14 is 20 in hexadecimal).
1.4 How to Create a Pro cess?
The content of each pro cess is actually a copy of a program stored on disk. Thus to create a pro ce ss, we
must
rst generate the program which describ es its content. A program is de
ned by a single
le with the
following format:
[priority] [N = number of instructions]
instruction 0
instruction 1
...
5
instruction N-1
where
priority
is the
default
priority of the pro ce ss created from this program. It needs to remind that
this system employs a dual priority mechanism.
The higher priority (with the smaller value) the pro cess has, the pro cess has higher chance to b e picked up
by the CPU from the queue (See section 2.1 for more detail).
N
is the numb er of instructions and each of
the next
N
lines(s) are instructions represented in the format mentioned in the previous section. You could
op en
les in
input/pro c
directory to see some s ample programs.
Dual pri ority mechanism
Please rememb er that this default value can b e overwrite by the
live
priority
during pro c ess execution c alling. For tackling the con
ict, when it has priority in pro cess loading (this inputt

le), it will overwrite and replace the default priority in pro cess description
le.
1.5 How to Run the Simulation
What we are going to do in this assignment is to implement a simple OS and simulate it over virtual hardware.
To start the simulation pro cess , we must create a description
le in
input
directory ab out the hardware and
the environme nt that we will simulate . The description
2 IMPLEMENTATION
2 Implementation
2.1 Scheduler
We
rst implement the scheduler. Figure 2 shows how the op erating system schedules pro cesses. The OS
is designed to work on multiple pro cessors. The OS uses multiple queue c alle d
ready
queue
to determine
which pro cess to b e executed when a CPU b ecomes available. Each queue is asso ciated with a
xed priority
value. The sche duler is designed base d on \multileve l queue" algorithm used in Linux kernel
1
.
According to Figure 2, the scheduler works as follows. For each new program, the loade r will create a new
pro cess and assign a new PCB to it. The loader then reads and copies the content of the program to the text
segment of the new pro cess (p ointed by
co de
p ointer in the PCB of the pro c ess - section 1.3). The PCB of
the pro cess is pushed to the asso ciated
ready
queue
having the same priority with the value
prio
of this
pro cess. Then, it waits for the CPU. The CPU runs pro cesses in round-robin s tyle. Each pro cess is allowed
to run in time s lic e. After that, the CPU is forc ed to enqueue the pro cess back to it asso ciated
priority
ready
queue
. The CPU then picks up another pro cess from
ready
queue
and continue running.
In this system, we implement the Multi-Level Queue (MLQ) p olicy. The system contains
MAX
PRIO
priority levels. Although the real system, i.e. Linux kernel, may group these levels into subsets, we keep
the design where each priority is held by one
ready
queue
for simplicity. We simplify the add
queue and
put
pro c
as putting the pro c to appropriated ready queue by priority matching. The main design is b elong
to the MLQ p olicy deployed by
get
pro c
to fetch a pro c and then dispatch CPU.
The desc ription of
MLQ p olicy
: the traverse d step of
ready
queue list
is a
xed formulated numb er
based on the priority, i.e. slot= (MAX
PRIO - prio), each queue have only
xed slot to use the CPU and
when it is used up, the system must change the resource to the other pro cess in the next queue and le ft the
remaining work for future slot even though it needs a c omple ted round of ready
queue.
2.2 Memory Management 2 IMPLEMENTATION
Figure 2: The op eration of scheduler in the assignment
2.2 Memory Management
2.2.1 The virtua l memory mapping in each pro cess
The virtual memory space is organized as a memory mapping for each pro cess PCB. From the pro cess p oint
of view, the virtual address includes multiple
vm
area
s (contiguously). In the re al world, each area can act
as co de, stack or heap segment. Therefore, the pro cess keeps in its
p cb
a p ointer of multiple contiguous
memory areas.
Memory Area
Each memory area ranges continuous ly in
[vm
start,vm
end]
. Although the space spans
the whole range, the actual usable area is limited by the top p ointing at
sbrk
. In the area b etween
vm
start
and
sbrk
, there are multiple regions captured by
struct vm
rg
struct
and free slots tracking by the list
vm
freerg
list
. Through this design, we make the design to p erform the actual allo cation of physical
memory only in the usable area, as in Figure 3.
Figure 3: The structure of vm area and region
Page 8 of 21
2.2 Memory Management 2 IMPLEMENTATION
//
From
include
/
os
-
mm
.
h
/
*
*
Memory
region
struct
*
/
5
struct
vm_rg_struct {
unsigned
long
rg_start;
unsigned
long
rg_end;
struct
vm_rg_struct
*
rg_next;
10
};
/
*
*
Memory
area
struct
*
/
15
struct
vm_area_struct {
unsigned
long
vm_id;
unsigned
long
vm_start;
unsigned
long
vm_end;
20
unsigned
long
sbrk;
/
*
*
Derived
field
*
2.2 Memory Management 2 IMPLEMENTATION
//
From
include
/
os
-
mm
.
h
/
*
*
Memory
mapping
struct
*
/
5
struct
mm_struct {
uint32_t
*
pgd;
struct
vm_area_struct
*
mmap;
10
/
*
Currently
we
support
a
fixed
number
of
symbol
*
/
struct
vm_rg_struct symrgtbl[PAGING_MAX_SYMTBL_SZ];
struct
pgn_t
*
fifo_pgn;
};
Memory mapping
is repre sented by
struct mm
struct
, which tracks all the me ntioned memory re-
gions in a separated contiguous memory area. In each memory mapping struct, many memory areas are
p ointed out by
struct vm
area
struct
*
mmap
list. An imp ortant
e ld is the
pgd
2.2 Memory Management 2 IMPLEMENTATION
CPU bus
PAGE size
PAGE bit
No pg entry
PAGE Entry sz
PAGE TBL
OFFSET bit
PGT mem
MEMPHY
fram bit
20
256B
12
■
4000
4byte
16KB
8
2MB
1MB
12
22
256B
14
■
16000
4byte
64KB
8
8MB
1MB
12
22
512B
13
■
8000
4byte
32KB
9
4MB
1MB
11
22
512B
13
■
8000
4byte
32KB
9
4MB
128kB
8
16
512B
8
256
4byte
1kB
9
128K
2.2 Memory Management 2 IMPLEMENTATION
2.2.3 Paging-based address translation scheme
The translation supp orts b oth segmentation and segmentation with paging. In this version, we develop
a single-level paging system that leverages one RAM device and one SWAP instance hardware. We have
implemented the capability to handle multiple memory segments, but we mainly fo cus on the
rst segment
of vm
area (vmaid = 0). The further versions will take into account a su■cient paging scheme for multiple
segments and the p otential overlap/non-overlap b etween segments.
Scheme CPU 32-bit
As in Figure 5
Figure 5: Page Table Entry Format.
This structure allows a userspace pro cess to determine which physical frame each virtual page is mapp ed to.
It contains a 32-bit value for each virtual page, containing the following data:
*
Bits 0-12 page frame number (FPN)
if
present
*
Bits 13-14 zero
if
present
*
Bits 15-27 user-defined numbering
if
present
*
Bits 0-4 swap type
if
swapped
5
*
Bits 5-25 swap offset
if
swapped
*
Bit 28 dirty
*
Bits 29 reserved
*
Bit 30 swapped
*
Bit 31 presented
Page table
The virtual space is isolated for each entity, so each
struct p cb
t
has its own table. To
work in paging-based m emory system, we need to up date this struct and the later section will dis cuss the
required mo di
cation. In all cases, each pro cess has a completely isolated and unique space,
N
pro cesses in
our setting result in
N
page tables. Each page must have all entries for the entire CPU address space. For
each entry, the paging numb er may have an asso ciated frame in MEMRAM or MEMSWP, or might have
null value. The functionality of each data bit of the page table entry is illustrated in Figure
??
. In our
chosen highlighted setting in Table 1 we have 16.000-entry table each table cost 64 KB storage space.
In Section 2.2.1, the pro ce ss can access the virtual memory space in a contiguous manner of the vm area
structure. The remaining work deals with the mapping b etween page and frame to provide the contiguous
2.2 Memory Management 2 IMPLEMENTATION
Figure 6: Memory system m o dules
help moving the contents of physical frame b etween the MEMRAM and MEMSWAP. The swapping is a
mechanism that copies the frame's content from outside to main memory (RAM). Swapping out, in reverse,
attempts to move the content of a frame in MEMRAM to MEMSWAP. In a typical context, s wapping helps
free up frame of RAM since the size of SWAP device is usually large enough.
Basic memory op erations in pa ging-based system
‹
ALLOC: user call the library functions in libmem and in most cases, it
ts into data segment area.
If there is no suitable space, we need to expand the memory space by lift up the barrier set by s brk.
Since it have never b een touched, it may needs to leverage some MMU systemcalls to obtains physical
frames and then map them using Page Table Entry.
‹
FREE: user call the library functions in libme m to revoke the storage space asso ciated with the given
region id. Since we cannot reclaim the taken physical frame which might c aus e memory holes, we
just ke ep the collected storage space in a free list for future allo c request, all are emb edded in libmem
library.
‹
READ/WRITE requires to get the page to b e presented in the main memory. The most resource
consuming step is the page swapping. If the page is in the MEMSWAP device, it needs to b e brought
back to MEMRAM device (swapping in) and if there is a lack of space, we need to give back some
pages to MEMSWAP device (swapping out) to make more ro oms.
To p erform these op erations, it needs a collab oration among the
mm
's mo dules as illustrated in Figure 6.
Question
What are the advantages and disadvantages of segmentation with paging?
2.2.4 Wrapping-up all paging-oriented implementations
Intro duction to the con
guration control using constant de
nition:
2
to make less e
ort on
dealing with the interference among feature-oriented program mo dules, we apply the same approach as
2
This section is applied mainly to paging memory management. If you are still working in Scheduler section you should keep
the default setting and avoi d touching to o many changes to these values
Page 13 of 21
2.2 Memory Management 2 IMPLEMENTATION
in the develop er community by isolating each feature through a system of con
guration. Leveraging this
mechanism, we can maintain various subsystems s eparately, all existing in a single ve rs ion of co de. We can
control the con
guration used in our simulation program in the
include/os-cfg.h

le
//
From
include
/
os
-
cfg
.
h
#
define
MLQ_SCHED 1
#
define
MAX_PRIO 140
5
#
define
MM_PAGING
#
define
MM_FIXED_MEMSZ
An example of
MM
PAGING
setting:
With this new mo dules of mem ory paging, we got a derivation
of PCB struct added some additional memory management
elds and they are wrapp ed by a constant
de
nition. If we want to use the
MM
PAGING
mo dule then we enable the asso ciated
#define
con
g line in
include/os-cfg.h
//
From
include
/
common
.
h
struct
pcb_t {
...
#
ifdef
MM_PAGING
5
struct
mm_struct
2.3 System Call 2 IMPLEMENTATION
2.3 System Call
2.3.1 Description
The system call is the fundamental inte rfac e b e tween an application and the Simple Op erating System kernel.
System calls and library wrapp er function
System calls are generally not invoked directly, but rather
via wrapp er func tion in libstd (or p erhaps some other libraries). For details on the direct invo cation of a
system c all, see Figure 7.
The libstd wrapp er functions are usually quite thin, doing little work other than copying arguments to the
appropriate registers b efore invoking the system c all. However, the wrapp er function some tim es do es some
additional works b e fore invoking the system call.
System call list
The list of syste m calls that are available in the Simple Op erating System is shown in
the follow ing listing:
SystemcallKernelNotes
================================================
listsyscall3.0
memmap 3 . 0
killall3.0Alpha,wasavailable
upto3.1
System call manual page
1.
listsyscall
list all system call
Name
listsyscall
=
listallsystemcall
Sysnopsis
SYSCALL 0
Description
listsyscalldisplaythelist
of
allsystemcalls.
2.
memmap
map memory
Name
memmap
=
map m e m o r y
Sysnopsis
SYSCALL 1 7 SYSMEM
OP REG
ARG2 REG
ARG3
Description
memmap s u p p o r t s v a r i o u s o p e r a t i o n s o n m e m o r y m a p p i n g . T h e o p e r a t i o n s a r e
decribed
in
libmem.h,including:
+ SYSMEM
MAP
OP
with
dummy h a n d l e r
+ SYSMEM
INC
OP
with
inc
vma
limit()handler
2.3 System Call 2 IMPLEMENTATION
Name
killall
=
killprocessesbyname
Sysnopsis
SYSCALL 1 0 1 REGIONID
Description
killallsendsasignalstoallprocessesrunningthespecifedcommands.
T h e command o r p r o g r a m n a m e a r e s p e c i f i e d b y m e m o r y r e g i o n
associated
with
REGIONID . I f n o s i g n a l n a m e i s s p e c i f i e d , t h e
terminatesignalissent.
k i l l a l l i s a n INCOMPLETED t a s k w h i c h a c q u i r e s t h e r e m a i n i n g
implementationbystudenttoterminatetheexecution
of
all
processeswhoseprogramnamematchthestringstored
in
REGIONID .
Figure 7: The handling of us er application invoking a system call
Question
What is the mechanism to pass a complex argument to a system call using the limited registers?
2.3.2 Adding a system call to Simple Op erating System
In this guide, you will learn how to add a simple system call to the Simple Op erating System.
Creation
1.
Create a C
le for your system call in
src/sys
xxxhandler.c
//
From
src
/
sys_xxxhandler
.
c
#
include
"
common
.
h
"
#
include
"
syscall
.
h
"
#
include
"
stdio
.
h
"
Page 16 of 21
2.3 System Call 2 IMPLEMENTATION
int
sys
xxxhandler(
struct
pcb
t
*
caller,
struct
sc
regs
*
reg)
f
/
*
TODO
:
implement
syscall
job
*
/
printf(
"
The
first
system
call
parameter
%
d
n
n
"
,regs
=
>
a1);
return
0;
g
2.
Create a Make
le entry for your s ys tem call with a unique indexing, i.e. 440
#
From
Makefile
SYSCALL
OBJ +=
$
(addprefix
$
( OBJ ) / , s y s
xxxhandler.o)
3.
Add your system call to the kernel's system call table
#
From
src
/
syscall
2.4 Put It All Together 2 IMPLEMENTATION
Congratulations! You have successfully added a system call to the Simple Op erating System!
Question
What happ ens if the syscall job implementation takes to o long execution tim e?
2.4 Put It All Together
Finally, we combine scheduler and memory management to form a complete OS. Figure 8 shows the complete
organization of the OS mem ory management. The last task to do is synchronization. Since the OS runs
on multiple pro cessors, it is p ossible that share resources could b e concurrently accessed by more than one
pro cess at a tim e. Your job in this section is to
nd share resource and use lo ck mechanism to protect them.
Figure 8: The op eration related to virtual memory in the assignment
Check your work by
rst com piling the whole source co de
makeall
Page 18 of 21
2.4 Put It All Together 2 IMPLEMENTATION
and com pare your output with those in
output
. Rememb er that as we are running in multi-pro cesses en-
vironment, there may b e more than one correc t result. All the outputs are used as samples and are not the
restricted res ults . Your results only need to b e explainable and b e comparable with
theoretical framework
and do es not need to match the output sample.
Question:
What happ ens if the synchronization is not handled in your Simple OS? Illustrate the problem
of yo ur simple OS (ass ignme nt outputs) by example if you have any.
Page 19 of 21
3 SUBMISSION
3 Submission
3.1 Source co de
Requirement:
you have to co de the system call followed by the co ding style. Reference:
https://www.gnu.org/prep/standards/html
no de/Writing-C.htm l
3.2 Requirements
Scheduler
implement the scheduler that employs MLQ p olicy as describ ed in Section 2.1.
Memory Management
implement the paging subsystem.
Systemcall
implement the remaining task of the system call killall. The program name fetching has b een
provided, students need to
gure out the matching pro cesses and terminate their execution (as a common
killall command usage).
Questionnaire
student ne ed to answe r all questions in the assignment description.
3.3 Rep ort
Write a rep ort that answers questions in the implementation section and interpre ts the results of running
tests in each section:
‹
Scheduling: draw Gantt diagram describing how pro cess es are executed by the CPU.
‹
Memory: show the status of the memory allo c ation in heap and data segments.
‹
SystemCall: show the inter-mo dule interactions among memory storing pro ces s nam e, OS pro cess
control, and scheduling queue management.
‹
Overall: students should
nd their own way to interpret the results of simulation.
After you
nish the assignment, move your rep ort to source c o de directory and compress the entire directory
into a single
le name d
assignment
STUDENTID.zip
and submit to LMS.
3.4 Grading
You must complete this assignment in groups of 4 or 5 students. The overall grade for your group is
determined by the following comp onents:
‹
Demonstration (7 p oints)
{
Scheduling: 3 p oints
{
MMU Paging: 2 p oints
{
Systemcall: 2 p oints
‹
Rep ort (3 p oints)
3.5 Co de of ethics
Faculty sta
memb ers involved in co de development reserved all the copyright of the pro ject source co de.
Source Co de Li cense Grant
: Author(s) hereby grant(s) to Licensee p ersonal p ermission to use and mo dify
the Licensed Source Co de for the sole purp ose of studying while attending the course CO2018 at HCMUT.
Page 20 of 21
Revision History 3 SUBMISSION
Revision History
Revision Date Author(s) Descri ption
1.0 01.2019 p dnguyen,
Minh Thanh CHUNG
,
Hai Duc NGUYEN
Created CPU, scheduling, memory
1.1 09.2022 p dnguyen Add Multilevel Queue (MLQ) CPU Sche duling
2.0 03.2023 p dnguyen Initialize MM Paging Framework
2.1 10.2023 p dnguyen Add Page Re plac ement
2.2 03.2024 p dnguyen Add CPU Translation Lo okaside Bu
er (TLB)
2.3 10.2024 p dnguyen Add heap segment
3.0 03.2025 p dnguyen Add systemcall
Page 21 of 21