> On Tue, 29 Sep 2009 16:33:21 +0000, Grant Edwards wrote:
>> On 2009-09-29, brOS <bogdanrosandic@gmail.com> wrote:
>>
>>> Variables j,i,k,q and m will be saved in R15,R14,R13,R12
>>> (these registers are pushed on stack before entering ISR) and
>>> one more register, say R10 which is not pushed on stack. Now
>>> my question is how come R10(and other registers) is not pushed
>>> on stack before entering ISR????
>>
>> Because the ISR didn't _use_ R10. The compiler knows what
>> registers are used by an ISR, so it only saves the ones that
>> are used. When switching contexts you've got to save _all_
>> the registers.
>
> Maybe it's just me recollecting teaching myself 8086 assembly
> in the 80's but I think it was the case back then to save all
> the registers.
Of course. You have to save the entire context regardless of
the CPU type.
--
Grant Edwards grante Yow! Hmmm ... an arrogant
at bouquet with a subtle
visi.com suggestion of POLYVINYL
CHLORIDE ...
Reply by Paul Keinanen●October 12, 20092009-10-12
On Tue, 29 Sep 2009 08:48:56 -0500, "brOS" <bogdanrosandic@gmail.com>
wrote:
>What do you people think which is better, saving context on stack or in
>task's TCB???
For orthogonal instruction sets in which autoincrement and
autodecrement addressing modes can be used with at least one other
register than the stack pointer, it really does not matter very much.
However, if short push/pop operations can only be used with the stack
pointer and the reference to the TCB would require longer/slower
instructions (or if the TCB is in a different address space requiring
extra code for the access), saving on the current stack would be
preferable.
Also saving to the TCB might usually require a longer period when the
interrupts must be disabled.
Saving on the stack the interrupts could be enabled during the context
save phase and later on the context restore phase, but the interrupts
need only be disabled while storing the current stack pointer to the
current TCB and loading the new stack pointer from the selected new
TCB.
Paul
Reply by jebblue●October 12, 20092009-10-12
On Tue, 29 Sep 2009 16:33:21 +0000, Grant Edwards wrote:
> On 2009-09-29, brOS <bogdanrosandic@gmail.com> wrote:
>
>> Variables j,i,k,q and m will be saved in R15,R14,R13,R12 (these
>> registers are pushed on stack before entering ISR) and one more
>> register, say R10 which is not pushed on stack. Now my question is how
>> come R10(and other registers) is not pushed on stack before entering
>> ISR????
>
> Because the ISR didn't _use_ R10. The compiler knows what registers are
> used by an ISR, so it only saves the ones that are used. When switching
> contexts you've got to save _all_ the registers.
>
Maybe it's just me recollecting teaching myself 8086 assembly in the
80's but I think it was the case back then to save all the registers.
--
// This is my opinion.
Reply by Grant Edwards●October 3, 20092009-10-03
On 2009-10-03, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>Now, I would like to measure its performance and to be sure
>>that everything is fine by now because I would like to add more
>>features later. So any help considering this subject is
>>welcome. Is there some book that you could recommend, or online
>>benchmark.....????
>
> I don't know of a "universal test."
Sounds like a different version of the halting problem to me. ;)
There are RTOSes that are certfied by various agencies, but I
think that involves a lot of code review/inspection and
detailed test-cases. I don't so how a universal test would be
possible.
--
Grant
Reply by Jon Kirwan●October 3, 20092009-10-03
On Sat, 03 Oct 2009 11:47:29 -0500, "brOS" <bogdanrosandic@gmail.com>
wrote:
>>On Tue, 29 Sep 2009 22:48:29 +0200, David Brown
>><david.brown@hesbynett.removethisbit.no> wrote:
>>
>>>Jon Kirwan wrote:
>>>> On Tue, 29 Sep 2009 18:11:52 +0000 (UTC), Grant Edwards
>>>> <invalid@invalid.invalid> wrote:
>>>>
>>>>> On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>>>>> On Tue, 29 Sep 2009 17:23:33 +0000 (UTC), Grant Edwards
>>>>>> <invalid@invalid.invalid> wrote:
>>>>>>
>>>>>>> On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>>>>>>
>>>>>>>>> Does that mean that any RTOS has limitation about task routine
>>>>>>>>> complexity ,
>>>>>>>> Not for the most part. There are exceptions, such as cases that
>>>>>>>> hardware may impose from time to time. But not in the way you
>>>>>>>> asked... for loops are always, in my experience, easy to handle.
>>>>>>> One thing to watch out for on the'430 is the hardware
>>>>>>> multiplier. Its state isn't part of the normal register set,
>>>>>>> and HW multiply operations are not atomic. If you use the HW
>>>>>>> multiplier in more than one task, you've either got to
>>>>>>> save/restore it's state as well or you have to make sure that
>>>>>>> interrupts are disabled around HW multiply operations.
>>>>>> Did I fail to introduce that idea in my post? I seem to recall
>>>>>> including some words there.
>>>>> I probably missed it.
>>>>
>>>> I probably wrote too much.
>>>
>>>Have you ever thought about setting up a website (perhaps a wiki), and
>>>just posting pointers when answering posts like these? Sometime in this
>
>>>group you post an amazing amount of information - it seems a shame to
>>>think this work will disappear (no one actually follows the rule of
>>>searching a newsgroup archives before posting a question). Posts like
>>>that are also so long that many people will skip them, thinking they'll
>>>read them later when they have more time. If you had this stuff on a
>>>wiki, I know I would read them more often.
>>>
>>>mvh.,
>>>
>>>David
>>
>>Hehe. Okay. I admit I do have a site I can use where I can install
>>server software. I'll see about setting something up. You are
>>probably right, though it does take some effort to set things up,
>>think about what may be desired, and get them seeded well enough with
>>starting material. But it is something I should do. Kick me more. ;)
>>
>>jon
>>
>
>I'd like to thank you all who helped me with this. It means a lot,
>especially because I'm new in this.
>But I would like to ask you something else.
>Is there some kind of universal test which can verify proper work and
>measure RTOS performance?
>Let's say I have finished my small RTOS for MSP430. Of course it's very
>simple. It's just have kernel API for task creation(which cannot be called
>from task routine, at least for now) and task suspension. Basically it just
> saves and switches context, and it has two possible scheduling algorithms
>to choose from (both preemptive). Now, I would like to measure its
>performance and to be sure that everything is fine by now because I would
>like to add more features later.
>So any help considering this subject is welcome. Is there some book that
>you could recommend, or online benchmark.....????
>
>Thanks in advance !!!
I don't know of a "universal test." And I'm not sure how I'd attempt
to design one. Do you know what you'd expect in one?
As far as the MSP430 goes, which is actually a fairly simple case, you
might look at specifying the fixed part of the data footprint together
with the per-process and per-semaphore (and per-whatnot) data required
and specify a formula there. That would allow folks to get a close
figure on what it would cost them in terms of scarce ram on the MSP.
You might also provide a similar figure for the flash requirements.
Add to that the timer interrupt cpu time requirements and the typical
case in terms of % of cpu used by the timer event, context switch
times, and latency requirements from the sleep queue to running a
highest priority process; such things might be nice to know. Features
supported are important to know, too.
I have built my own O/S that runs on the MSP430 and some other
processors. The principal feature is compile-time configurability.
When a feature is not enabled or selected, the code and data
associated with it is eliminated from the resulting object code. It's
a prime goal that adding features to the source code may not incur a
cost if an end-user doesn't require them and deselects them in the
compile-time configurations. A minimally compiled system does NOT
have a real-time clock, quantums, semaphores, messages, thread
priorities, sleeping threads, and so on -- but it does support all of
those features if desired at compile-time. In the minimal case,
though, it's just a simple, cooperative switcher, able to keep the
stacks separated (and that's about it.) It supports Harvard and von
Newmann architectures and the kinds of memory systems that common
microcontrollers provide (such as read/write and read-only for either
code or data.) It has an explicit design requirement to isolate those
portions of the thread/process data structures which can be arranged
into read-only memory from those portions which require read/write
access during operation in order to reduce ram requriements further.
(Threads can be defined at compile-time, not only at run-time.) I
could provide figures to compare with, if I knew what you were wanting
to compare against.
You and I are neither the first nor the last to do this kind of stuff,
but I think it is important that you try your hand at it. I wish
everyone did. It's an extremely good learning experience for any c
programmer to go through to improve their own understanding of both
the c language and exactly what an operating system actually does.
Please keep up the work!
Jon
Reply by brOS●October 3, 20092009-10-03
>On Tue, 29 Sep 2009 22:48:29 +0200, David Brown
><david.brown@hesbynett.removethisbit.no> wrote:
>
>>Jon Kirwan wrote:
>>> On Tue, 29 Sep 2009 18:11:52 +0000 (UTC), Grant Edwards
>>> <invalid@invalid.invalid> wrote:
>>>
>>>> On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>>>> On Tue, 29 Sep 2009 17:23:33 +0000 (UTC), Grant Edwards
>>>>> <invalid@invalid.invalid> wrote:
>>>>>
>>>>>> On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>>>>>
>>>>>>>> Does that mean that any RTOS has limitation about task routine
>>>>>>>> complexity ,
>>>>>>> Not for the most part. There are exceptions, such as cases that
>>>>>>> hardware may impose from time to time. But not in the way you
>>>>>>> asked... for loops are always, in my experience, easy to handle.
>>>>>> One thing to watch out for on the'430 is the hardware
>>>>>> multiplier. Its state isn't part of the normal register set,
>>>>>> and HW multiply operations are not atomic. If you use the HW
>>>>>> multiplier in more than one task, you've either got to
>>>>>> save/restore it's state as well or you have to make sure that
>>>>>> interrupts are disabled around HW multiply operations.
>>>>> Did I fail to introduce that idea in my post? I seem to recall
>>>>> including some words there.
>>>> I probably missed it.
>>>
>>> I probably wrote too much.
>>
>>Have you ever thought about setting up a website (perhaps a wiki), and
>>just posting pointers when answering posts like these? Sometime in this
>>group you post an amazing amount of information - it seems a shame to
>>think this work will disappear (no one actually follows the rule of
>>searching a newsgroup archives before posting a question). Posts like
>>that are also so long that many people will skip them, thinking they'll
>>read them later when they have more time. If you had this stuff on a
>>wiki, I know I would read them more often.
>>
>>mvh.,
>>
>>David
>
>Hehe. Okay. I admit I do have a site I can use where I can install
>server software. I'll see about setting something up. You are
>probably right, though it does take some effort to set things up,
>think about what may be desired, and get them seeded well enough with
>starting material. But it is something I should do. Kick me more. ;)
>
>jon
>
I'd like to thank you all who helped me with this. It means a lot,
especially because I'm new in this.
But I would like to ask you something else.
Is there some kind of universal test which can verify proper work and
measure RTOS performance?
Let's say I have finished my small RTOS for MSP430. Of course it's very
simple. It's just have kernel API for task creation(which cannot be called
from task routine, at least for now) and task suspension. Basically it just
saves and switches context, and it has two possible scheduling algorithms
to choose from (both preemptive). Now, I would like to measure its
performance and to be sure that everything is fine by now because I would
like to add more features later.
So any help considering this subject is welcome. Is there some book that
you could recommend, or online benchmark.....????
Thanks in advance !!!
---------------------------------------
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com
Reply by Jon Kirwan●September 29, 20092009-09-29
On Tue, 29 Sep 2009 22:48:29 +0200, David Brown
<david.brown@hesbynett.removethisbit.no> wrote:
>Jon Kirwan wrote:
>> On Tue, 29 Sep 2009 18:11:52 +0000 (UTC), Grant Edwards
>> <invalid@invalid.invalid> wrote:
>>
>>> On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>>> On Tue, 29 Sep 2009 17:23:33 +0000 (UTC), Grant Edwards
>>>> <invalid@invalid.invalid> wrote:
>>>>
>>>>> On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>>>>
>>>>>>> Does that mean that any RTOS has limitation about task routine
>>>>>>> complexity ,
>>>>>> Not for the most part. There are exceptions, such as cases that
>>>>>> hardware may impose from time to time. But not in the way you
>>>>>> asked... for loops are always, in my experience, easy to handle.
>>>>> One thing to watch out for on the'430 is the hardware
>>>>> multiplier. Its state isn't part of the normal register set,
>>>>> and HW multiply operations are not atomic. If you use the HW
>>>>> multiplier in more than one task, you've either got to
>>>>> save/restore it's state as well or you have to make sure that
>>>>> interrupts are disabled around HW multiply operations.
>>>> Did I fail to introduce that idea in my post? I seem to recall
>>>> including some words there.
>>> I probably missed it.
>>
>> I probably wrote too much.
>
>Have you ever thought about setting up a website (perhaps a wiki), and
>just posting pointers when answering posts like these? Sometime in this
>group you post an amazing amount of information - it seems a shame to
>think this work will disappear (no one actually follows the rule of
>searching a newsgroup archives before posting a question). Posts like
>that are also so long that many people will skip them, thinking they'll
>read them later when they have more time. If you had this stuff on a
>wiki, I know I would read them more often.
>
>mvh.,
>
>David
Hehe. Okay. I admit I do have a site I can use where I can install
server software. I'll see about setting something up. You are
probably right, though it does take some effort to set things up,
think about what may be desired, and get them seeded well enough with
starting material. But it is something I should do. Kick me more. ;)
jon
Reply by David Brown●September 29, 20092009-09-29
Jon Kirwan wrote:
> On Tue, 29 Sep 2009 18:11:52 +0000 (UTC), Grant Edwards
> <invalid@invalid.invalid> wrote:
>
>> On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>> On Tue, 29 Sep 2009 17:23:33 +0000 (UTC), Grant Edwards
>>> <invalid@invalid.invalid> wrote:
>>>
>>>> On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>>>
>>>>>> Does that mean that any RTOS has limitation about task routine
>>>>>> complexity ,
>>>>> Not for the most part. There are exceptions, such as cases that
>>>>> hardware may impose from time to time. But not in the way you
>>>>> asked... for loops are always, in my experience, easy to handle.
>>>> One thing to watch out for on the'430 is the hardware
>>>> multiplier. Its state isn't part of the normal register set,
>>>> and HW multiply operations are not atomic. If you use the HW
>>>> multiplier in more than one task, you've either got to
>>>> save/restore it's state as well or you have to make sure that
>>>> interrupts are disabled around HW multiply operations.
>>> Did I fail to introduce that idea in my post? I seem to recall
>>> including some words there.
>> I probably missed it.
>
> I probably wrote too much.
>
Have you ever thought about setting up a website (perhaps a wiki), and
just posting pointers when answering posts like these? Sometime in this
group you post an amazing amount of information - it seems a shame to
think this work will disappear (no one actually follows the rule of
searching a newsgroup archives before posting a question). Posts like
that are also so long that many people will skip them, thinking they'll
read them later when they have more time. If you had this stuff on a
wiki, I know I would read them more often.
mvh.,
David
Reply by Jon Kirwan●September 29, 20092009-09-29
On Tue, 29 Sep 2009 18:11:52 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:
>On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>> On Tue, 29 Sep 2009 17:23:33 +0000 (UTC), Grant Edwards
>><invalid@invalid.invalid> wrote:
>>
>>>On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>>
>>>>>Does that mean that any RTOS has limitation about task routine
>>>>>complexity ,
>>>>
>>>> Not for the most part. There are exceptions, such as cases that
>>>> hardware may impose from time to time. But not in the way you
>>>> asked... for loops are always, in my experience, easy to handle.
>>>
>>>One thing to watch out for on the'430 is the hardware
>>>multiplier. Its state isn't part of the normal register set,
>>>and HW multiply operations are not atomic. If you use the HW
>>>multiplier in more than one task, you've either got to
>>>save/restore it's state as well or you have to make sure that
>>>interrupts are disabled around HW multiply operations.
>>
>> Did I fail to introduce that idea in my post? I seem to recall
>> including some words there.
>
>I probably missed it.
I probably wrote too much.
Jon
Reply by Grant Edwards●September 29, 20092009-09-29
On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
> On Tue, 29 Sep 2009 17:23:33 +0000 (UTC), Grant Edwards
><invalid@invalid.invalid> wrote:
>
>>On 2009-09-29, Jon Kirwan <jonk@infinitefactors.org> wrote:
>>
>>>>Does that mean that any RTOS has limitation about task routine
>>>>complexity ,
>>>
>>> Not for the most part. There are exceptions, such as cases that
>>> hardware may impose from time to time. But not in the way you
>>> asked... for loops are always, in my experience, easy to handle.
>>
>>One thing to watch out for on the'430 is the hardware
>>multiplier. Its state isn't part of the normal register set,
>>and HW multiply operations are not atomic. If you use the HW
>>multiplier in more than one task, you've either got to
>>save/restore it's state as well or you have to make sure that
>>interrupts are disabled around HW multiply operations.
>
> Did I fail to introduce that idea in my post? I seem to recall
> including some words there.