On Tuesday, 9 October 2001 2:34 PM, Scott Dattalo wrote

Hi,

I have used this technique also :-). I think someone pointed it out earlier,
that there is no need for a subroutine to return its own call. Another
variation on this one is for example instead of calling individual tasks you
had a call to a jump vector, you could use the technique for a command
interpreter whereby the routine called will return in-place as you have
described here but the actual subroutine "called" would the interpreted
result of some bytecode... and if it created an error you could even jump to
an exception handler ;-)

>Again, I think this approach is little more than an intellectual
>curiosity. The same kind of programming can be achieved with goto's
>replacing the returns. Then the call limitation can be removed.

Agreed :-)

Regards,
James Caska
caska@virtualbreadboard.com
ujVM - 'The worlds smallest java virtual machine'



-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Scott Dattalo
Sent: Tuesday, 9 October 2001 2:34 PM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]:


On Tue, 9 Oct 2001, James Caska wrote:

> Hi,
>
> Just to re-iterate. All I ever said was that it can be "handy" to flush
the
> stack and that in a controlled environment can solve some difficult
problems
> like Abrupt Call Path exit which can be used for Exception Handling in a
> controlled environment. I never said it was a pop, and only ever pointed
it
> out as a 'trick' to gain some control over the stack.




Here's a trick where stack stuffing is useful. I alluded to it earlier,
but it probably wasn't too obvious. I haven't actually had a need for this
kind of code (well, not exactly this kind, but something similar).


Install1
     goto   init_task1
Install2
     goto   init_task2
Install3
     goto   init_task3
...
Install8
     goto   init_task8

start
     return


;----------------- Tasks ------------------------
init_task1
     call   Install2  ; This call places the address of 'task1'
                      ; on the call stack. Install2 doesn't return.
task1
  ; task 1 code - contains no calls
    ....

  ; do stuff
  ; when done, exit with a return

    return     ; run next task


init_task2
     call   Install3
task2

    ....

    return


.....



init_task8
     call   start
task8

    ....

    return



The idea is that the stack is pre-loaded with return addresses that point
to the beginning of each "task". When a task is completed, it executes a
return.  This will send control to the next task. This can continue
indefinitely since the stack will roll over after eight returns have been
excuted.

The major limitation is that none of the tasks can make a call. This will
destroy the contents on the stack. Similary, interrupts cannot be enabled.

Again, I think this approach is little more than an intellectual
curiosity. The same kind of programming can be achieved with goto's
replacing the returns. Then the call limitation can be removed.

Scott

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads