Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Task context and execution memory in vxworks

287 views
Skip to first unread message

s.subbarayan

unread,
Nov 16, 2004, 11:18:54 PM11/16/04
to
Dear all,
I would like to clarify with you all whether my understanding with
respect to tasks and its context is correct:
Heres what I inferred:

1)When we say execution memory,it means a part of RAM.

2)Generally RAM is configured into multiple segments where our
executing task occupies a particular segment of memory.

3)Other then the segment required for execution from RAM,rest of the
space in RAM will be occupied by the non executing tasks.

4)If what I stated in (3) is wrong,the non executing tasks and their
info will be in ROM and each time when the kernel schedules a task to
run ,it will be promoted from ROM to RAM for execution.

5)Execution memory related configurations like start address and size
of memory allocated for execution is configured via config.h and
syslib.c file.Is this correct?

I was searching for the above info in the manual,but was not able to
find.So can someone throw some light on whether my understanding is
correct regarding memory for nonexecuting tasks and executing
tasks.Typically all the above inferences boils to basic doubt of

6)When a task executes,where physically will be the other non
executing tasks in my application stay ?

Expecting to learn from all your replys and advanced thanks for the
same,
Regards,
s.subbarayan

joe durusau

unread,
Nov 17, 2004, 8:07:20 AM11/17/04
to

"s.subbarayan" wrote:

> Dear all,
> I would like to clarify with you all whether my understanding with
> respect to tasks and its context is correct:
> Heres what I inferred:
>
> 1)When we say execution memory,it means a part of RAM.

It depends. You can build vxWorks to reside in ROM or ram,
your choice.

>
> 2)Generally RAM is configured into multiple segments where our
> executing task occupies a particular segment of memory.
>

No. At least for 5.4 and earlier, the whole shebang of all executable
code is in a single text segment. Data is in the data segment, bss is
all the un-initialized memory for varieables that do not have intiial
values.

>
> 3)Other then the segment required for execution from RAM,rest of the
> space in RAM will be occupied by the non executing tasks.
>

More or less, see above.

>
> 4)If what I stated in (3) is wrong,the non executing tasks and their
> info will be in ROM and each time when the kernel schedules a task to
> run ,it will be promoted from ROM to RAM for execution.
>

No. Everything is in RAM if you compiled and linked with that option.
the text segment might all be in ROM, if you set things up that way.

>
> 5)Execution memory related configurations like start address and size
> of memory allocated for execution is configured via config.h and
> syslib.c file.Is this correct?
>

The same constants are in the Makefile.

>
> I was searching for the above info in the manual,but was not able to
> find.So can someone throw some light on whether my understanding is
> correct regarding memory for nonexecuting tasks and executing
> tasks.Typically all the above inferences boils to basic doubt of
>

See chapter 8 of the Programmer's guide, which has all the details.

>
> 6)When a task executes,where physically will be the other non
> executing tasks in my application stay ?
>

Tasks do not occupy memory. Programs do. A task is a thread,
at least up to 5.4

>
> Expecting to learn from all your replys and advanced thanks for the
> same,
> Regards,
> s.subbarayan

Read the programmer's guide, you will find this kind of info there.

Speaking only for myself,

Joe Durusau


rsripathi

unread,
Nov 17, 2004, 8:39:01 PM11/17/04
to
s_subb...@rediffmail.com (s.subbarayan) wrote in message news:<c396173e.04111...@posting.google.com>...

> Dear all,
> I would like to clarify with you all whether my understanding with
> respect to tasks and its context is correct:
> Heres what I inferred:
>
> 1)When we say execution memory,it means a part of RAM.

Not necessarily. You can run it out of ROM.

>
> 2)Generally RAM is configured into multiple segments where our
> executing task occupies a particular segment of memory.

Post 5.4 ,yes.


>
> 3)Other then the segment required for execution from RAM,rest of the
> space in RAM will be occupied by the non executing tasks.
>

Not all the RAM space will be taken up by the text segment.

> 4)If what I stated in (3) is wrong,the non executing tasks and their
> info will be in ROM and each time when the kernel schedules a task to
> run ,it will be promoted from ROM to RAM for execution.
>

It again depends on if your code runs out of ROM or RAM. But there
will not be any promotion from ROM to RAM.

> 5)Execution memory related configurations like start address and size
> of memory allocated for execution is configured via config.h and
> syslib.c file.Is this correct?
>
> I was searching for the above info in the manual,but was not able to
> find.So can someone throw some light on whether my understanding is
> correct regarding memory for nonexecuting tasks and executing
> tasks.Typically all the above inferences boils to basic doubt of
>
> 6)When a task executes,where physically will be the other non
> executing tasks in my application stay ?

The others remain in suspended state and in RAM / ROM. When a task
executes it is really some function that exceeutes in a certain
context aka task.

David Hamel

unread,
Nov 18, 2004, 2:52:17 AM11/18/04
to
s.subbarayan wrote:
> 1)When we say execution memory,it means a part of RAM.

Usually, although there are exceptions.

> 2)Generally RAM is configured into multiple segments where our
> executing task occupies a particular segment of memory.

This is splitting hairs and is not precise enough for vxWorks. A memory
segment means something specific in DOS or UNIX (and especially means
something on an x86 processor). In vxWorks, except for object module
files (including the kernel file called vxWorks), a segment of memory
is general, and a vxWorks task occupies memory, but it isn't useful
to refer to it as a segment. A vxWorks task has a portion of contiguous
memory used for a stack and has a portion of memory devoted to storing
special information (the Task Control Block, or TCB which is adjacent to
the stack memory. A vxWork task executes instructions and uses data that
may or may not reside all over the place.

> 3)Other then the segment required for execution from RAM,rest of the
> space in RAM will be occupied by the non executing tasks.

True, but coincidental. The truth of this statement yields no conclusions.

> 4)If what I stated in (3) is wrong,the non executing tasks and their
> info will be in ROM and each time when the kernel schedules a task to
> run ,it will be promoted from ROM to RAM for execution.

False, in most if not all uncustomized cases.

> 5)Execution memory related configurations like start address and size
> of memory allocated for execution is configured via config.h and
> syslib.c file.Is this correct?

What you state here in "5" is only true for the initial "thread" of
execution. After the initial thread, gets started, all other qualities
that a task has are progammable up for you to decide what they are.
If you don't decide, then there exist reasonable default qualities.

> 6)When a task executes,where physically will be the other non
> executing tasks in my application stay ?

Where they have always been unless you allow them to no longer exist or
explicitly take actions to move them.

Summary: A task has 3 important qualities. A stack, a thread of
execution, and a set of processor register values (state variables that
are stored in a structure called a TCB when not actually stored in the
processor's registers). When one task blocks/stops/halts....and another
task begins/starts/runs, the only thing that changes in the system is
the processor's actual registers are set to the running tasks's register
values. Nothing is demoted to ROM and nothing is promoted to RAM and
nothing is moved around in memory during a context switch except for
small number things required to identify a task's context.

s.subbarayan

unread,
Nov 18, 2004, 11:27:42 PM11/18/04
to
Dear all,
Thanks for all your replys.
I do understand that each task will not be given individual memory to
execute.I think theres something wrong in the way I framed my query.My
actual doubt is

1)What exactly you mean by execution address space?Suppose take for a
scenario,where there are two tasks A and B and suppose now taskA is
executing in the execution address space,where will be rest of
application located physically?

2)I understand that it can be configured to execute in RAM or ROM,but
the question is will the whole or entire range of memory in RAM or ROM
be considered as execution address space?Or jus a part of it is
considered as execution space?If suppose entire range is considered as
execution space,where will I have memory for rest of my application?

Sorry for disturbing you all again,advanced thanks for all your
replys.

Regards,
s.subbarayan


David Hamel <da...@csua.berkeley.edu> wrote in message news:<419C550D...@csua.berkeley.edu>...

David Hamel

unread,
Nov 19, 2004, 12:46:27 AM11/19/04
to
s.subbarayan wrote:
> Dear all,
> Thanks for all your replys.
> I do understand that each task will not be given individual memory to
> execute.I think theres something wrong in the way I framed my query.My
> actual doubt is
>
> 1)What exactly you mean by execution address space?Suppose take for a
> scenario,where there are two tasks A and B and suppose now taskA is
> executing in the execution address space,where will be rest of

> application located physically?

The "execution address space" is definitely a nebulous or intangible
idea unless we talk about a particular processor. In any case, vxWorks
5.x uses a flat address space without virtual memory. So all addresses
which map to physical RAM is conceivably "execution address space".
Whether a portion of memory is execution address space or not depends
on how you use it.

Suppose you have two tasks, 1 and 2. Each task has the same entry point
, the arguments to taskSpawn. priorities are the same 100, 9000 bytes
of stack each), and for simplicity I'll write out the entire application.
Only the task name identifier is different.

int globalvar;
void entryFunction()
{
int localvar;
static int persisentvar = 0;
while(1)
{
printf("taskId: %i\n", taskIdSelf());
taskDelay(60);
}
}
....
taskSpawn("task1", 100, 0, 9000, entryFunction, 0,0,0,0,0,0,0,0,0);
taskSpawn("task2", 100, 0, 9000, entryFunction, 0,0,0,0,0,0,0,0,0);

Physically, each task will have a separate stack occupying 9000 bytes of
RAM allocated from within taskSpawn with something like malloc().
The 9000 bytes that taskSpawn() allocates for a task's stack comes from
the system's heap. Yep.. the heap of one thing becomes the stack of another.

entryFunction() resides in the same physical memory location for both
task1 and task2, regardless of which task is actually executing.

globalvar and persisentvar also reside in the _same_ physical memory
location for both task1 and task2; If task1 modifies either of these
variables, then task2 will see the modification. This is why skilled
reentrant programming is necessary on vxWorks.

localvar resides in a _different_ physical memory location in task1 than
from task2. In fact, it is either at the bottom 9000 bytes of stack or
the top 9000 bytes of stack depending on which processor architecture
one uses.


> 2)I understand that it can be configured to execute in RAM or ROM,but
> the question is will the whole or entire range of memory in RAM or ROM
> be considered as execution address space?Or jus a part of it is
> considered as execution space?If suppose entire range is considered as
> execution space,where will I have memory for rest of my application?

Depends. The definition of "execution space" is mostly arbitrary. That
which you do not use for one purpose is available for another. You
should stop worring about this type of question and come back again
after more experience and you'll realize the circular logic of your
question.

> Sorry for disturbing you all again,advanced thanks for all your
> replys.

Not at all, we (and especially me) like answering solid tangible questions.

Joe Durusau

unread,
Nov 21, 2004, 1:33:29 PM11/21/04
to

s.subbarayan wrote:
> Dear all,
> Thanks for all your replys.
> I do understand that each task will not be given individual memory to
> execute.I think theres something wrong in the way I framed my query.My
> actual doubt is
>
> 1)What exactly you mean by execution address space?Suppose take for a
> scenario,where there are two tasks A and B and suppose now taskA is
> executing in the execution address space,where will be rest of
> application located physically?
>

What version of VxWorks, and where did you get the term "Execution
Address Space"?? In 5.4 and earlier, the term has no meaning.
Everything is static, located in RAM or ROM, depending on how you made
the image, and is there forever and forever, never being moved,
relocated, or meddled with in any way.

> 2)I understand that it can be configured to execute in RAM or ROM,but
> the question is will the whole or entire range of memory in RAM or ROM
> be considered as execution address space?Or jus a part of it is
> considered as execution space?If suppose entire range is considered as
> execution space,where will I have memory for rest of my application?
>

If execution in ROM is selected, the text segment only is in ROM.
bss and data are in RAM, as they have to be modifiable. Again,
I have never heard the term "execution Address Space in VxWorks
documentation. If you are getting this term from some other OS,
please delete it from your vocabulary. If from VxWorks documentation,
please specify the OS version and the source of the term.

Speaking only for myself,

Joe Durusau

0 new messages