--->all the descriptions, in this document

are based on the text book by Charles Crowley

, chapters 2/3/4/5/6
--->this is the text book, for embedded students

- in this context of discussions, we will be understanding

how the OS services use low-level processor services and
provide the final set of services

- so, high-level services are connected to low-level

services

- how the system-space modules/code execute ???

- how some of the system-space modules/code

are inter-linked ???

- in the case of a system call API, it invokes

a machine instruction and this leads to following
set of actions :
- some of the current hw context is saved,
in hw (+ in the sw, system call handler ??)

- in addition, there is an implicit processor

mode switch, from user-privilege to
system-privilege - this is triggered, by
the "machine instruction" - some cpu
registers are affected
-->refer to your text book, see above
--->refer to lecture slides

- as part of processing this "trap instruction",

an execption jump is effective, which loads
the address
of the corresponding system call handler -
this system call handler needs to implemented,
as per OS design ??? OS core component,
system call interface layer typically
provides this system call handler plus
a system call table and other supporting
frame-work

- in a typical OS implementation, the system call

handler must access appropriate system call
table, for accessing the corresponding
system service routine and complete the
service --->refer to the previous para.

- once the system call handler completes,

it is expected to return, "using an interrupt
return technique of the hw architecture" -
-->this is a form HAL - based on hw architecture
-->HAL of OS provides low-level code, for
kernel/components of the OS
--->we will come across HAL, in the context of
embedded/RTOS
 - once this is done, the saved hw context of
the current process is extracted and
loaded into the processor, which will
resume the process, in the user-space
to continue ?? after the above processing,
the processor mode is again switched
back to user-mode/less privileged mode
--->refer to chapter 5/ slides of your text book
--->continue the following discussions
- connect the above details, with system
call API processing and related service
routines

- in the following discussions, we will be referring

to "chapter 5 of Charles Crowley" :
- we will be understanding an implementation of
system call handler, timer routine,
scheduler, and their interlinking
- as per this reference and GPOS systems,
the first process is created, by the
kernel/CORE of the OS - this first process
is the one,which loads/launches other
processes, based on the OS configuration
and set-up - as part of this job, it will
invoke one or more process management system
call APIs and create new processes
- as part of this set-up, any other process is
also created, using one or more system call
APIs of the process managememt
- as a developer, once the basic OS set-up
is done, as above, one or more
processes are created for applications/
multitasking, using system call APIs

- following discussion will involve

process system call API, system call
handler, system call service routines,
scheduler, and their interlinking
--->in this context, process system call API
is used to create a new process, as per
application's requirements
--->similarly, OS provides other system call
APIs, like thread creation system call
APIs

- as part of the next discussion, we will start,

with
system call handler and system service routines ??
- let us assume, that an existing process
invokes a system call API, for a new
process creation - most of the comments
below are same, for other system call APIs,
with some difference - meaning, the basic
principles remain the same, but details
will change ??
--->basic working of system call APIs are similar,
but their services will differ
 - in this textbook/context/scenario, after a system
call execution, scheduler is always
invoked - scheduler will take appropriate
action to dispatch and continue the
current process or schedule/dispatch
another process, as per the state of
the processes and scheduling parameters
- in this textbook/context/scenario, scheduler
is invoked sub-optimally
--->the above design is sub-optimal
--->in a typical embedded sw platform(non-OS), we
will be using only one stack memory region
--->however, for a more sophisticated processor/
sw stack design, we may use multiple stack
memory regions, 2 or more
--->in a typical OS platform, each process /thread
may be allocated 2 stack memory regions, one
stack memory region, for user-space and another
stack memory region, for system-space - this is a
typical OS design

- there is an explicit saving of hw context

in the "pd or related objects of a process"
- there is an explicit switching of processor
stack pointer - the stack pointer will be
forced to point to a system stack
- hw context is saved, in the pd or stack,
for resuming this process, after the
completion of the system call execution
-->in most designs, hw context is saved, in a
stack memory region dedicated to the process/
thread
- in a typical OS platform, let us assume, that
there is a "dedicated stack memory region
for user-space execution" and
"another dedicated stack
memory region for the system space execution"
-->this is based on hw architecture/embedded
and
managed by the OS
-->many modern hw architectures/embedded
support
multiple stack memory regions,
for OS design
- every system call API passes parameters to
the system - "one such parameter is system
call no." - there are other parameters passed
to
the system call service routine
--->in this context/architecture,
stack pointer register is r30

- as part of system call handler execution,

there is a stack switch and r30 is
updated to system stack top - the
basics of stack pointer remain the
same
--->why is the r30 /stack pointer updated, during
 a system call handler ?? r30 is updated to use
system-space stack memory region of the
process, since the execution is , in system-space

- based on the system call no. of a system call,

the system call
handler will invoke appropriate service
routine of the kernel /components
-->in this context, r8 is the
cpu register which is holding
the system call no.
- in this case, let us assume, that it is a
process creation system call API and
corresponding
service routine is invoked :
--->we will ignore some of the parameters
passed to the service routine

- as part of the process creation service

routine, following are done:
- allocate a free pd
- initialize pd's fields
--->some of these are purely OS
specific fields
--->whereas, there are certain
fields related to hw context
initialization

- allocate physical memory and initialize

the related details, in the pd
- "initialize initial hw context"
fields of the pd, like the
program counter, stack pointer,
control register - this control
register will contain value,for
setting the processor mode, for
user-mode
- the above "hw context will be used",
"when this process will be scheduled
and dispatched, in the future, for
the first time"
- once a process/pd is successfully
set-up, the pd is added to Rq/ready-state

- in this context,
once the process creation
service routine completes,
it will return to the system call
handler

- once the above processing is done, the

control of the system call handler is
passed to "scheduler of the system" -
this is a sub-optimal invokation of
scheduler, in this design - in the
future designs, this will be different
--->in many modern OS platforms, more efficient
designs are used, including RTOS platforms
- in this context, let us assume that
 the "scheduler is divided into 2
parts - one is the policy part, which
is "time-slicing/RR" - in chapter 5/
ch6 of Crowley, the scheduling policy
is assumed to be time-slicing/RR

- the second part of the scheduler will

be the actual dispatcher - it will
"load the low-level hw context of the
process/pd selected by the scheduler"
into the processor

- the policy part will check the

current time-slice field of the
process and if it is non-zero,
continue the current process, after
the system call API - in the current
context of system call execution,
the time-slice field of the current
process/pd will be non-zero

- however, if the time-slice field is

expired, the current process will be
preempted and another process will
be selected - this time-slice field
will be set to 0, when there is
a hw timer interrupt and there is
a time-slice expiry -- refer to
hw timer interrupt handler section/
slide/code

- manipulation of the time-slice field

of processes is done, by timer ISR,
whenever there are timer int events

- as part of the dispatching part of

the scheduler,
for a selected process/pd, the hw context
contents are loaded into the processor and
"at the end of the scheduler, a typical
return from interrupt action" is taken

- in the common scenario, the current process

will be resumed, after a process creation
system call API - scheduler will select
the same process and dispatch, using
the saved hw context of the current process ??i
---->typically, hw context will be saved, in a stack
memory region of the process, but in this
chapter 5 of the text book, the hw context is
saved, in the process descriptor of the process
----->in the chapter 6/of the text book, many of these
design details will differ and we will understand
other scenarios
-->in the common case, when a process
invokes a process creation system
call API, hw context is saved and
the same hw context will be reloaded
by the scheduler/dispatcher
 --->assuming a new process is created
with a new program/application instance,
following will
be the actions taken, for its
scheduling/dispatching
- the newly created process will be

runnable/ready and
will be dispatched, in the future, when it
is eligible ?? we will assume that this
new process is set-up and its pd is
ready, but its actual scheduling/dispatching
will be, in the future
------->in these scenarios, let us assume, that
the system is an uniprocessor

- let us assume that a process/newly created is scheduled

and dispatched to the processor - it has been
assigned a time-quantum, because of time-slicing
- it is executing/running on the processor
- as per this system/design, the timer int is generated
, after every "one time-quantum/100msecs(or
another value)"
--->hw timer is programmed to generate
periodic hw ints. every 100msecs
-->OS is setting up the hw timer
--->in this text-book, time-quantum
is 100msecs, but may change, in
different OS platforms
-based on the above set-up, when "a timer int.
event is generated,timer ISR will be processed"
- as part of the timer ISR processing,
time-slice field of the current process
/pd will be manipulated
- the time-slice field of the
current process/pd is set to 0-
this means, time-slice of the
current process is expired
- as per this design, scheduler is
invoked, at the end of the timer
ISR - this is a sub-optimal design,
but basics are the same
- as per the time-slicing/policy,
if the time-slice
field is set to 0, the current process
will be preempted and another
ready process
will be selected and dispatched
-->refer to the scheduler's selection/
scheduling code

- the model used, in chapter 5 is a minimal

/sub-optimal model, due to the
following reasons -
in this minimal model several features
are unsupported - in chapter 6, the
missing/additional features will be added to
 the design and implemented :
- hw interrupts are enabled, in user-mode
/user-space
- hw interrupts are disabled, in system-mode
/system-space, during system call execution

- due to these limitations, user-space

preemptions are allowed,
not system-space
preemptions ?? this is another aspect
of the design
-->some of these limitations will
not trouble certain applications,
but trouble a few applications
--->in chapter 5, hw interrupts are
masked, during system-space
execution - so,there no possibility
of interruption, during system call
execution, as well as preemption
, as hw interrupts are disabled
- in this model, hw context is saved, in the
pd(not, in the stack of the process)
and "there is room, for only one
instance of hw context" - if we need to save
2 or more instances of hw context, it is
disallowed, as per the design - these
are limitations
- there are multiple user-space stacks, for
supporting multiple processes, but there
is a single systems-space stack,
as per design - this is a serious
limitation
- since there is a single system-space
stack, blocking operations are not
supported, in system calls / system call
APIs ?? - as per this design, core
OS service cannot support blocking
operations, but only non-blocking
operations - this is a serious
limitation

- let us understand user-space preemption

and system-space preemption ??/

- let us see certain diagrams ??

- if a process is executing, in the user-space
and there is an event(possibly, an int.
event), if there is a preemption and
rescheduling, such a preemption is
known as user-space preemption
- if a process is executing a system call,
in the system-space,if there is an
interrupt event, which leads to
preemption and
rescheduling,such a preemption is known
as kernel preemption/kernel-space
preemption
- different operating system platforms
have different supports, for
 user-space and system-space
preemptions - we will understand more,
in the upcoming discussions
-->GPOS platforms
-->RTOS platforms
--->there are configuration
settings, for enabling
/disabling preemptions

- in these discussions, hw int. priorities

will be treated higher than OS scheduling
priorities - these rules are true, for
any OS platform or other sw platforms -
embedded platform rules are always
respected
--->if a process with a real-time
policy /real-time priority is
executing/running, if a hw int
event is generated, the hw int
event will be serviced immediately
- high priority process is
immediately interrupted

- whenver a process is interrupted or

preempted or blocked, the current hw
context of the process/processor will
be saved, "in the pd or related objects",
such that the saved hw context will be
used to resume the process, from the
correct point of execution - this set-up
ensures, that a preempted process will
be resumed correctly, in its code/data
, without any run-time corruption -
this will ensure that multitasking will
take are saving hw contexts of processes
and restoring hw contexts of processes ??
- in addition, pd and its nested objects
will ensure, that other sw contexts are
also saved and resumed, during preemptions
- such actions are commonly taken, in
system call handlers, ISRs, and scheduler's
dispatcher ?? refer to Crowley, for low-level
understanding of the details

- in any OS/EOS/rtoS, several system call APIs

/system APIs are supported - in addition,
as part of the system call API, implicitly,
system call nos. are assigned and hard-coded
- these system call nos. are passed to the system,
when the corresponding system call API is
invoked - internally, based on these numbers,
system call HANDLER will invoke corresponding
system service routines ???

- in all these scenarios,OS CORE code will be

resident, in the system, but may not execute,
until events are triggered - once events are
triggered, these handlers/ISRs are invoked
and processed - OS core code is passively
 resident most of the life-time of the system
- in chapter 5 of this reference,
pds are maintained in a table,
not a list - other designs may
maintain a list
- there is a pd table/list, in the system -
this table/list will contain free/used
pds - when a process is created, a free
pd is allocated to the specific process
and initialized - this will be associated
with the process, until its termination
and clean-up - once terminated/cleaned-up,
pd will be freed to the system table/
list

- since hw interrupts are disabled, in system-

space and there is only one hw context
save area, in the pd, in this model,
user-space preemption is supported,
but not system-space preemption
--->this may be a serious limitation,
for certain applications

- "first, understand chapter 5 model of

charles crowley" - next, move on to
"chapter 6 model of Charles Crowley,
where we have a more sophisticated
and realistic model" - many
limitations are removed

- let us summarize the key features of

chapter 6 model of Crowley:
- there is one private user-space
stack per process
- there is one private/dedicated
kernel/system
stack per process
- in this model, pd is not used to
save hw contexts, but kernel
stack of the pd/process is used -
so, there is more flexibility
to save multiple hw contexts,
as needed - this feature is
more realistic
- this model allows multiple hw context
save areas, in the kernel stack of
a specific process - pd
no longer manages hw context save areas,
but the kernel stack does - kernel stack
is managed, by the pd
--->hw interrupts are enabled, in user-space,
in a typical OS platform
- hw interrupts are enabled, during
system call execution, as per this design
- hw interrupts are disabled, during
ISRs - "meaning,nested ISRs are disallowed
, in this design"
- in other OS platforms, there may be
support, for nested ISRs, if the design
 is acceptable
- in addition, "hw interrupts will be masked,
during OS critical code sections of the
kernel ??? "executing scheduler code -
executing IO code, for a shared
hw interface" ??"
--->in the context of OS platforms, hw interrupts/
ISRs must be managed, as per OS rules - developers
must follow OS rules
--->in the case of RTOS, some of these rules are
more relaxed, for applications/developers
- based on the above set-up, in this model,
system-space preemption is supported and
allowed - since hw interrupts are
enabled, in system-space, system-space
preemptions are allowed
- in this model, blocking of processes, in
system call APIs/system callS is allowed
--->in most OS platforms, system call
APIs block the current process/
thread,due to resource /other
events - this is a common design

- to understand chapter 6 OS model/design

of Crowley,
we will discuss certain scenarios:
--->we will discuss a few scenarios to describe the
design and its features
- let us understand all these features, using
certain scenarios :
- in this model, let us assume,that a process
is invoking a system call API and it
completes its processing and resumes the
same process
- as part the system call processing
/system call handler, hw context 1
is saved, in sa1 of the kernel stack of
the current process/pd -
after the system call processing/
service routine processing,
the system call handler invokes the scheduler
- the scheduler will resume the same
process, using sa1 stored, in the
kernel stack of this process
- hw context of sa1 is loaded into
the processor and the process resumes,
in the user-space
- in another scenario,let us assume, that
there is a system-space preemption ?? let us
understand the behaviour of this model, in
this scenario
- the current process Pi invokes a
system call API, which will lead
to execution of system call
handler and syscall service routine
- system call handler will save sa1,
in the kernel stack of the current
process/pd
- this sa1 will be used to resume
 the execution of this process,
in the user-space
- while the system call/service
routine is executing,
in the system-space, if there is an
int. event , another hw context/2
is saved, in sa2 of the kernel
stack of the current process/pd- this
sa2 is needed to resume the kernel
space execution/service routine
of the the current process
- in addition, if these events lead to
a preemption, scheduler will be invoked
, after the ISR and
it will preempt the current process
and schedule/dispatch another process,
in the Rq
- as part of scheduling and dispatching the
selected,next process/pd,
save areas of the
kernel stackj of next process, Pj
are used - it is not shown, in the
big-picture

- sometime, in the future, the preempted

process will become eligible, for
scheduling and dispatching - in this
case, scheduler is invoked, due to
certain event,like interrupt or
system call API - when the scheduler
is invoked, the scheduler
will select the processi and the dispatcher
will use sa2 to dispatch/resume the
processi/pdi - the processi will resume its
system space service routine and
complete it

- after completing the service routine,

system call handler completes and
control is passed to the scheduler
, again

- the scheduler will continue the same

processi, using sa1 and dispatching it
,again - at the end of this, the preempted
processi will resume and continue its
user-space
execution - as per the above
discussions, the hw context
areas are saved,in respective
kernel stacks and reloaded
and the processi is resumed
as expected

i - let us look, at another scenario, for

"blocking and unblocking, using
system call APIs" of IPC mechanisms -
for this discussion,
we will be using a message queue IPC
 mechanism :
- two processes cannot interact with
each other, without support of an
IPC mechanism, in OS platforms
- one such IPC mechanism is a
message queue, in the core of
the OS - it has
a system object, known as message
queue object - there are different
forms of message queues -
in this context, we will be seeing
a GPOS form - in the case of embedded
/RTOS, similar message queues
are present, but design will be
different, but basic principles
are the same
--->refer to lecture big-pictures
- "processes can access a message queue
object using system call APIs"
- typically, one process will send
messages to the mq object and the
message will be copied and maintained
, in a queue/list of buffers -
mq object maintains
a set of buffers/messages, in a queue
list managed, in the mq object
- a process can receive messages,from
the queue , using system call API -
if a process invokes a receive
message system call API,
if there is no message, the receiving
process will be blocked, in the system
call - the receive message system
call/service routine will change the
state of the process/pd to blocked and
add the pd to the wq of the
message queue object - let us assume,
that a process is blocked, in the
wq of a message queue and a sending
process sends a
message, using a system call API,
a message will be copied, as well as
any blocked processes will be unblocked
- a typical mq object also maintains a waitqueue
and a receiver process can be blocked, if
there is no message, in the queue
--->following discussions connect high-level system
call APIs to low-level service routines /operations
-->refer to big-pictures
--->following immediate discussion describes
receive message system call API and it s
blocking operation
--->part of the system call handler,
hw context1/sa1 is saved, in the
kernel stacki of the current processi/
pdi
--->next, the receive system call's
service routine is invoked/
processed
 --->if there is a message present,
in the message queue, copy the
message to user-space and
return back from system call
processing
- as per the implementation details,
if there are no messages, in the
message queue and a receive message
system call API is invoked,the
current process will blocked, using
switchprocess() system routine -
as part of this system routine,
the current processi/pdi is blocked,
in the wq of the message queue,
hw context 2/sa2 is saved, in the kernel
stacki of processi and scheduler is invoked -
as part of scheduler, it will select and
dispatch another eligible process/pd
from the Rq
--->such blocking operations trigger scheduler -
these are not preemption points, but still
trigger scheduler

-->in the near future, what happens, when another

processj sends a message to the above
message queue
- if another process sends a message,using
send message system call API ???
- the new message will be copied into
the message queue of the mq object
- in addition,the blocked receiver process
is unblocked
- once unblocked, this processi/pdi will be
added to Rq - this is a separate
event and scheduler invokation is
another event - meaning, if a processi/
pdi is unblocked by a system call APIi,
the pdi is added to Rq, but scheduling
will happen, based on the scheduling
policy/parameters - for instance,
if the unblocked processi/pdi is
of very high importance, after the
unblocking operation, scheduler will
be immediately triggered and there will
be a form of preemption
- or,some time in the future, this unblocked
processi will be scheduled and dispatched,if
it of lower importance
---->refer to big pictures
- once scheduled, the unblocked process
will be resumed, using sa2 of the
kernel stack of the process
- based on the sa2, the process will complete
its receive part and a message will be copied
- once the system service routine is
completed, the system call handler is also
completed and control is passed to scheduler
- now, scheduler will use sa1 to again
restore the hw context and resume the processi,
 in user-space
- in short, we have completed a cycle of blocking,
unblocking, scheduling/dispatching, processing,
and restoring the user-space execution of
of a process
- based on the above discussions,
can we conclude the following :
- are int. events allowed, in a
system call execution ??
-->in this model, YES
- are int. events allowed, in
an ISR ??
-->in this model, NO-
no nested ISRs
- can we save multiple hw contexts,
in kernel stack ???
--->in this model, YES
- is system-space preemption allowed
, in this model ??? YES, due to
the above reasons
- is blocking inside a system call
execution allowed, in this model ??
-->YES, due to the above
reasons
- based on all the above details, we will
be following chapter 6 model of
charles crowley, for many of our
discussions ?? YES, but
there can be optimal designs,
based on this model

--->following discussion is about

"memory management characteristics
of processes, in this design/in the
text book"

--->only memory management---->

--->following memory management model is part
of initial process management,but actual
discussions will be, in the later documents
--->same applies to the text-book, in chapter 5/6
--->refer memory management slides, in all.pdf,
under bigpictures directory
- in this hw memory-model, let assume, that "logical
address-space" is used, based on the
"logical addresses of the processor" -
this "processor architecture supports
logical addresses"
and in addition, supports a "simple logical
to physical address translation,
using a base register and a bound register, in
the processor " - these are the translation
control registers, in the cpu
--->since the processor supports logical/virtual
addresses, most OS platforms also support
logical addresses/virtual addresses
--->during memory management, we will understand
the benefits of logical addresses/address-space/
 virtual addresses/virtual address-space
- we need to connect the details and
a few lecture diagrams, for
complete clarity
- refer to lecture diagrams ??
--->a typical processor will support MMU unit or
MPU unit, as per the architecture -
MPU is specific to certain embedded processor
architectures
- in these diagrams, the "processor/MMU
maintain several registers and
control registers" - some of these
are "logical address registers" -
these "logical address registers/
control registers are initialized",
when a process/pd
is scheduled/dispatched - this is
done, as part of dispatching, using
hw context of the process/pd - these
addresses are provided by the pd -
further,
these logical address registers
are incremented and logical addresses
are generated and used on behalf
of the process
- the base /length (or bound) control
registers
of the processor are used to translate
the logical addresses of the process
that is loaded/scheduled/dispatched
- we will see the actual translation
details of the hw - finally, it
helps process/application - this
hw model supports logical address-space
for a process,as well as translation of
these logical addresses to physical
addresses
-->every process is assigned a range
of logical addresses, as per the
requirements of its active
application
--->refer to big pictures
--->in this model, passive program/application
is assigned logical addresses/addres-space
--->when a passive program/application is loaded
into main-memory, a copy of is loaded, with
an extended address-space and managed by
a process/pd
--->in addition, when the active instance is
loaded and executing, logical addresses will
be translated to physical addresses, using
processor's control registers
--->more details are discussed below

- let us summarize the hw and sw memory models

, in this system :
- the processor supports logical addresses
and logical address registers
- the processor supports a set if control
 registers - base register and
length register - for address translation
- the programs and their processes are assigned
logical address-space and logical addresses -
process uses logical addresses
and "OS is managing logical address space and
logical addresses", for the processes/pds

- during process creation, the "hw context is

initialized" , with "logical addresses"
- in addition, "base and bound registers" values
are initialized, when the process is created/
set-up
- when this process is scheduled and dispatched,
the "logical addresses and base/bound values"
are loaded, from the "pd into the processor
registers"
--->refer to chapter 5/slides/process creation service
routine
--->refer to chapter5/slides/scheduler's dispatcher
routine and timer ISR
- during run-time, when this process is
running/executing, based on the
initialization of registers
and their values, translation is done, from
logical to physical addresses
--->see the translation details
discussed below

- a active program's contents are typically loaded

into a physical memory block defined, by
base register and bound register, for this
process - this is based on the physical
memory block allocated to a process/pd,
when it is created

- the above set-up is done, for each process,

separately - meaning, whenever a process
is scheduled and dispatched, the corresponding
logical addresses/base register value/
bound register value will be loaded into
the processor - each pd maintains the
hw context details of the respective
process

- visualize several active processes, their

respective process address-spaces and their
corresponding physical memory mappings/memory
blocks, in the system ???

- refer to all the above diagrams

and connect all the details
- connect the process address-spaces
to allocated physical memory blocks of
processes, due to processor/MMU
translations
- also connect with operating system
and pds/how pds maintain process
related resources, like address-space
 and hw contexts

- at the end of the above discussions, we can

visualize the following set-up, based on
the design(s) :
- there are several active applications
and their independent logical
address-spaces/a set of logical
addresses - it is a logical
resource, so easy to allocate
and assign
- next, these active applications'
contents(code/data) are
actually loaded into the "physical
memory blocks of main memory/RAM"
- however, we cannot directly
access the phyical memory blocks
of processes - we need to access
logical addresses of the processes,
which will be translated to
corresponding physical addresses -
this set-up is real and we cannot
bypass it, in a typical OS platform
--->we will provide more justifications, for
logical addresses/address-spaces, in the
complex hw models, but the basic translations
remain the same
- however, there is a mapping/
translation between
the logical address-spaces of the
processes to actual physical
memory blocks, using hw /MMU and
their registers - this happens during
run-time
- "as a developer/application,logical
address-space(s) are visible" and
the "other side of physical address
/memory blocks are hidden", but
seen as resources allocated to
the processes - "logical address spaces
are also logical resources,
but visible to
the applications/processes"
-->Pi -->lai--->bai(lai<li)
lai+bai--->pai
---> this is repeated for
several logical addresses
of Pi
-->Pi+1-->lai--->bai'(lai'<li')
lai+bai'-->pai'
---> this is repeated for
several logical addresses
of Pi+1
-->Pi+2-->lai--->bai''(lai''<'li'')
lai+bai'' -->pai''
---> this is repeated for
several logical addresses
of Pi+2
.........
 - in this above set-up, let us assume the
"logical address-space scope is the same",
for "each process", "as per the hw model" -
which means, "every process can be provided
an independent/duplicate range of
logical address-
space", based on the hw support, by the
"OS memory management" - what
does this mean ?? what are the benefits
of logical address-space(s), for
processes ??
- the "OS memory management design"
is such that the "developers/applications
are exposed to logical/virtual
addresses/address-spaces and
virtual memory"(virtual address-space
/VMM are part of complex OS
memory models)
- the "OS memory management design"
is such that "application developers
//applications" are not exposed to
physical memory /address-space/addresses
--->some of these mechanisms are more favourable, for
GPOS type of platforms, but certain embedded
systems may still use these, for practical
reasons - we will see certain details, in the
context of RTOS
-->OS manages hw resources and
exposes logical/virtual resources
to applications - there are
practical benefits

- however, OS memory design enables

the "developer/application to see
the physical memory blocks, as
resources" - there is no direct
access, but indirect access
-->still, indirect access to
physical memory blocks
are provided, as part of
resource managment

- based on the same logical address space

scope, each process is
assigned its own private/duplicate
logical address-space
/set of logical addresses
-->the logical address-width can be
32-bits or 48-bits, as per the
processor architecture
-->based on the logical address-width
max. scope of logical address-space is
defined
-->because it is logical address/address-
space, every process can be given
a generous duplicate/priave
copy of the same scope,
as per requirements of the
 processes/active applications
-->however, each logical address-space
of every process must be mapped
/translated to different physical
memory blocks/addresses
-->such a set-up has several practical
benefits, for processes/active
applications, in GPOS , as well
as RTOS
- what do you understand, based on the above
set-up ???
- based on the above set-up, when a
process is scheduled and dispatched,
the corresponding "logical addresses
of the process are mapped/translated
to corresponding physical memory
blocks/adddresses", using appropriate
"translation registers" of the process
- "bi / li/lai of pi"

note : we will come across "more complex

hw memory models and sw memory models,
during memory management"
note : in all the these cases, basic principles
are the same
------------> end of memory management