-
Notifications
You must be signed in to change notification settings - Fork 17
/
abi.html
506 lines (434 loc) · 31.3 KB
/
abi.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
<!DOCTYPE html>
<html lang="en">
<head>
<!-- Basic Page Needs
================================================== -->
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<title>ABI</title>
<!-- Mobile Specific Metas
================================================== -->
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- Favicon -->
<link rel="shortcut icon" type="image/png" href="img/favicon.jpg"/>
<!-- CSS
================================================== -->
<!-- Bootstrap css file-->
<link href="css/bootstrap.min.css" rel="stylesheet">
<!-- Font awesome css file-->
<link href="css/font-awesome.min.css" rel="stylesheet">
<!-- Superslide css file-->
<link rel="stylesheet" href="css/superslides.css">
<!-- Slick slider css file -->
<link href="css/slick.css" rel="stylesheet">
<!-- smooth animate css file -->
<link rel="stylesheet" href="css/animate.css">
<!-- Elastic grid css file -->
<link rel="stylesheet" href="css/elastic_grid.css">
<!-- Circle counter cdn css file -->
<link rel='stylesheet prefetch' href='css/jquery.circliful.css'>
<!-- Default Theme css file -->
<link id="orginal" href="css/themes/eucalyptus-theme.css" rel="stylesheet">
<!-- Main structure css file -->
<link href="style.css" rel="stylesheet">
<!-- Google fonts -->
<link href='css/opensans.css' rel='stylesheet' type='text/css'>
<link href='css/varela.css' rel='stylesheet' type='text/css'>
<link href='css/montserrat.css' rel='stylesheet' type='text/css'>
<!-- HTML5 shim and Respond.js for IE8 support of HTML5 elements and media queries -->
<!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
<!--[if lt IE 9]>
<script src="https://oss.maxcdn.com/html5shiv/3.7.2/html5shiv.min.js"></script>
<script src="https://oss.maxcdn.com/respond/1.4.2/respond.min.js"></script>
<![endif]-->
</head>
<body>
<!-- BEGAIN PRELOADER -->
<div id="preloader">
<div id="status"> </div>
</div>
<!-- END PRELOADER -->
<!--=========== BEGIN HEADER SECTION ================-->
<header id="header">
<!-- BEGIN MENU -->
<div class="menu_area">
<nav class="navbar navbar-default navbar-fixed-top past-main" role="navigation">
<div class="container">
<div class="navbar-header">
<!-- FOR MOBILE VIEW COLLAPSED BUTTON -->
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#navbar" aria-expanded="false" aria-controls="navbar">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<!-- LOGO -->
<!-- TEXT BASED LOGO -->
<a class="navbar-brand" href="index.html">eXpOS<span>NITC</span></a>
</div>
<div id="navbar" class="navbar-collapse collapse">
<ul id="top-menu" class="nav navbar-nav navbar-right main_nav">
<li><a href="./index.html">Home</a></li>
<li><a href="./documentation.html" target="_blank">Documentation</a></li>
<li><a href="./Roadmap.html" target="_blank">Roadmap</a></li>
<li><a href="faq.html" target="_blank">FAQ</a></li>
<li><a href="About_us.html" target="_blank">About Us</a></li>
</ul>
</div>
</div>
</nav>
</div>
<!-- END MENU -->
</header>
<!--=========== End HEADER SECTION ================-->
<!--begin section-->
<section id="abi" style="text-align:justify">
<br>
<br>
<br>
<div class="container">
<div class="row">
<div class="col-lg-12 col-md-12">
<div class="about_area">
<!-- START ABOUT HEADING -->
<div class="heading">
<h2 >Application Binary Interface (ABI)</h2>
<br/>
<br/>
<p> An application binary interface (ABI) is the interface between a user program and the kernel.
</p>
<p>
The eXpOS ABI defines the following:
<ul style="list-style-type: square;line-height: 25px;margin-left: 80px;font-size: 16px;">
<li> The <b>machine model</b> - that is, the instruction set and the virtual memory address space to which an application/compiler generating executable file must generate target code for. This is very much architecture specific.
</li>
<br>
<li>
A logical division of the memory address space into <b>regions</b> - <i>text, stack, heap and library </i>and the low level (assembly/machine level) system call interface. This part is dependent on both the OS and the architecture.
</li>
<br>
<li>
The <b>file format</b> to be followed for executable files by the compiler (the XEXE executable file format). This part is generally OS specific and architecture independent. Compilers must generate executable files adhering to this format.
</li>
<br>
<li>A <b>low level system call interface</b> which gives the specification of the software interrupt instruction (trap) corresponding to each system call and the order in which arguments must be passed to the system call through the application program's stack.This part is architecture dependent.</li>
<br>
<li>The <b>low level runtime library interface :</b> The low level runtime library interface consists of user level routines which provide a layer of abstraction between the low level system call interface and the application program by providing a unified interface for all system calls, hiding low level interrupt details from the application. (Applications however, may choose to bypass this layer and directly invoke the low level system calls.) In addition to the system call interface, application level dynamic memory allocator and deallocator functions are also part of the eXpOS library. </li>
</ol></p>
</div>
<!-- START ABOUT CONTENT -->
<div class="about_content">
<div class="row">
<div class="about_featured">
<div class="panel-group" id="accordion">
<!-- START SINGLE FEATURED ITEM #1-->
<div class="panel panel-default ">
<div class="panel-heading">
<h4 class="panel-title">
<a data-toggle="collapse" href="#collapse1">
<span class="fa fa-check-square-o"></span>XSM User Level Instruction Set
</a>
</h4>
</div>
<div id="collapse1" class="panel-collapse collapse">
<div class="panel-body">
<p>
XSM Instruction set describes the target language in which a compiler must generate an executable file. Instructions are classified into privileged and unprivileged instructions. Since application programs run in the user mode, they can make use of only unprivileged instructions.</p>
<p>
You can read more about the XSM user level instruction set <a href="virtual_machine_spec.html" target="_blank">here</a>.
</p>
</div>
</div>
</div>
<!-- START SINGLE FEATURED ITEM #2 -->
<div class="panel panel-default ">
<div class="panel-heading">
<h4 class="panel-title">
<a data-toggle="collapse" href="#collapse2">
<span class="fa fa-check-square-o"></span>Virtual Address Space Model
</a>
</h4>
</div>
<div id="collapse2" class="panel-collapse collapse">
<div class="panel-body">
<p>
The (virtual) address space of any eXpOS process is logically divided into four parts namely <i>Shared Library, Heap, Code and Stack</i>.
<br>
</p>
<center><img src="img/process_model.png"></center>
<br>
<br>
<p><b>Shared library</b> can be shared by more than one executable file. The maximum size of this memory region is X_LSIZE.</p>
<p><code>Note :</code> eXpOS provides a library that provides a unified interface for system calls and dynamic memory allocation/deallocation routines. The library is pre-loaded into memory at the time of OS startup and is linked to the address space of a process when an executable program is loaded into the memory for execution if required (as determined by the Library flag in the <a href="http://exposnitc.github.io/abi.html#xexe" target="_blank">executable file</a>) . The eXpOS implementation for the XSM architecture discussed here sets X_LSIZE to 1024 words. Thus the shared library will be loaded into the region between
memory addresses 0 and 1023 in the address space of the process.</p>
<p><b>Heap</b> is the portion of the address space of a process reserved as the memory pool from which dynamic memory allocation
is done by the allocator routines in the shared library (for example, memory allocated via malloc in C). The maximum size of this memory region is X_HSIZE. Library functions access this portion of memory for dynamic memory allocation and deallocation. The eXpOS execution semantics specify that when a process executes the Fork system call, this region will be shared between the parent process and the child process. The eXpOS implementation for the XSM architecture discussed here sets X_HSIZE to 1024 words. Thus the heap region will be between memory addresses 1024 and 2047 in the address space of the process.</p>
<p><b>Code</b> contains the header and code part of the XEXE executable file, which is loaded by the eXpOS loader from the file system when the Exec system call is executed. The first eight words of the executable file contains the header. The rest of the code region contains the XSM instructions. The total size of code section cannot exceed X_CSIZE. The eXpOS implementation for the XSM architecture discussed here sets X_CSIZE to 2048 words. Hence, the code region will be between memory addressess 2048 and 4095 in the address space of the process.</p>
<p><b>Stack</b> is the space reserved for the runtime stack of the process. Parameters and local variables associated with functions in a program are allocated in the stack. In the XSM architecture, the stack grows upwards and the maximum stack size is X_SSIZE. Global variables are normally allocated in the stack as the executable file format does not support a separate <a href = "http://en.wikipedia.org/wiki/Data_segment" target="_blank">Data region</a>. The eXpOS implementation for the XSM architecture discussed here sets X_SIZE to 1024 words.Thus the stack will occupy the region between memory address 4096 and 5119 in the address space of the process.</p>
<p>A description of the user level address space provided by XSM is given <a href="virtual_machine_spec.html" target="_blank">here</a>.</p>
</div>
</div>
</div>
<!-- START SINGLE FEATURED ITEM #3 -->
<div id="xexe">
<div class="panel panel-default ">
<div class="panel-heading">
<h4 class="panel-title">
<a data-toggle="collapse" href="#collapse3">
<span class="fa fa-check-square-o"></span>XEXE Executable File Format
</a>
</h4>
</div>
<div id="collapse3" class="panel-collapse collapse">
<div class="panel-body">
<p> Executable files in eXpOS must be in the <a href="../os_spec-files/eXpFS.html#xexe" target="_blank">XEXE format</a> as eXpOS executes only files of such format.</p>
<p>An XEXE executable file in eXpOS consists of two parts:</p>
<ul style="text-indent: 5em;">
<li>1. Header</li>
<li>2. Code</li>
</ul>
<center><img src="img/exe_file.jpeg"></center>
<br>
<p>The maximum size of the file (including the header) is limited by the constant EXE_SIZE. The eXpOS implementation for the XSM architecture discussed here sets EXE_SIZE to 2048 words.</p>
<p>The first eight words of an executable file are reserved for the header which describes the features of file. The structure of the header is :</p>
<br>
<center> <img src="img/header.png"></center>
<br>
<p><b>XMAGIC</b> is a number indicating the type of executable file. All XEXE files will have magic number 0. For more on Magic Number, click <a href = "http://en.wikipedia.org/wiki/File_format#Magic_number" target="_blank">here</a>.</p>
<p><b>Entry point</b> contains the virtual address in memory of the first instruction to be executed (entry point) of the program after the OS loader has loaded it. During loading, the program counter must be initialized to this address. </p>
<p><b>Text Size</b>, <b>Data Size</b>, <b>Heap Size</b> and <b>Stack size</b> indicates the sizes of Text, Data, Heap and Stack regions to be allocated by the OS loader when the file is loaded for execution. </p>
<p><code>Note : </code>The present eXpOS virtual address space model requires that the data and stack must be in the same memory area and must be managed by the compiler / application program (this means that the program must contain the code to initialize the value of the stack pointer). The value of Data Size field is ignored. Moreover, the eXpOS loader (<a href = "http://exposnitc.github.io/os_spec-files/systemcallinterface.html#processsystemcalls" target="_blank">exec system call</a>) sets the size of text region to 2048 words and stack region to 1024 words in memory irrespective of the values present in the header.</p>
<p>If the <b>Runtime Library</b> must be included when the file is loaded, the Library Flag is set to 1 in the executable file. If this flag is not set then neither memory is allocated for the heap nor the library linked to the address space of the process by the eXpOS loader at execution time.</p>
<p>In summary, the eXpOS loader maps an executable file into its virtual address according to the following table : </p>
<table class="table table-bordered" style="text-align: center;">
<tr class="success">
<th style="text-align: center;">Region</th>
<th style="text-align: center;">Start Address</th>
<th style="text-align: center;">End Address</th>
</tr>
<tr>
<td>Library<sup style="color:red">*</sup></td>
<td>0</td>
<td>1023</td>
</tr>
<tr>
<td>Heap<sup style="color:red">*</sup></td>
<td>1024</td>
<td>2047</td>
</tr>
<tr>
<td>Code<sup style="color:green">**</sup></td>
<td>2048</td>
<td>4095</td>
</tr>
<tr>
<td>Stack<sup style="color:blue">†</sup></td>
<td>4096</td>
<td>5119</td>
</tr>
</table>
<p><span style="color:red">*</span> If Library Flag is set to 1 in the executable header.</p>
<p><span style="color:green">**</span> The eXpOS loader sets IP to the value specified in the program header.</p>
<p><span style="color:blue">†</span> The eXpOS loader does not gurentee that the values of SP and BP are initialised to the base address of the stack region.
Hence the executable program must contain code to initialise these registers.</p>
</div>
</div>
</div>
</div>
<!-- START SINGLE FEATURED ITEM #4 -->
<div class="panel panel-default ">
<div class="panel-heading">
<h4 class="panel-title">
<a data-toggle="collapse" href="#collapse4">
<span class="fa fa-check-square-o"></span>Low Level System Call Interface
</a>
</h4>
</div>
<div id="collapse4" class="panel-collapse collapse">
<div class="panel-body">
<p>The <b>Low level system call interface</b> describes the conventions to be followed by application programs that invoke <a href="os_spec-files/systemcallinterface.html" target="_blank" >eXpOS system calls</a> on the XSM architecture. The interface describes the software interrupt instruction (trap) corresponding to each system call and the calling conventions for passing arguments and extracting return values of the system call through the application program's stack. This part is architecture dependent.</p>
<p> <code>Note:</code> If a high level language like <a href="silcnitc.github.io" target="_blank">ExpL </a> is used for writing application programs, then the application
programs will be using the <a href="os_spec-files/dynamicmemoryroutines.html" target="_blank">high level library interface </a> for invoking system calls.
The ExpL compiler is responsible for generating assembly language code to translate the call to a
corresponding library call using the low level library interface. The ExpL library which is pre-loaded into
the system memory during eXpOS boot up contains assembly language code that redirects
the library call to the corresponding eXpOS system call using the low level system call interface described
here. If you write assembly language application programs as user programs, then you can use the low
level system call interface directly bye-passing the library.</p>
<h3>System Calls</h3>
<p>For an application program, there are two stages in executing a system call:</p>
<ul style="text-indent: 5em;">
<li>1. <b>Before the system call</b> : The calling application must set up the arguments in the (user) stack before executing the trap instruction. </li>
<pre>
<p><b>Important Note:</b> The calling application is supposed to save its register context into the stack before making a system call.
The system call is not expected to save the user context of the calling application. However, the <a href="https://silcnitc.github.io/run_data_structures/run-time-stack.html">ExpL calling convention</a>
(unfortunately) does not save the Base Pointer Register (BP) before the call. Hence, the OS implementation must be careful
to save the value of the register.
</pre>
<li>2. <b>After the system call</b> : The return value of the system call must be extracted from the stack. </li>
</ul>
<h3>Invoking a system call</h3>
<p>A user program invokes a system call by first pushing the system call number and then the arguments into the stack and then invoking the <b>INT</b> machine instruction corresponding to the system call. The eXpOS ABI stipulates that the number of arguments pushed into the stack is fixed at three. </p>
<div>
<p>
<pre style = "float:right;margin-left:10px;width:700px">
PUSH System_Call_Number // Push system call number
PUSH Argument_1 // Push argument 1 to the stack
PUSH Argument_2 // Push argument 2 to the stack
PUSH Argument_3 // Push argument 3 to the stack
<b>PUSH R0 // Push an empty space for RETURN VALUE</b>
INT number // Invoke the corresponding INT instruction.
// The number can be any number between 4 and 18
</pre>
A system call invocation using the high level application programmer's interface of a programming language like ExpL compiles to a set of machine instructions (see the instructions to the left). They are the stack operations that must be performed by the user program before the INT instruction is executed. </p>
</div>
<br/>
<div>
<p style="clear:right">
<img src="img/system_call_stack1.png" width="350px" height="350px" style="float:left;margin-right:5px">
<br/><br/>
The arguments must be pushed into the stack in such a way that the last argument comes on the top. An additional push instruction ('PUSH R0') is inserted to have an empty space in the stack for the return value. The system call implementation must ensure that the return value is stored in this space. The system call number is also pushed to the stack. The interrupt routine needs this value to identify the system call. The figure to the left shows the data stored in process stack just before an INT instruction. </p>
</div>
<div style="clear:left">
<p>
<img src="img/system_call_stack2.png" width="350px" height="350px" style="float:right;margin-left:5px">
<br/>The INT instruction in XSM will push the value of IP + 2 on to the stack. This is the address of the instruction immediately following the INT instruction in the user program. Each instruction is 2 words, hence IP is incremented by 2. Upon execution of the IRET instruction from the system call, execution resumes from this value of IP. The INT instruction changes mode from <b>User</b> mode to <b>Kernel</b> mode and passes control to the Interrupt Routine corresponding to the system call. The figure to the right shows the contents of the stack immediately after the execution of the INT instruction. </p>
</div>
<br/>
<h3 style="clear:right">After return from the system call</h3>
<p>The IRET instruction transfers control back to the user program to the instruction immediately following the INT instruction. The following machine instructions are present after the INT instruction in the ExpL compiled machine code given in the previous step. </p>
<div>
<p>
<pre style="float:left;margin-right:10px">
POP Ri // Pop and save the return value into some register Ri
POP Rj // Pop and discard argument 3
POP Rj // Pop and discard argument 2
POP Rj // Pop and discard argument 1
POP Rj // Pop and discard the system call number
// Now the stack is popped back to the state before call
</pre>
The machine code to the left pops the values from the stack. The system call number and arguments were inputs to the system call and hence they may be discarded now. The return value which is stored in the stack by the system call is fetched and used by the user program by popping out to some register. </p>
</div><br/>
<h3 style="clear:left">System calls and their translation</h3>
<p>
Associated with each system call, there is a system call number and interrupt routine number. The system call number is used to identify a system call. The interrupt routine number denotes the number of the interrupt routine which handles the system call. An interrupt routine may handle more than one system call.
</p>
<p> <b> Mapping of system calls to interrupt numbers and corresponding system call interface specification with details of arguments and return values of system calls are given in the <a href="./os_design-files/Sw_interface.html" target="_blank">eXpOS Low Level System Call Interface</a> Documentation.</b> </p>
<!--<p>For details of argument of the system calls, click <a href="os_spec-files/systemcallinterface.html" target="_blank">here</a>.</p>-->
</div>
</div>
</div>
<!--start-->
<div id="library">
<div class="panel panel-default ">
<div class="panel-heading">
<h4 class="panel-title">
<a data-toggle="collapse" href="#collapse5">
<span class="fa fa-check-square-o"></span>Low Level Runtime Library Interface
</a>
</h4>
</div>
<div id="collapse5" class="panel-collapse collapse">
<div class="panel-body">
<p>The eXpOS library consists of a collection of user level routines provided as part of the operating system. These routines are loaded to the memory during OS start up and can be linked to the address space of any user process by the OS loader (exec system call). The OS loader will link these routines to the shared library region of the address space <a href="" target="_blank">(see address space)</a> if the library flag in the header of the executable file being loaded is set to 1 <a href="" target="_blank">(see xexe)</a>.</p>
<p>
The library provides a <b>uniform interface</b> through which an application program can invoke system calls and dynamic memory allocation / deallocation routines by providing the function code and the arguments. The interface hides the details of the interrupt service routines corresponding to the <b>system calls</b> from the application, thereby making them architecture independent.
The library also provides user level routines for <b>dynamic memory management (allocation and de-allocation)</b> from the <i>heap region</i> of the application.</p>
<div>
<p>
<img src="./img/memory_management.png" width="350px" height="300px" style="float:right;margin-left:5px">
<br/>
<p>The library routine is linked to <b>virtual address 0</b> of the address space of a process by the OS loader and requires four arguments (function code and three arguments to the system call / memory management routine) to be passed through the stack. The routine invokes the corresponding low level system call / memory management routine and returns to the user program the return value of the system call / memory management routine through the stack. The figure to the side shows the contents of the stack immediately before a call to this library routine.</p>
<p>The invocation details for the system calls and the dynamic memory management routines using the library interface can be seen in the <a href = "../os_spec-files/dynamicmemoryroutines.html" target="_blank"><b>eXpOS High Level Library Interface</b></a> documentation.</p></p>
</div>
<h3 style="clear:right">Invoking a library module</h3>
<div >
<p>
<pre style = "float:left;margin-right:10px">
PUSH Function_Code // Push Function Code
PUSH Argument_1 // Push argument 1 to the stack
PUSH Argument_2 // Push argument 2 to the stack
PUSH Argument_3 // Push argument 3 to the stack
<b>PUSH R0 // Push an empty space for RETURN VALUE</b>
CALL 0 // Pass the control to virtual address 0.
// (eXpOS loader links the library to virtual address 0)
</pre>
A library module invocation using the high level application programmer's interface of a programming language like ExpL compiles to a set of machine instructions (see the instructions to the right). They are the stack operations that must be performed by the user program before the CALL instruction is executed.
</div>
<h3 style="clear:left">After return from the library module </h3>
The following machine instructions are present after the CALL instruction in the ExpL compiled machine code given in the previous step.
<div>
<p>
<pre style="float:left;margin-right:10px">
POP Ri // Pop and save the return value into some register Ri
POP Rj // Pop and discard argument 3
POP Rj // Pop and discard argument 2
POP Rj // Pop and discard argument 1
POP Rj // Pop and discard the function code
// Now the stack is popped back to the state before call
</pre>
The machine code to the left pops the values from the stack. The function code and arguments were inputs to the library module and hence they may be discarded now. The return value which is stored in the stack by the system call is fetched and used by the user program by popping out to some register. </p>
</div>
<p><code>Note:</code>If application programs are written in a high level language like
ExpL, the <a href="os_spec-files/dynamicmemoryroutines.html" target="_blank"> exposcall() function </a> will be
used to make system calls/invoke dynamic memory routines. The programmer does not have to worry about the library interface
specified here because the ExpL compiler will automatically generate assembly code that
translate the high level call to a low level call to the library using the above interface and retrieve return
values from the call. eXpOS pre-loads the library into the memory at boot time. The library re-directs system
call requests to the OS through the low level system call interface. Dynamic memory mangement functions are
implemented as part of the library itself.</p>
</div>
</div>
</div>
</div>
<!--end-->
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</section>
<!--end section-->
<!--=========== BEGIN FOOTER ================-->
<footer id="footer">
<div class="container">
<div class="row">
<a style="float: right" rel="license" href="http://creativecommons.org/licenses/by-nc/4.0/"><img alt="Creative Commons License" style="border-width:0" src="./img/creativecommons.png" /></a>
<div class="col-lg-6 col-md-6 col-sm-6">
<div class="footer_left">
<p><a href="http://www.nitc.ac.in/">National Institute of Technology, Calicut</a></p>
</div>
</div>
</div>
</div>
</footer>
<!--=========== END FOOTER ================-->
<!-- Javascript Files
================================================== -->
<!-- initialize jQuery Library -->
<script src="js/jquery.min.js"></script>
<!-- Google map -->
<script src="js/map_js.js"></script>
<script src="js/jquery.ui.map.js"></script>
<!-- For smooth animatin -->
<script src="js/wow.min.js"></script>
<!-- Bootstrap js -->
<script src="js/bootstrap.min.js"></script>
<!-- superslides slider -->
<script src="js/jquery.superslides.min.js" type="text/javascript"></script>
<!-- slick slider -->
<script src="js/slick.min.js"></script>
<!-- for circle counter -->
<script src='js/jquery.circliful.min.js'></script>
<!-- for portfolio filter gallery -->
<script src="js/modernizr.custom.js"></script>
<script src="js/classie.js"></script>
<script src="js/elastic_grid.min.js"></script>
<script src="js/portfolio_slider.js"></script>
<!-- Custom js-->
<script src="js/custom.js"></script>
</body>
</html>