Sign in

Not a member? | Forgot your Password?

Search Comp.Arch.Embedded

Search tips

Free PDF Downloads

Advanced Linux Programming

What Every Programmer Should Know About Memory

Introduction to Embedded Systems

C++ Tutorial

Embedded Systems - Theory and Design Methodology

Microcontroller Programming and Interfacing

Introduction to Microcontrollers


More Free PDF Downloads

Recent Blogs on EmbeddedRelated

Someday We’ll Find It, The Kelvin Connection
posted by Jason Sachs


Reverse engineering wireless wall outlets
posted by Fabien Le Mentec


Short Circuit Execution vs. Unit Testing
posted by Stephen Friederichs


Practical protection against dust and water (i.e. IP protection)
posted by Dr Cagri Tanriover


Specifying the Maximum Amplifier Noise When Driving an ADC
posted by Rick Lyons


How to make a heap profiler
posted by Yossi Kreinin


Introduction to Microcontrollers

1 - Beginnings

2 - Further Beginnings

3 - Hello World

4 - More On GPIO

5 - Interrupts

6 - More On Interrupts

7 - Timers

8 - Adding Some Real-World Hardware

9 - More Timers and Displays

10 - Buttons and Bouncing

11 - Button Matrix & Auto Repeating

12 - Driving WS2812 RGB LEDs

See Also

ElectronicsDSPFPGA

Find us on Facebook





Discussion Groups | Comp.Arch.Embedded | Re: Stack growth towards high addresses?

There are 9 messages in this thread.

You are currently looking at messages 1 to 9.


So far in July, you have voted 0 times ou of a total of 0 votes by the community.
Please help us clean the archives from unuseful discussion threads by using the voting system! Details here.

Re: Stack growth towards high addresses? - larwe - 2007-03-23 11:52:00

On Mar 23, 12:41 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> What CPUs, except x51, do have the direction of the stack growth from
> low to high addresses?

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.



Re: Stack growth towards high addresses? - Vladimir Vassilevsky - 2007-03-23 12:10:00


larwe wrote:


>>What CPUs, except x51, do have the direction of the stack growth from
>>low to high addresses?
> 
> 
> 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.

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



Stack growth towards high addresses? - Vladimir Vassilevsky - 2007-03-23 12:30:00

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

VLV



Re: Stack growth towards high addresses? - Ken Asbury - 2007-03-23 12:51:00

On Mar 23, 12:10 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:
> larwe wrote:
> >>What CPUs, except x51, do have the direction of the stack growth from
> >>low to high addresses?
>
> > 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.
>
> My beliefs are the code portability and the independence from the
> underlying hardware.

To quote my favorite philosopher, "Everybody should believe
in something and I believe that I'll have another drink."

>
> 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?
>

Seems to me that larwe answered very adequately
so I'm at a loss as to why you would ask it again.

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

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.

> Vladimir Vassilevsky
>
> DSP and Mixed Signal Design Consultant
>
> http://www.abvolt.com


Ken Asbury


Re: Stack growth towards high addresses? - larwe - 2007-03-23 13:00:00

On Mar 23, 12:10 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:

> 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?

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.

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

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.


Re: Stack growth towards high addresses? - msg - 2007-03-23 14:06:00

On Mar 23, 12:10 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
wrote:

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

 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

Re: Stack growth towards high addresses? - Vladimir Vassilevsky - 2007-03-23 14:58:00


larwe wrote:


>>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?
> 
> 
> Well, this is a semantic question; what, exactly, is "significant"?


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.


> There are relatively few architectures that have a hardware-enforced
> "directionness" that makes the stack grow up. 

I can't recall any except x51, that's why I am addressing the question 
to the club.

> 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.

Ditto.

> This issue has been dealt with extensively by the porters of Linux to
> eldritch architectures.

And what conclusion did they came to?

VLV



Re: Stack growth towards high addresses? - larwe - 2007-03-23 15:14:00

On Mar 23, 2:58 pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com>
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

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?

> 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.

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.

> > 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.
>
> Ditto.

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.

> > This issue has been dealt with extensively by the porters of Linux > > eldritch architectures.
>
> And what conclusion did they came to?

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).



Re: Stack growth towards high addresses? - Grant Edwards - 2007-03-23 15:16:00

On 2007-03-23, Vladimir Vassilevsky <a...@hotmail.com> wrote:

>>>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?
>> 
>> Well, this is a semantic question; what, exactly, is "significant"?
>
> 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.

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                   grante             Yow!  Now that we're
                                  at               in LOVE, you can BUY
                               visi.com            this GOLDFISH for a 48%
                                                   DISCOUNT.