How does context switching work?

[Joel Sherrill]

On Sat, Oct 31, 2020, 10:51 AM Richi Dubey <richidubey at gmail.com> wrote:

> Hi,
>
> I want to learn more about how context switching works in RTEMS. I saw the
> following lines in theaddispatch.c:
>
>     _Thread_Save_fp( executing );
>     _Context_Switch( &executing->Registers, &heir->Registers );
>     _Thread_Restore_fp( executing );
>
> I do not understand how it works. Here, the executing process saves its
> context by calling _Thread_Save_fp( executing ), then if a different
> process resumes execution after the context switch, why does it get the
> context of previous process (executing)?
>
> Can someone help me learn more about this?
>

In general, floating point registers are not touched unless there are
floating point operations. There are exceptions to this where GCC uses the
floating point unit for surprising reasons but that rule generally holds.

the code that switches the integer registers takes care of the stack,
status register, and the general programming registers which must be
preserved across subroutine calls.

This approach allows for lazy context switches where the floating point
unit holds the state of a previous thread until it runs again. On some
single processor architectures, this can result in great speed ups.

But that code is okay because the floating point unit is not used during
that sequence. it is untouched and up to a point it doesn't matter when the
floating point unit is restored as long as it's before the thread needs it.
And RTEMS should not be using floating point operations except in very
special places in the code base.

not sure that helps but the floating point unit and the integer unit are
separate and most of the time can be contact switched separately completely
safely.


> Thanks,
> Richi.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201031/8c3ab005/attachment.html>