Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
06/27/06 06:56
Read: times


 
#119174 - on stack and data
Responding to: ???'s previous message
Erik Malund said:
you will put the stack at the top of RAM (more DATA, low stack frce moer IDATA) so why the statement and check if it won't collide with data


In most of processors I used the stack was growing downwards so one sets it to top and if one won't check it overwrites data.

In '51 if one sets SP to have enough stack (based on stack usage calculation) it might collide with data straight off; there might be some automatic check for this in compiler/assembler (I don't know).

Most of the people don't calculate/estimate stack usage at all (assuming "infinite" stack, especially when using C*); so they simply set it at the end of data and assume it will do; sometimes it will, sometimes it won't. Depending on the application, the resulting crashes might be a nightmare possibly with no pattern and trace to go.

'51's don't have explicit hardware mechanism for stack range checking (leading to exception) so upon stack overflow there is no predictible behaviour (Jez, Richard: you might want to add this as a feature to your '51 softcores). One trick might be to add minimum stack checking to the interrupts; but this is not universal either.

JW
-----------
* this is a "high level language" paradigm: true HLL programming assumes infinite resources - data&code&stack memory, speed


List of 19 messages in thread
TopicAuthorDate
best practice regarding SP            01/01/70 00:00      
   an easier method            01/01/70 00:00      
   the other way round            01/01/70 00:00      
      as a general rule            01/01/70 00:00      
         Good rule            01/01/70 00:00      
         on stack and data            01/01/70 00:00      
            Estimating stack usage            01/01/70 00:00      
               The future is now            01/01/70 00:00      
                  I'd like it also as interrupt...            01/01/70 00:00      
                     where would you store the interrupt retu            01/01/70 00:00      
                        what return???            01/01/70 00:00      
                           then don't call it an interrupt            01/01/70 00:00      
                              OK, call it... exception?            01/01/70 00:00      
                              Trap perhaps?            01/01/70 00:00      
                                 trap!            01/01/70 00:00      
                                 the root            01/01/70 00:00      
                                    Fair point            01/01/70 00:00      
                                       signaling            01/01/70 00:00      
                                    avost?            01/01/70 00:00      

Back to Subject List