Processors who's stack grows up

Adam Messer wrote:
> 
> 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.

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:
> Unbelievable! An RTOS ***MUST*** be stack-agnostic!!!!
>
> Shit, looks like I'll be pulling nucleus from a current project ...
>
> Unbelievable...

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

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:

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

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/~ajo/docs/FAQ-acllc.html

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...
> >I am the lead engineer on the Nucleus Plus RTOS.
>
> I've worked with Nucleus+ for many years, but I don't recall your name.
> Sorry!
>
> > asked me if I knew any processors that had a stack that grows up.
>
> There are plenty.
>
> > If
> > we can't find a reasonable number of processors who's stack does grow
> > up we will remove that code.
>
> Unbelievable! An RTOS ***MUST*** be stack-agnostic!!!!
>
> Shit, looks like I'll be pulling nucleus from a current project ...
>
> Unbelievable...
>
> Al.

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

>>I am the lead engineer on the Nucleus Plus RTOS.
>
> I've worked with Nucleus+ for many years, but I don't recall
> your name.  Sorry!
>
>> asked me if I knew any processors that had a stack that grows
>> up.
>
> There are plenty.

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

>> If we can't find a reasonable number of processors who's stack
>> does grow up we will remove that code.
>
> Unbelievable! An RTOS ***MUST*** be stack-agnostic!!!!

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

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

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

> Unbelievable...

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,

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

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!

> As far as we know
> no one has ever used the 'stack grows up' conditional.

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.

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

8051.

> Why?

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

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

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.

> You must be a real joy to
> work with.

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

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.

Adam Messer wrote:
> 
> 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.

I suspect you are making the feature harder than necessary.  Stacks
have very limited possible actions, such as push, pop, create,
destroy.  You may also want such things as generate stack address,
for accessing buried things.  If you can convert your main code to
these primitives, you can then worry about modifying them for stack
direction.  For OS use the primitives probably need to be
paramatized with such things as item size.  Procedure entry/exit is
another possible primitive.

Please do not top-post, it loses the entire sense of the thread. 
Simply snip the quoted portion not germane to your reply, which can
then be either intermixed or appended.

You realize, of course, that the first request for such a system
will appear approximately six months after removing the ability, or
whatever period is needed to make restoration a major problem.

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