Return-Path: <perot@pallas.amp.uni-hannover.de>
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3])
          by hugin.oden.se (8.8.4/8.8.4) with SMTP
	  id KAA19995 for <dlanor@oden.se>; Thu, 9 Jan 1997 10:44:34 +0100
Received: from pallas.amp.uni-hannover.de by mgate with SMTP (PP);
          Thu, 9 Jan 1997 10:33:33 +0100
Received: by pallas.amp.uni-hannover.de (AIX 3.2/UCB 5.64/4.03) id AA19952;
          Thu, 9 Jan 1997 10:34:07 +0100
Date: Thu, 9 Jan 1997 10:34:06 +0100 (MET)
From: Peter Rottengatter <perot@pallas.amp.uni-hannover.de>
To: Ronald Andersson <dlanor@oden.se>
Subject: Re: [2] System stack problem ...
In-Reply-To: <199701082217.XAA07887@hugin.oden.se>
Message-Id: <Pine.A32.3.91.970109101938.22596E-100000@pallas.amp.uni-hannover.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: d94d17c9cb4f5b2468f49080a454f8a8


On Wed, 8 Jan 1997, Ronald Andersson wrote:

> On Wed, 8 Jan 1997 00:23:33  Peter Rottengatter <perot wrote: 
> >
> >On Tue, 7 Jan 1997, Ronald Andersson wrote:
> 
> >> >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.
> >
> >No, the work part (and thus the part using the stack as system stack) is 
> >only called from the interupt when STiK gets activated. STiK is passive 
> >after startup, it gets activated by either ConfSTiK or STIKCPX.CPX. So no 
> >way for the stacks to get mixed up.
> 
> Oh, sorry then.  It's just that in the early threader code you showed me,
> there was a 'house_cleaning' vector which was regularly invoked regardless
> of the STiK activity.  If that had still been the case,  it would cause
> problems of the type you described for the reasons I described.

The cleaning is still there, but along with the work code it gets 
desactivated. The only difference between the `work' and the `cleaning' 
is that the latter is called once a second, whereas the call frequency
of the former is adjustable, both only if STiK is set active.


> Ok.  I suppose the threader has changed too much from its original form
> for my conclusions based on that code to be valid.  If you don't mind,
> it would be very interesting to see the new source, in which case I may
> also be able to find some more relevant explanation of the problems.

Yes, I know I wanted to send it the other day, but I didn't get around to 
actually doing it. Here I try again ;-)


   ; This is the end of the install routine :

            move.l  sp, sys_stack                ;" Pointer to our stack
            rts

;-------------------------------------------------------------------------------------)

            .dc.l   'XBRA'                       ;" XBRA structure for
            .dc.l   'STiK'                       ;" STiK ...
old_200_Hz: .ds.l   1                            ;" Old 200 Hz timer vector

my_200_Hz:
            move.l  d0, extra_do                 ;" Save d0, we'll use it
            add.l   #5, stik_clock               ;" Count stack internal clock
            move.l  #86400000, d0                ;" One day in milliseconds
            cmp.l   stik_clock, d0               ;" Day elapsed ?
            bpl     clk_ok                       ;" No, ready
            sub.l   d0, stik_clock               ;" Correct clock otherwise
clk_ok:     move.l  extra_do, d0                 ;" Restore d0 now
            sub.w   #1, traffic                  ;" Count down for IP traffic
            bne     early_a                      ;" Is it time for it ?
            move.w  fraction, traffic            ;" Yes : Reset counter
            bset    #0, tm_exec                  ;" Signal : Do work
early_a:    sub.w   #1, cleaning                 ;" Count down for Cleaning up
            bne     early_b                      ;" Is it time for it ?
            move.w  #200, cleaning               ;" Yes : Reset counter
            bset    #1, tm_exec                  ;" Signal : Do work
early_b:    tst.w   tm_sema                      ;" STiK work still on ?
            bne     lazy                         ;" Yes : Do nothing
            tst.w   active                       ;" Are we switched active ?
            beq     lazy                         ;" No : Do nothing
            tst.w   tm_exec                      ;" Something to do ?
            bne     here_we_go                   ;" Yes : Do some work now
lazy:       move.l  old_200_Hz, -(sp)            ;" Jump to system handler
            rts

active:     .dc.w   0                            ;" Flag for active
traffic:    .dc.w   1                            ;" Counter for IP traffic
fraction:   .dc.w   10                           ;" Divide by this
cleaning:   .dc.w   1                            ;" Counter for Cleaning up
tm_sema:    .dc.w   0                            ;" Execution semaphore
tm_exec:    .dc.w   0                            ;" Execution flags
stik_clock: .dc.l   0                            ;" Internal clock
sys_stack:  .dc.l   0                            ;" Our stack pointer

here_we_go:
            tst.w   longframe                    ;" Do we have a 68000 CPU ?
            beq     cpu_fixed                    ;" Yes, no extra stack word
            clr.w   -(sp)                        ;" Extra stack word for 680X0
cpu_fixed:  pea     keep_going                   ;" Install exception stack frame
            move.w  sr, -(sp)                    ;" For return to STiK work
            move.l  old_200_Hz, -(sp)            ;" Jump to system handler
            rts

keep_going:
            move.w  #-1, tm_sema                 ;" Signaling STiK work
            movem.l d0-d7/a0-a7, cpu_state       ;" Save CPU register
            move.w  (sp), d0                     ;" Fetch status from stack
            bset    #13, d0                      ;" Stay in Super mode
            move.w  d0, sr                       ;" Lower interupt level
            move.l  sys_stack, sp                ;" Install our system stack
            btst    #0, tm_exec                  ;" IP traffic to do ?
            beq     dont_a                       ;" No : Skip it
            lea     poll_ports, a0               ;" Address of IP traffic routine
            jsr     (a0)                         ;" Execute it !
            bclr    #0, tm_exec                  ;" Signal done it
dont_a:     btst    #1, tm_exec                  ;" Clean up to do ?
            beq     dont_b                       ;" No : Skip it
            lea     clean_up, a0                 ;" Address of clean up routine
            jsr     (a0)                         ;" Execute it !
            bclr    #1, tm_exec                  ;" Signal done it
dont_b:     movem.l cpu_state, d0-d7/a0-a7       ;" Restore CPU register
            clr.w   tm_sema                      ;" STiK work finished
            rte

extra_do:   .ds.l   1                            ;" Just one for d0
cpu_state:  .ds.l   16                           ;" Space for CPU registers

;-------------------------------------------------------------------------------------)


I got a mail from Andreas Kromke. He states MagiC has a Stack of 5 ... 6 
kB, MagiCMac has more. TOS has 1 kB. This means MagiC does not need any 
extra system stack, 5 kB is enough by far. 1 kB on TOS might be tight, 
however, so maybe I reset the stack only for TOS.


Cheers  Peter

---------------------------------------------------------------------
   Peter Rottengatter             perot@pallas.amp.uni-hannover.de
---------------------------------------------------------------------

.
