Hello,

I am the lead engineer on the Nucleus Plus RTOS. One of my coworkers
asked me if I knew any processors that had a stack that grows up. The only
one I knew of, for sure, was the Intel i960. We have a fair amount of code
in our system that accommodates stacks that grow up. If we can't find a
reasonable number of processors who's stack does grow up we will remove that
code.

TIA,
Adam Messer
adam_messer@mentor.com

HP PA-RISC, not commonly used in embedded applications but it does
exist. Couldn't point you to a part that is still in production,
though.

i960 and PA-RISC are essentially dead architectures; if you don't find
a few architectures _with a future_ it probably won't hurt your market
share any to remove support for these devices.

"Adam Messer" <adam_messer@mentor.com> wrote in message
news:41dabc9a$1@solnews.wv.mentorg.com...
PIC and 8051 I think. Don't suppose you are interested in these those.

Regards,
Richard.

http://www.FreeRTOS.org

Adam Messer wrote:
On the ARM you can decrement or increment the stack pointer when loading
multiple registers - take a look at LDMIA, LDMIB, LDMDA, and LDMDB. I
don't know if any standard development environment uses the
stack-growing-up convention.

Regards,
-- Georgi

Georgi Beloev wrote:
In 32 bit mode ARM can handle the stack both ways.

There is another degreee of freedom: whether the stack
pointer points to the last used slot or the first free slot.

In 16 bit Thumb mode of the T variants (e.g. ARM7TDMI),
the stack is fixed to grow down.

--

Tauno Voipio
tauno voipio (at) iki fi

"Adam Messer" <adam_messer@mentor.com> wrote

8051 family

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

Hello,

To all who responded to the question, I say "Thank You"!

Adam

"Adam Messer" <adam_messer@mentor.com> wrote in message
news:41dabc9a$1@solnews.wv.mentorg.com...

In article <41dabc9a$1@solnews.wv.mentorg.com>,
Adam Messer <adam_messer@mentor.com> wrote:
I think the PPC is stack-direction-agnostic, though I may be forgetting
some corner case where the processor would care. There's no reason you'd
define your OS to use an ABI with a stack growing up if it was a problem
though.

--
Ben Jackson
<ben@ben.com>
http://www.ben.com/

I've worked with Nucleus+ for many years, but I don't recall your name.
Sorry!

There are plenty.

Unbelievable! An RTOS ***MUST*** be stack-agnostic!!!!

Shit, looks like I'll be pulling nucleus from a current project ...

Unbelievable...

Al.

Maybe You should ask your colleagues doing Microtec compilers...
An ARM compiler could be implemented that grew the stack upwards
but I have not seen an ARM used this way.

--
Best Regards,
Ulf Samuelsson ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB

Adam Messer wrote:
The HP3000.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Al wrote:
Al, I do believe you're an asshole.

Why not politely and reasonably argue your position? This guy is
asking nicely before he makes a decision, and you could choose to
respond in kind, rather than in the manner you did.

It seems to me that by convention, design or happenstance the world has
settled on a stack-grows-down philosophy. If you think that's flawed
in that processors you're selecting for current or future projects have
upward growning stacks (or the option of one, which you are actually
planning to use (i.e. is supported by compilers, etc)) then that is
useful (as opposed to academic) information that needs to be shared.
Good luck with that project.

Regards,
Paul.

"Adam Messer" <adam_messer@mentor.com> wrote in message
news:41dabc9a$1@solnews.wv.mentorg.com...
8051 and its derivaties...
-Neo

On Tue, 4 Jan 2005 09:56:09 -0600, "Adam Messer"
<adam_messer@mentor.com> wrote in comp.arch.embedded:

Some of TI's DSPs, such as the 2712 I am using right now, have a stack
that grows up, and can't be changed like ARM and some others can.

Whether or not there is a market for a general purpose RTOS for
products using parts like this is something you need to consider.
Personally, I'd guess not.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

8051

Al,

The only way to make an OS stack agnostic is to have some sort of
conditionals and/or macros every place where the stack must be accessed. One
of my coworkers is working on a project to put in an easier porting layer
(similar to a HAL or BSP). The code we have for 'stack grows up' makes the
affected modules much harder to read. We are trying to weigh the importance
of supporting those architectures with the all around readability of the
code. Since Nucleus Plus is a source level product, readability is very
important. As far as we know no one has ever used the 'stack grows up'
conditional.

Adam

"Al" <alnews67@hotmail.com> wrote in message
news:Xns95D4D192DA512alnews67hotmailcom@130.133.1. 4...

On 2005-01-04, Al <alnews67@hotmail.com> wrote:

Interesting that you can't actually name any...

Why? If no customer ever wants an upward growing stack, then
including stack agnosticism is nothing but a source of bugs and
increased cost.

For which the Necleus vendor will probably be grateful. Some
customers are a net loss.

Wow. Your reaction is what's unbelievable. He hasn't done
anything yet. He asks for customer input before making a
decision, and you rip him a new one. You must be a real joy to
work with.

If you really _use_ Nucleus on a processor with an
upwards-growing stack, then speak up. What processor, what
compiler?

I agree with the OP. If a feature costs a significant amount
of money and is used by 0% of the customer base, get rid of the
feature! We all win: fewer bugs, lower costs, better support.

--
Grant Edwards grante Yow! This PIZZA symbolizes
at my COMPLETE EMOTIONAL
visi.com RECOVERY!!

Hi Adam,

I've worked with Nucleus source code on many occasions and have had no
problems regarding readability :-) Conditionals can be easily stripped with
a preprocessor, so I don't generally worry.

Having said that, I *do* complain about code that ships with too many
conditionals, so you might have a fair point!

8051 and the numerous offshoots are 'up'. Seen a few oddball ones that are
'up' too, can't recall the details ATM.

The things I like about nucleus are:

It works very well
It's cheap
I get the source and can tune it
I can port it to any processor I like, and it will work
Oh, and it works very well!

Don't get me wrong, I love Nucleus. I just worry that sometime in the
future you'll have removed a feature that I need! :-)

Al.

8051.

Because I need it to work on any processor. *ANY* processor. Even those
that don't exist yet ;-)

Nucleus is pay-per-product, not pay-per-item-sold. Nucleus is cheap and
good. I really doubt that they have made a loss on the licences I've sold
to customers.

Not a joy. Just professional. I need products that work. Always. Nucleus
always did. I don't want it changed!

Al.

[F'up2 cut down --- should have been done by OP]

In comp.arch.embedded Adam Messer <amesser39@hotmail.com> wrote:
Right. So make sure such places are rare enough that this doesn't
hurt too badly.

IMHO, if this kind of access is made in so many places throughout the
source code that accounting for "the other" stack growth direction
becomes a noticeable maintenance burden, that's a symptom of a design
problem, rather than a reason to remove that feature.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.