On Tue, 25 Dec 2001, Bob Ammerman wrote:

> ----- Original Message -----
> To: <PICLIST@MITVMA.MIT.EDU>
> Sent: Monday, December 24, 2001 11:51 AM
> Subject: Re: [PIC]: Implementing MCLR in software
>
>
<snip>

> >
> > BTW I bet a small sum of money that most simulators do not follow this
> > functionality. As to usefullness ? Every merchandise has its buyer [tm].
> >
> > Peter
> >
>
> Peter,
>
> This sample will NOT work because only one entry on the stack has been
> initialized
> to contain the return address that gets you back to 'Thesub'.
>
> This ugly code would work however (assuming interrupts are off):
>

<snip>

We talked about stack priming before (in the context of RTOS'). I just
whipped together this routine and tested it with gpsim (Peter, you'd lose
a small sum of money if you were betting getting agains gpsim).

        list    p=16f84

        ;; The purpose of this program is to test gpsim's capability to
simulate
        ;; the PIC's stack.
        ;;
        ;;   Start gpsim:
        ;;   $ gpsim
        ;;   then load the Startup command file 'stack_test.stc':
        ;;   gpsim> load c stack_test.stc
        ;;
        ;;    OR
        ;;
        ;;   invoke gpsim with the command file
        ;;   $ gpsim -c stack_test.stc
        ;;
        ;;    OR
        ;;
        ;;   invoke the simualtion from the Makefile:
        ;;   make sim

        ;; In all cases, the stimulus file will load the simulation
        ;; file and create the stimuli. In the Makefile case, the
        ;; simulation file will be (re)created if the .asm has been
        ;; been changed.
        ;;
        ;;



include "p16f84.inc"

  cblock  0x20

        temp1
        temp2
        temp3
  endc

        org     0
        goto    start

        org     4
start

init_tasks
        goto    Task_0_init
init_done


        return

        goto   $  ; never reached

Task_0_init:
        call    Task_1_init
Task_0:
        return

Task_1_init:
        call    Task_2_init
Task_1:
        return

Task_2_init:
        call    Task_3_init
Task_2:
        return

Task_3_init:
        call    Task_4_init
Task_3:
        return

Task_4_init:
        call    Task_5_init
Task_4:
        return

Task_5_init:
        call    Task_6_init
Task_5:
        return

Task_6_init:
        call    Task_7_init
Task_6:
        return

Task_7_init:
        call    init_done
Task_7:
        return

        end


-----
This code loads the stack with the starting addresses of each "task". A
"task switch" occurs by simply returning. As shown, this is hardly useful.
However, it's possible to retain one level of stack state per task. In
other words, as shown the code above will begin executing at the begining
of each task. However, if a call is made with in the task (just one call,
mind you), then the return address can be modified. E.g. Here's Task 1
modified to have two different exit points.


Task_1_init:
        call    Task_2_init
Task_1:

        btfsc   portb,0
        goto    t1b
        call    $+1        ; this changes task 1's exit
t1a
        movlw   2
        return
t1b
        movlw   3
        return


-----

As said before, while interesting I don't see much usefulness for this
kind of code.

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body