To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 256
255  |  257
Subject: 
signals / legOS internals
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Wed, 23 Jun 1999 00:40:15 GMT
Viewed: 
1044 times
  
Peek-a-boo!

I've been banging my head against this a bit and thought I'd see if any
of you can shove me in the right direction.  I am trying to implement
signals in legOS.  The problem is that a signal can happen at any time.
I know how to make that happen, but what is causing me trouble is that I
need to be able to put stuff on the stack.

I was rolling along, planning this out, then it occurred to me that
local (to the function) variables are on the stack above the stack
pointer.  That means that pushing anything on the stack asynchronously
is going to toast those variables.  It  makes me wonder why that doesn't
happen whenever OC1A happens.

Currently, my thinking is to allocate a second stack for each process,
just for signal handling.  To keep the waste down, I'd allocate it only
if a signal is sent to a given task.  If there is a better way to cope
with this, I'm all ears.



Message has 3 Replies:
  Re: signals / legOS internals
 
(...) The stack pointer must always always always point at the bottom of the stack data area, i.e. to the last valid data item on the stack. As a consequence, push val (or mov.w val,@-r7) never overwrites data. When an interrupt occurs, the first (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
  Re: signals / legOS internals
 
(...) Actually, gcc moves the stack pointer before using any variables, so it is always safe to use stack below the current stack pointer. If you are using a different C compiler or doing assembly tricks, then you are on your own. (...) Traditional (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)
  Re: signals / legOS internals
 
(...) Why signals?!? Unix-style asynchronous signals is the last feature I would ever want to implement or use. Brain-dead and very dangerous "feature". As you write; "The problem is that a signal can happen at any time". You shouldn't pass this (...) (25 years ago, 23-Jun-99, to lugnet.robotics.rcx.legos)

32 Messages in This Thread:









Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR