🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #21635

Re: Register usage

#21635
From: mcg
Date: Wed, 07 Jun 1989 22:58
65 lines
2411 bytes
In article <20810@orac.mips.COM> earl@orac.mips.com (Earl Killian) writes:
>Another problem with register windows is that they make it difficult
>to support coroutines.  I typically do queuing simulations by having
>multiple coroutines representing separate entities, each with a
>separate stack.  I've implemented this on VAXs, 68000s, and MIPS boxes
>with only 20-50 lines of assemlber.  But I can't see any way to do
>stack switching on a register window machine without a kernel call
>(yuck).  Have any of the register window architectures implemented a
>way for user code to do stack switching?

This is easiest to answer with code for the 960.  I count 15 instructions.
This code was written by Jim Valerio.  'pfp' is the previous frame pointer
register.


/*
 *	C callable coroutine support for 960
 *
 */

/*
 *	co_fp = co_init(stk_addr, init_ip);
 *
 * Creates coroutine on the stack `stack_addr' to begin at `init_ip'.
 * The value returned should be assigned to a global variable which
 * is used in calls to co_jump (e.g. task1 = co_init(...) and later
 * co_jump(task1)).  We assume that `stk_addr' is properly aligned.
 *
 */
	.globl	_co_init
_co_init:
	st	g14,(g0)	/* pfp := 0  (assumes g14 is 0) */
	lda	0x40(g0),g2
	st	g2,4(g0)	/* initial sp */
	st	g1,8(g0)	/* init_ip */
	ret

/*
 *	co_jump(&my_fp, new_co_fp);
 *
 * Saves away the calling-frame's FP for a later return, and then
 * returns to the new coroutine's context.  We know here that the
 * C calling convention requires that only g8..g12 be saved.
 */
	.globl	_co_jump
_co_jump:
	movq	g8,r4
	mov	g12,r8
	call	co_swap
	mov	r8,g12
	movq	r4,g8
	ret

co_swap:
	st	pfp,(g0)
	flushreg
	mov	g1,pfp
	ret			/* goto new coroutine */


-------------------------------------------------------------------------------

S. McGeady
Intel Corp.
Technical Details
Message-ID: <m0fVBqk-0001khC@mipon2.intel.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!oliveb!mipos3!omepd!mcg
References: <259@mindlink.uucp> <25382@ames.arc.nasa.gov> <m0fRx4x-0001fDC@mipon2.intel.com> <1RcY6x#64Zq3Y=news@anise.acc.com> <26204@ames.arc.nasa.gov> <20810@orac.mips.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!oliveb!mipos3!omepd!mcg
From: mcg@mipon2.intel.com
Newsgroups: comp.arch
Subject: Re: Register usage
Message-ID: <m0fVBqk-0001khC@mipon2.intel.com>
Date: 7 Jun 89 22:58:17 GMT
References: <259@mindlink.uucp> <25382@ames.arc.nasa.gov> <m0fRx4x-0001fDC@mipon2.intel.com> <1RcY6x#64Zq3Y=news@anise.acc.com> <26204@ames.arc.nasa.gov> <20810@orac.mips.COM>
Sender: news@omepd.UUCP
Reply-To: mcg@mipon2.UUCP (Steven McGeady)
Organization: Intel Corp., Hillsboro
Lines: 65