Re: setjmp/longjmp and sparc

[Matt Emerson <matt@rme.com> writes:]

>i don't understand how setjmp/longjmp are used to
>switch contexts in sched.c.

Unlike classic UNIX, VSTa does not have all kernel stacks exist at the same
address. Thus, when you want to switch processes, you simply need to swap
register values to point at a new stack (and restore whatever other
registers restore you to the corresponding execution context).

The changing of VM context to a new process mostly impacts the *user*
portion of the address space; the kernel portion is identical across all
processes.

>on a sparc, setjmp just saves the caller's stack pointer,
>frame pointer, and return pc; longjmp simply unwinds the
>call stack by popping register windows until it finds the
>matching frame.

As I understand Sparc (never done kernel work for it, but read a little
about it), the CPU has a window of stack space which is implemented with
register-level performance. Thus, the i386-like dichotomy between registers
and stack variables is a little fuzzier.

>i take it that a jmp_buf saves a lot more stuff (like an
>almost-complete copy of the register file) on other
>architectures? i think my ignorance of how setjmp/longjmp
>works on other machines is part of my problem in understanding
>what's going on.

And since the "register file" is basically just a portion of the stack
context, restoring stack context should be all that's needed.

I assume there's still a collection of stuff towards the top of the stack
which you pop off as a part of returning to user mode?

                                                Andy
Received on Wed Jan 11 10:13:36 1995