Date: Sun, 21 Dec 1997 19:35:04 -0700 From: Wes Peters <softweyr@xmission.com> To: Greg Lehey <grog@lemis.com> Cc: Ric Flinn <rmf@radiks.net>, Jason Evans <jasone@canonware.com>, freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing Message-ID: <349DD1D8.8C56047C@xmission.com> References: <Pine.BSF.3.96.971221003424.367P-100000@mozart.canonware.com> <349D746C.85A2D84F@radiks.net> <19971222101113.50010@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ric Flinn wrote:
% There are other ways for an OS to deal with register windows; consider
% the following: Instead of different register windows being used for
% function calls, have different windows available for different OS
% functions, such as interrupts and system calls. This way, when an
% interrupt occurs, you don't save the user program's registers, but just
% switch to a differnent (non-adjacent) window, which reduces a bit of
% overhead. Same with system calls, just switch to the kernel's register
% window.
Greg Lehey replied:
> I think you're misunderstanding the Sparc hardware. The Sparc has a
> register file (we'll discuss the terminology when I find my Sparc
> books, which are still in the shed since moving house) which is
> addressed something like a stack. At any time, 24 registers are
> addressable, organized as 8 input, 8 local, and 8 output registers.
> These registers are called the register window. Each function call
> moves the pointer on by 16 registers, so the output registers of the
> calling function become the input registers of the called function.
> Jason went into more detail about this in an earlier posting. There
> is no question of using the register file for anything but local data
> storage in an individual program.
Actually, you can setup GCC to do what Ric suggests, it is sometimes done
in embedded systems to keep the task switch latency down. The windows
don't necessarily work the way you expect, due to the overlapping of the
in/out registers, but they become a fast inter-process communications
channel, for up to NWINDOWS-1 processes. Typically, window 0 is reserved
for the OS core.
You'd be astonished how bad your performance gets on most SPARC architectures
when you try this. One important thing to keep in mind when designing using
RISC architectures is the setup of the memory system. Think of it as a
giant pipeline flowing into the processor -- anything flowing outward sets
up eddies that you cannot begin to visualize. This is the reason for the
large chip-local caches and the large register files on RISC chips. Trying
to change the SPARC into a traditional stack-based architecture is a sure
recipe for sluggish code.
(I tried this one with my port of uC/OS to the SPARClite. Context switch
times were fantastic, only about 20 instructions to switch, but the overall
performance was so terrible I re-recompiled the entire library and went
back to register windows. Now if I could just get the context switch to
work entirely reliably... ;^)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.xmission.com/~softweyr softweyr@xmission.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?349DD1D8.8C56047C>