1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Stack growth towards high addresses?

Discussion in 'Embedded' started by larwe, Mar 23, 2007.

  1. larwe

    larwe Guest

    Several RISC architectures are neutral about stack growth direction,
    because they don't "microcodedly" push registers into RAM; they switch
    to alternate register sets during exceptions, for example, and instead
    of having a "call" instruction that pushes a return address, they have
    a "branch and link" instruction that saves the return address in a
    link register. PA-RISC is an example where the stack often (always?)
    grows up, e.g. in the canonical HP-UX. ARM and PowerPC can also use
    stacks that grow up, down or sideways according to the developer's
    particular fetish.
     
    larwe, Mar 23, 2007
    #1
    1. Advertisements

  2. larwe wrote:

    My beliefs are the code portability and the independence from the
    underlying hardware.

    For example, if I am allocating a stack for a task something like:

    task_stack = new u32[stacksize];
    task_SP = task_stack + stacksize;


    Should the SP be always set to the end of stack or there could be a
    significant number of cases when the task_SP should be set to the beginning?

    On another question, is the SP always pre-decremented or there are
    architectures where SP is post-decremented?


    Vladimir Vassilevsky

    DSP and Mixed Signal Design Consultant

    http://www.abvolt.com
     
    Vladimir Vassilevsky, Mar 23, 2007
    #2
    1. Advertisements

  3. What CPUs, except x51, do have the direction of the stack growth from
    low to high addresses?

    VLV
     
    Vladimir Vassilevsky, Mar 23, 2007
    #3
  4. larwe

    Ken Asbury Guest

    To quote my favorite philosopher, "Everybody should believe
    in something and I believe that I'll have another drink."
    Seems to me that larwe answered very adequately
    so I'm at a loss as to why you would ask it again.
    Yes!

    C'mon, Vladimir, your website claims expertise
    in AD DSPs and hardware. That's not the kind
    of question one would expect from someone who
    has read AD's documentation on their 32-bit chips.

    Ken Asbury
     
    Ken Asbury, Mar 23, 2007
    #4
  5. larwe

    larwe Guest

    Well, this is a semantic question; what, exactly, is "significant"?
    There are relatively few architectures that have a hardware-enforced
    "directionness" that makes the stack grow up. The RISC architectures I
    mentioned are neutral, _BUT_ there are ABI definitions, generally
    adhered to by compilers, that might "encourage" one direction rather
    than another. Your life will become consummately interesting if you
    defy this without modifying the compiler, operating system and
    libraries with which you intend to interoperate.

    This issue has been dealt with extensively by the porters of Linux to
    eldritch architectures.
    I can't think of a useful example off the top of my head, but I've got
    a vague memory tickling the back of my mind.
     
    larwe, Mar 23, 2007
    #5
  6. larwe

    msg Guest

    From the Intel 80x196kb users' guide:

    "On the 8096BH, the address is calculated
    based on the un-updated version of the stack
    pointer. The 80C196KB uses the updated version. The
    offset for POP[SP] and POP nn[SP] instructions may
    need to be changed by a count of 2."

    I am currently working with the 8096 and need to treat the stack
    pointer as post-decremented.

    Regards,

    Michael
     
    msg, Mar 23, 2007
    #6
  7. larwe wrote:


    The context is the following: I am developing the small RTOS keeping in
    mind the portability to the popular architectures. The RTOS is seen as a
    library module with the minimum dependencies from the tool chain and the
    target. So, the question is if it can be assumed that the stacks are
    always from high to low address, pre-decremented, or it should be
    defined as the configuration or build option.

    I can't recall any except x51, that's why I am addressing the question
    to the club.
    And what conclusion did they came to?

    VLV
     
    Vladimir Vassilevsky, Mar 23, 2007
    #7
  8. larwe

    larwe Guest

    Then you have a logical inconsistency highlighted by merely asking
    your original question, viz: if you are targeting "popular"
    architectures, why are you worrying about obscure, rare, alien
    architectures not known to the majority of engineers or programmers?
    And the answer - which you didn't really need to ask in order to know
    - is that it is most flexible if you make it configurable, but most
    people will be satisfied with the assumption of a downgrowing stack.
    Are you asking a question? Well, on ARM, it's normally down, PA-RISC
    it's up, MIPS it's down, PowerPC it's down, but you can implement it
    the other way on any of those architectures.
    Solutions have been found for processors capable of running Linux. The
    MCS51 etc obviously do not qualify.

    For your application, it's non-obvious why you need to know; your RTOS
    and libraries would presumably conceal most of this information from
    the caller (e.g. if your caller needs to start a thread and provide
    stack space, he passes a pointer to the start of the block, and a size
    parameter, and your OS handles any required arithmetic and
    housekeeping).
     
    larwe, Mar 23, 2007
    #8
  9. Why woudl the portable part of your RTOS even need to know?
    Wouldn't the low-level context handling code for a particular
    target deal with all of that?

    If for some reason it does need to know, it should absolutely
    be configurable.
     
    Grant Edwards, Mar 23, 2007
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.