To: perot@pallas.amp.uni-hannover.de
Subject: Re: System stack problem ...                                                    


On Sun, 5 Jan 1997 21:44:18  Peter Rottengatter <perot wrote: 
>
>Hi

Hi Peter !


>When testing STiK I got bombs due to system stack overflow.

I assume you mean the supervisor stack as indicated by SSP, which at entry
to interrupt routines is also the active A7 (since CPU is in super mode).


>I almost expected that problem, I knew the system stack is small. So I tried
>to reuse the STIK.PRG's stack as a system stack replacement during the STiK 
>work execution.

I assume this means that in the STiK work portion of the interrupt code you
have set a7 to the same local stack area used by STiK init before Ptermres.


>During the install_timer function I saved the user stack pointer, and
>after the work call has saved the CPU registers (now with a7) I added an
>instruction to load the system stack pointer. The movem that restores the
>CPU registers also restores the normal system stack. But I got bombs again,
>which was at first not too surprising, the STIK.PRG stack was small too.

That is not the only, or even the worst problem.  The major problem is that
the STiK initialization code, using that same stack (via USP and/or SSP) is
still running, so any STiK work interrupt will smash that stack and cause
STiK to bomb before (or during) Ptermres.  This may act inconsistently too.


>Set stack size at 32700 bytes. Bombs. Added a 
>
>     sub.l #6000, sp
>
>after the move.l ..., sp. Now everything works. How can this come ?

That is clear.  The subtraction segments the stack area into two separate
parts.  One of 6000 bytes for the still running STiK initialization code,
and another of 26700 bytes for the interrupt code.  With separate stacks
there is no conflict between them.


>Any explanation ? I'd like to know what I must do in order to replace the 
>system stack temporarily.

You have already stumbled on the correct solution (two separate stacks),
even though you have used unnecessarily large stacks.  I'd rather suggest
something like this:

;----------------------------------------------------------------------
;NB: For brevity I've used my lib macros to acces GEMDOS and XBIOS below.
;    Hopefully their use will be clear to you, so you can translate them
;    to calls of whatever lib you are using.  Otherwise tell me ASAP.
;----------------------------------------------------------------------
	SECTION	TEXT
;------------------------------
;
progbase:			;This is the first address in the program
	bra	STiK_init	;Initialize the TSR
;------------------------------
;
;Insert all STiK API code here
;
;Somewhere in the interrupt code you should reload SSP by using:
;
;	lea	thread_stack_top(pc),a7
;
;Note that this must be in a section of the code protected against reentrancy,
;preferably by a TAS operation as we have discussed previously.
;------------------------------
;
;Insert all STiK API data and variables here (use Malloc for buffers/arrays)
;
thread_stack_base:
	ds.b	1024		;1 Kbyte stack for interrupt work routine
thread_stack_top:
;----------------------------------------------------------------------
resident_end:	;The end of the resident program, all beyond is released
;----------------------------------------------------------------------
;
STiK_init:
	move.l	4(sp),a5		;a5 -> STiK basepage
	lea	init_stack_top(pc),a7	;reload USP for local stack
	gemdos	Mshrink,!,(a5),$100+initial_end-progbase	;release RAM
	xbios	Supexec,STiK_init_supx	;init stuff needing Super mode
;
;Insert all STiK User mode init code here
;
	gemdos	Ptermres,#$100+resident_end-progbase,0	;go TSR and release more
;
;------------------------------
;
STiK_init_supx:
;
;Insert all STiK Super mode init code here
;
	rts			;return to main STiK_init routine
;
;----------------------------------------------------------------------
	SECTION	DATA
;------------------------------
;NB: This is nonresident, so no stuff needed after init can be here
;Insert only predefined STiK initialization data here
;
;------------------------------
	SECTION BSS
;------------------------------
;NB: This is nonresident, so no stuff needed after init can be here
;Insert all STiK initialization variables here
;
init_stack_base:			;lo limit of initialization stack
	ds.b	2048			;reserve 2 Kbyte
init_stack_top:				;hi limit of initialization stack
;
initial_end:				;hi limit of entire program
;------------------------------
	END
;----------------------------------------------------------------------


As you can see, this makes the file a bit longer, since the resident stack
lies in the 'TEXT' section, rather than in the 'BSS' section.  The reason
for doing this is that it allows us to release lots more RAM at Ptermres,
by releasing all areas only needed for initialization.


>I think I'll talk to Andreas again, for which I have another reason. The 
>replacement of the MAPTAB pointers that I told you before does not work 
>properly, CoNnect for instance is able to access the port even if I click 
>Modem 1 active for STiK. The result is that some bytes go to STiK, others 
>go to CoNnect, none of both is happy of course.

Ok, but the stack problem seems very clear to me, and the MAPTAB problem
becomes irrelevant if we opt for the 'p_run' solution instead.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
