🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

6 total messages Started by Ken Gibson Fri, 02 Oct 1992 20:43
ctxsw routine for M68000
#115
Author: Ken Gibson
Date: Fri, 02 Oct 1992 20:43
5 lines
605 bytes
  Can someone post an M68000 version of the assembly language context switch
routine _ctxsw for Xinu?  

Many Thanks
Re: ctxsw routine for M68000
#117
Author: John Reed
Date: Mon, 05 Oct 1992 16:49
77 lines
3025 bytes
In article <1992Oct2.195944.772@nntpd2.cxo.dec.com> kgibsonkgibson@cxcad%decwrl.dec.com (Ken Gibson) writes:
>
>  Can someone post an M68000 version of the assembly language context switch
>routine _ctxsw for Xinu?  
>
>Many Thanks


*-----------------------------------------------------------------------------
* ctxsw  --	actually perform context switch, saving and loading registers
*		This routine is executed in kernel mode.
*
*		Upon entry, d0-d7, a0-a6, the usp, the sr, and the pc are
*		saved.
*
*		Upon exit, all registers saved are restored, and the value
*		of the user stack pointer is copied into the user 
*		stack pointer.
*-----------------------------------------------------------------------------

	section	14

	xdef	.cnt_ctxsw

.cnt_ctxsw	dc.l	0

	section	9

	xdef	.ctxsw

.ctxsw:
	addq.l	#1,.cnt_ctxsw
	move.l	a0,-(sp)	 		; Save A0 onto old stack	
	move.l	8(sp),a0			; Move address of old area into A0 
	movem.l	d0-d7/a0-a7,(a0)	; Save all registers		
	move.l	(sp),32(a0)			; Put original A0 in old savearea	
	addq.l	#8,60(a0)			; Move SP beyond return address
								; 	as if a return has occured
	add.l	#64,a0				; Skip past registers d0-7,a0-7
	move.w	#0,(a0)+ 			; Pad SR savearea, since SR is a word
	move.w	sr,(a0)+			; Save SR in old savearea
	move.l	4(sp),(a0)+			; Save PC in old savearea


*Save image:d0,d1,d2,d3,d4,d5,d6,d7,a0,a1,a2,a3,a4,a5,a6,ssp,0x00, sr, pc
*            0  4  8 12 16 20 24 28 32 36 40 44 48 52 56  60  64   66  68

	move.l	12(sp),a0			; Move address of new area into A0
	movem.l	(a0),d0-d7/a0-a6	; Restore all regs (even A0) except SP
	move.l	12(sp),a0			; Move address of new area into A0 again
	move.l	60(a0),sp			; Put  SSP into kernel stack
	move.l	68(a0),-(sp)		; Move PC onto current stack	
	move.w	66(a0),sr			; Restore the status register
	move.l	32(a0),a0			; Restore A0 from new area
	rts							; since we pushed the pc onto the stack,
								;   we just pretend to return






---JR---


-- 


   /------------------------------------------------------------------\
  |  John Reed                           {ucsd,uunet}!pacdata!johnr    |
  |  Pacific Data Products               johnr@pacdata.com             |
  |                    ---------------------                           |
  |  George Herbert Walker Bush, with the letters re-arranged spells:  |
  |                                                                    |
  |                 Huge Berserk Rebel Warthog                         |
  |                                     -- From Cosmic Trigger II      |
   \------------------------------------------------------------------/
Re: ctxsw routine for M68000
#119
Author: Michael Park
Date: Tue, 06 Oct 1992 07:48
105 lines
4670 bytes
Thanks to John Reed for posting his 68000 ctxsw (listing follows);
I have a few comments and questions about it:

1. The comments are inconsistent as to which stack pointer is actually
   saved, the usp or the ssp.  Since the routine is executed in kernel
   (aka supervisor) mode, all references to A7 or SP must refer to the
   SSP (unless I am very much mistaken).

2. Given (1) above, two questions spring to mind:
   a. since the USP is never saved, does that mean that the 68000
      is ALWAYS in supervisor mode?  Or,
   b. the 68000 can switch between user and supervisor modes, but
      it's perfectly safe not to save USP between context switches.
      (I seriously doubt that it's case b)

3. I was leafing through the Mac edition of the xinu book, and was
   forced to conclude that Mac xinu runs completely in supervisor
   mode (this was never stated explicitly as far as I could tell;
   there wasn't even an index entry for "supervisor").  Is that
   deduction correct, and is it true for Mac programs in general
   that everything is done in supervisor state?

4. Isn't running solely in supervisor state a bit of a lose?

I hope Mr. Reed or some other knowledgeable person can help me out.

------- listing follows ------

In article <1992Oct5.164946.19346@pacdata.uucp> johnr@pacdata.uucp (John Reed) writes:
...
>*-----------------------------------------------------------------------------
>* ctxsw  --	actually perform context switch, saving and loading registers
>*		This routine is executed in kernel mode.
>*
>*		Upon entry, d0-d7, a0-a6, the usp, the sr, and the pc are
>*		saved.
>*
>*		Upon exit, all registers saved are restored, and the value
>*		of the user stack pointer is copied into the user 
>*		stack pointer.
>*-----------------------------------------------------------------------------
>
>	section	14
>
>	xdef	.cnt_ctxsw
>
>.cnt_ctxsw	dc.l	0
>
>	section	9
>
>	xdef	.ctxsw
>
>.ctxsw:
>	addq.l	#1,.cnt_ctxsw
>	move.l	a0,-(sp)	 		; Save A0 onto old stack	
>	move.l	8(sp),a0			; Move address of old area into A0 
>	movem.l	d0-d7/a0-a7,(a0)	; Save all registers		
>	move.l	(sp),32(a0)			; Put original A0 in old savearea	
>	addq.l	#8,60(a0)			; Move SP beyond return address
>								; 	as if a return has occured
>	add.l	#64,a0				; Skip past registers d0-7,a0-7
>	move.w	#0,(a0)+ 			; Pad SR savearea, since SR is a word
>	move.w	sr,(a0)+			; Save SR in old savearea
>	move.l	4(sp),(a0)+			; Save PC in old savearea
>
>
>*Save image:d0,d1,d2,d3,d4,d5,d6,d7,a0,a1,a2,a3,a4,a5,a6,ssp,0x00, sr, pc
>*            0  4  8 12 16 20 24 28 32 36 40 44 48 52 56  60  64   66  68
>
>	move.l	12(sp),a0			; Move address of new area into A0
>	movem.l	(a0),d0-d7/a0-a6	; Restore all regs (even A0) except SP
>	move.l	12(sp),a0			; Move address of new area into A0 again
>	move.l	60(a0),sp			; Put  SSP into kernel stack
>	move.l	68(a0),-(sp)		; Move PC onto current stack	
>	move.w	66(a0),sr			; Restore the status register
>	move.l	32(a0),a0			; Restore A0 from new area
>	rts							; since we pushed the pc onto the stack,
>								;   we just pretend to return
>
>
>
>
>
>
>---JR---
>
>
>-- 
>
>
>   /------------------------------------------------------------------\
>  |  John Reed                           {ucsd,uunet}!pacdata!johnr    |
>  |  Pacific Data Products               johnr@pacdata.com             |
>  |                    ---------------------                           |
>  |  George Herbert Walker Bush, with the letters re-arranged spells:  |
>  |                                                                    |
>  |                 Huge Berserk Rebel Warthog                         |
>  |                                     -- From Cosmic Trigger II      |
>   \------------------------------------------------------------------/


-- 
Ciao-abunga!           +-------------------------------------+
Michael Park           | This space intentionally left blank |
mpark@u.washington.edu +-------------------------------------+
Re: ctxsw routine for M68000
#121
Author: John Reed
Date: Wed, 07 Oct 1992 00:09
75 lines
3624 bytes
In article <1992Oct6.074825.27658@u.washington.edu> mpark@stein.u.washington.edu (Michael Park) writes:
>Thanks to John Reed for posting his 68000 ctxsw (listing follows);
>I have a few comments and questions about it:
>
>1. The comments are inconsistent as to which stack pointer is actually
>   saved, the usp or the ssp.  Since the routine is executed in kernel
>   (aka supervisor) mode, all references to A7 or SP must refer to the
>   SSP (unless I am very much mistaken).


	You are correct.  The references are for the SSP.



>
>2. Given (1) above, two questions spring to mind:
>   a. since the USP is never saved, does that mean that the 68000
>      is ALWAYS in supervisor mode?  Or,
>   b. the 68000 can switch between user and supervisor modes, but
>      it's perfectly safe not to save USP between context switches.
>      (I seriously doubt that it's case b)


	Yes, the 68000 is always operated in the supervisor state.


>
>3. I was leafing through the Mac edition of the xinu book, and was
>   forced to conclude that Mac xinu runs completely in supervisor
>   mode (this was never stated explicitly as far as I could tell;
>   there wasn't even an index entry for "supervisor").  Is that
>   deduction correct, and is it true for Mac programs in general
>   that everything is done in supervisor state?
>
>4. Isn't running solely in supervisor state a bit of a lose?


	The usage of the user state is typically associated with an
	"untrustworthy" environment.  With the user state set, certain
	assembly language statements are not allowed.  These certain
	statements are generally those that control critical
	parts of the processor.  The statement which re-programs the
	status register is one such example.

	An example of an "untrustworthy" environment would be running
	Unix on the 68000.  User processes would all execute in the user
	state and code within the kernel would execute in the
	supervisor state.  Without this protection, an ornery programmer
	could easily code a program which modified the status register
	in order to lock out all interrupts.

	Xinu executes in a trusted environment on the 68000.  There might
	be exceptions to this rule, but generally Xinu is there to help
	facilate the running of some dedicated application.  The entire
	application (including Xinu) is just one big system-software
	program.  There is really no need to distinguish between user
	state and supervisor state because the entire program is
	trusted.


JR


-- 


   /------------------------------------------------------------------\
  |  John Reed                           {ucsd,uunet}!pacdata!johnr    |
  |  Pacific Data Products               johnr@pacdata.com             |
  |                    ---------------------                           |
  |  George Herbert Walker Bush, with the letters re-arranged spells:  |
  |                                                                    |
  |                 Huge Berserk Rebel Warthog                         |
  |                                     -- From Cosmic Trigger II      |
   \------------------------------------------------------------------/
Re: ctxsw routine for M68000
#100
Author: Serge Rouveyrol
Date: Fri, 09 Oct 1992 07:27
41 lines
1221 bytes
In article <1992Oct2.195944.772@nntpd2.cxo.dec.com> kgibsonkgibson@cxcad%decwrl.dec.com (Ken Gibson) writes:
>
>  Can someone post an M68000 version of the assembly language context switch
>routine _ctxsw for Xinu?  
>
>Many Thanks

*
*   ctxsw(OldSp,NewSp)
*   int *OldSp, *NewSp;
*
NBREGS  EQU     15
ADRRET  EQU     15*4
OLDSP   EQU     ADRRET+4
NEWSP   EQU     OLDSP+4

        xdef    _ctxsw
_ctxsw:
*
*   sauvegarde des registres du processus courant dans sa pile
*
        movem.l d0-a6,-(a7)
*
*   l'instant magique (eucharistique meme) : on fait l'echange des piles
*
        move.l  OLDSP(a7),a0
        move.l  sp,(a0)

        move.l  NEWSP(a7),a0
        move.l  (a0),a7
*
*   rechargement des registres du nouveau processus a partir de sa pile
*
        movem.l (a7)+,a6-d0
*
*   bye!
*
        rts

-- 
serge@imag.fr
Re: ctxsw routine for M68000
#102
Author: Serge Rouveyrol
Date: Mon, 12 Oct 1992 16:21
15 lines
1058 bytes
In article <1992Oct5.164946.19346@pacdata.uucp> johnr@pacdata.uucp (John Reed) writes:
>...................................
>	add.l	#64,a0				; Skip past registers d0-7,a0-7
>	move.w	#0,(a0)+ 			; Pad SR savearea, since SR is a word
>	move.w	sr,(a0)+			; Save SR in old savearea
>	move.l	4(sp),(a0)+			; Save PC in old savearea
>...............................

- It's not necessary ta save SR in the savearea

ps)
  It's most quickly to save context in the stack of process and
  to save the stack-pointer in the savearea
-- 
serge@imag.fr
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads