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

From:	CBFalconer
Subject:	Re: Processors who's stack grows up
Date:	Tue, 04 Jan 2005 21:26:40 GMT

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.
USE worldnet address!

From:	Dave Thompson
Subject:	Re: Processors who's stack grows up
Date:	Mon, 10 Jan 2005 03:35:45 GMT

On Tue, 04 Jan 2005 21:26:40 GMT, CBFalconer
wrote:

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

And, for completeness, an architecture that was if not quite descended
from at least inspired by the HP 3000, Tandem^WCompaq^WHP NonStop,
which was still built and sold as recently as IIRC 1992, and userland
software for which is still supported in emulation on the successor
TNS/R systems since Tandem shops tend to be very slow to change their
business-critical applications. But the OS now is all 'native' MIPS
with downward stack, and even in the days of TNS hardware no one with
sense would have bought it to run a non-Tandem OS and throw away the
fault-tolerance and support features they paid a hefty premium for.

Also, equally irrelevantly, the PDP-10 doesn't have any "hardware"
stack for interrupts, but can use any GPR (except R0? I forget) as a
pointer to an upward-growing and (optionally) length-checked stack.
According to the folks in alt.sys.pdp10 there are actually a few clone
hardware systems still in use, as well as rather more folks using
(several) emulators, but again those systems are kept in existence
(only) to run old software and they wouldn't want to run Nucleus.

- David.Thompson1 at worldnet.att.net

From:	Robert Kaiser
Subject:	Re: Processors who's stack grows up
Date:	7 Jan 2005 13:32:13 GMT

In article <41dabc9a$1@solnews.wv.mentorg.com>,
"Adam Messer" writes:
> 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 MIPS processor doesn't really have a notion of a stack (and I
suspect this applies to some other RISC architectures as well).
It is up to the compiler to implement a stack and so a compiler
writer can choose to let the stack grow up or down. However, I'm not
aware of any MIPS compilers that actually let the stack grow up.

Rob

--
Robert Kaiser email: rkaiser AT sysgo DOT com
SYSGO AG http://www.elinos.com
Klein-Winternheim / Germany http://www.sysgo.com

From:	Andrew Reilly
Subject:	Re: Processors who's stack grows up
Date:	Sat, 08 Jan 2005 10:41:59 +1100

On Fri, 07 Jan 2005 14:32:13 +0000, Robert Kaiser wrote:

> In article <41dabc9a$1@solnews.wv.mentorg.com>,
> "Adam Messer" writes:
>> 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 MIPS processor doesn't really have a notion of a stack (and I
> suspect this applies to some other RISC architectures as well).
> It is up to the compiler to implement a stack and so a compiler
> writer can choose to let the stack grow up or down. However, I'm not
> aware of any MIPS compilers that actually let the stack grow up.

I've never used one, but I believe that the normal convention for
HP-PA under HP-UX is for stacks to grow upwards.

--
Andrew

From:	Heinz Saathoff
Subject:	Re: Processors who's stack grows up
Date:	Mon, 10 Jan 2005 11:00:28 +0100

Hello,

Robert Kaiser wrote...
> The MIPS processor doesn't really have a notion of a stack (and I
> suspect this applies to some other RISC architectures as well).
> It is up to the compiler to implement a stack and so a compiler
> writer can choose to let the stack grow up or down.

If the MIPS doen't have a notion of a stack, do they have call/ret
instructions? What about interrupts? The interrupted location must be
saved somewhere.

- Heinz

From:	Nicholas O. Lindan
Subject:	Re: Processors who's stack grows up
Date:	Mon, 10 Jan 2005 21:51:37 GMT

"Heinz Saathoff" wrote
> Robert Kaiser wrote...
> > The MIPS processor doesn't really have a notion of a stack (and I
> > suspect this applies to some other RISC architectures as well).
> If the MIPS doen't have a notion of a stack, do they have call/ret
> instructions? What about interrupts? The interrupted location must be
> saved somewhere.

They get younger every year ...

http://www.cs.clemson.edu/~mark/subroutines.html

The stack, as in "SP->memory", in a non-Burroughs* machine
(see below) is a recent circa 1970 creation.

The traditional method (like we got traditions in computer design)
of returning from subroutines was by forming a linked list. Sometimes
by such subtle methods as writing a JMP instruction to the caller's
"return-to" address at the end of the called subroutine - remember
all code was in core ("RAM" for the young'ns) - this method is
not recommended for recursion.

IBM (?) came up with the idea of linking registers rather than
using code modification when subroutines are called.

Register linkage re-appeared in the TI-9900 micro (others?) and some
modern primitive instruction set micros as MIPS (above).

* The early Burroughs machines are a must see:

http://www.cs.virginia.edu/brochure/images/manuals/b5000/descrip/descrip.html

A machine designed to run Algol, c. 1958.

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

From:	Heinz Saathoff
Subject:	Re: Processors who's stack grows up
Date:	Tue, 11 Jan 2005 13:42:57 +0100

Nicholas O. Lindan wrote...
> "Heinz Saathoff" wrote
> > If the MIPS doen't have a notion of a stack, do they have call/ret
> > instructions? What about interrupts? The interrupted location must be
> > saved somewhere.
>
> They get younger every year ...

Or you get older every year ;-)

> http://www.cs.clemson.edu/~mark/subroutines.html
>
> The stack, as in "SP->memory", in a non-Burroughs* machine
> (see below) is a recent circa 1970 creation.

Yes, I'm too young to know that (was 10 years old that year).
Thank's for this historic infos.

- Heinz

From:	Tauno Voipio
Subject:	Re: Processors who's stack grows up
Date:	Mon, 10 Jan 2005 11:31:25 GMT

Heinz Saathoff wrote:
> Hello,
>
> Robert Kaiser wrote...
>
>>The MIPS processor doesn't really have a notion of a stack (and I
>>suspect this applies to some other RISC architectures as well).
>>It is up to the compiler to implement a stack and so a compiler
>>writer can choose to let the stack grow up or down.
>
>
> If the MIPS doen't have a notion of a stack, do they have call/ret
> instructions? What about interrupts? The interrupted location must be
> saved somewhere.
>

In RISC processors it is a common method to have
special registers which save the interrupted state,
including the return location.

As an example, in ARM processors there are saved
PSR and exception state link registers to save
the previous processor status and return location.

The interrupt handler software may decide to still
save the state into a stack, but it is then entirely
managed by the software handler.

--

Tauno Voipio
tauno voipio (at) iki fi

From:	www.FreeRTOS.org
Subject:	Re: Processors who's stack grows up
Date:	Tue, 04 Jan 2005 16:55:53 GMT

"Adam Messer" 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
>
>

PIC and 8051 I think. Don't suppose you are interested in these those.

Regards,
Richard.

http://www.FreeRTOS.org

From:	Adam Messer
Subject:	Re: Processors who's stack grows up
Date:	Thu, 06 Jan 2005 01:45:17 GMT

Richard,

You are correct. We don't do 8-bits anyway, but thanks for the input!

Adam

"www.FreeRTOS.org" wrote in message
news:tUzCd.42971$48.1879@fe1.news.blueyonder.co.uk...
>
> "Adam Messer" 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
>>
>>
>
> PIC and 8051 I think. Don't suppose you are interested in these those.
>
> Regards,
> Richard.
>
> http://www.FreeRTOS.org
>
>

From:	Wouter van Ooijen (www.voti.nl
Subject:	Re: Processors who's stack grows up
Date:	Thu, 06 Jan 2005 16:09:22 GMT

>PIC and 8051 I think. Don't suppose you are interested in these those.

PICs (at least the 12-bit and 14-bit cores) don't have a memory-mapped
stack, so whether they grow up or down is invisible and hence
irrelevant.

Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics

From:	www.FreeRTOS.org
Subject:	Re: Processors who's stack grows up
Date:	Thu, 06 Jan 2005 16:17:27 GMT

"Wouter van Ooijen (www.voti.nl)" wrote in message
news:41dd6283.156976680@news.xs4all.nl...
> >PIC and 8051 I think. Don't suppose you are interested in these those.
>
> PICs (at least the 12-bit and 14-bit cores) don't have a memory-mapped
> stack, so whether they grow up or down is invisible and hence
> irrelevant.
>

The Microchip PIC18 C compiler uses the POSTINC/POSTDEC registers to effect
a stack and frame.

Regards,

http://www.FreeRTOS.org

From:	Dick Wesseling
Subject:	Re: Processors who's stack grows up
Date:	Mon, 17 Jan 2005 02:29:44 -0000

In article <7KwGd.698$Rs.117@newsread3.news.atl.earthlink.net>,
"Nicholas O. Lindan" writes:
> "Dick Wesseling" wrote
>> "Nicholas O. Lindan" writes:
>> >
>> > by such subtle methods as writing a JMP instruction to the caller's
>> > "return-to" address at the end of the called subroutine -
>>
>> That would require the caller to know the end of the subroutine.
>
> And? The caller has to know the entry point, yah? Knowing the
> exit point is somehow interdict?

I figure that having to know both the entry point and the exit
point is twice as much work as having to know the entry point
only, but ...

>> You are probably referring to the CDC.
>
> No, I am not. Why, because as you so state:
>
>> [A CDC mainframe] would write a jump back
>> to the caller at the *first* word of the callee and begin execution
>> at the 2nd word
>
> This was an improvement, for modern day dilettantes.

... I stand corrected

From:	Georgi Beloev
Subject:	Re: Processors who's stack grows up
Date:	Tue, 04 Jan 2005 09:25:59 -0800

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

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

From:	Tauno Voipio
Subject:	Re: Processors who's stack grows up
Date:	Tue, 04 Jan 2005 18:08:50 GMT

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

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

From:	Adam Messer
Subject:	Re: Processors who's stack grows up
Date:	Thu, 06 Jan 2005 01:46:16 GMT

Georgi,

Thanks for the input!

Adam

"Georgi Beloev" wrote in message
news:ztudncoe188mTEfcRVn-rg@megapath.net...
> Adam Messer wrote:
>> 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
>>
>>
>
> 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

From:	Jack Klein
Subject:	Re: Processors who's stack grows up
Date:	Tue, 04 Jan 2005 22:44:13 -0600

On Tue, 4 Jan 2005 09:56:09 -0600, "Adam Messer"
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

From:	Robert Kaiser
Subject:	Re: Processors who's stack grows up
Date:	7 Jan 2005 13:07:42 GMT

In article <1105005503.c2e7c4d716c50ca8103adc1a6645169f@teranews>,
Anton Erasmus writes:
> On 5 Jan 2005 20:29:28 GMT, Al wrote:
>
> [Snipped]
>>
>>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.
>
> [Snipped]
>
> Regarding the point above. Normally when using a preprocessor to strip
> out the conditional code. It expands everything. Is there an option or
> other tool that will only strip out the conditionals ?
>

I'm using a tool called 'preparser' which comes from the isdn4linux
community, see:

http://www.isdn4linux.de/cgi-bin/viewcvs.cgi/isdn/README.preparser?rev=HEAD

Apparently the sourcecode is not online, but the author says he'll send
it upon request.

Rob

--
Robert Kaiser email: rkaiser AT sysgo DOT com
SYSGO AG http://www.elinos.com
Klein-Winternheim / Germany http://www.sysgo.com

From:	Adam Messer
Subject:	Re: Processors who's stack grows up
Date:	Tue, 4 Jan 2005 13:32:11 -0600

Hello,

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

Adam

"Adam Messer" 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
>
>

From:	Ben Jackson
Subject:	Re: Processors who's stack grows up
Date:	Tue, 04 Jan 2005 20:06:06 GMT

In article <41dabc9a$1@solnews.wv.mentorg.com>,
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.

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

http://www.ben.com/

From:	Ulf Samuelsson
Subject:	Re: Processors who's stack grows up
Date:	Tue, 4 Jan 2005 21:56:51 +0100

> 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
>
Hi Adam,
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

From:	Dick Wesseling
Subject:	Re: Processors who's stack grows up
Date:	Mon, 17 Jan 2005 02:32:36 -0000

In article <41e9df9b$0$82339$a1866201@visi.com>,
Grant Edwards writes:
>
> I remember that from the days not so long ago when the UofMinn
> used to torture students by making them program on a 6600. I
> always wondered how one did recursion or re-entrancy on a 6600,

That was done in software. The prelude of the called function would
save the value written by the return jump on the (software) stack.

From:	Dick Wesseling
Subject:	Re: Processors who's stack grows up
Date:	Sun, 16 Jan 2005 03:23:32 -0000

In article ,
"Nicholas O. Lindan" writes:
>
> The traditional method (like we got traditions in computer design)
> of returning from subroutines was by forming a linked list. Sometimes
> by such subtle methods as writing a JMP instruction to the caller's
> "return-to" address at the end of the called subroutine -

That would require the caller to know the end of the subroutine.

You are probably referring to the CDC. It would write a jump back
to the caller at the *first* word of the callee and begin execution
at the 2nd word.

From:	Grant Edwards
Subject:	Re: Processors who's stack grows up
Date:	16 Jan 2005 03:29:31 GMT

On 2005-01-16, Dick Wesseling wrote:

>> The traditional method (like we got traditions in computer design)
>> of returning from subroutines was by forming a linked list. Sometimes
>> by such subtle methods as writing a JMP instruction to the caller's
>> "return-to" address at the end of the called subroutine -
>
> That would require the caller to know the end of the subroutine.
>
> You are probably referring to the CDC. It would write a jump back
> to the caller at the *first* word of the callee and begin execution
> at the 2nd word.

I remember that from the days not so long ago when the UofMinn
used to torture students by making them program on a 6600. I
always wondered how one did recursion or re-entrancy on a 6600,
but the professor who taught that class wasn't really up on
modern stuff like that. He had also never heard of passing
parameters by value.

--
Grant Edwards grante Yow! YOW!! The land of the
at rising SONY!!
visi.com

From:	Jim Stewart
Subject:	Re: Processors who's stack grows up
Date:	Sat, 15 Jan 2005 19:27:22 -0800

Dick Wesseling wrote:
> In article ,
> "Nicholas O. Lindan" writes:
>
>>The traditional method (like we got traditions in computer design)
>>of returning from subroutines was by forming a linked list. Sometimes
>>by such subtle methods as writing a JMP instruction to the caller's
>>"return-to" address at the end of the called subroutine -
>
>
> That would require the caller to know the end of the subroutine.
>
> You are probably referring to the CDC. It would write a jump back
> to the caller at the *first* word of the callee and begin execution
> at the 2nd word.

I believe a pdp 8 did the same thing. The
return was an indirect jump to the first word.

From:	Simon Wright
Subject:	Re: Processors who's stack grows up
Date:	16 Jan 2005 19:01:06 +0000

Jim Stewart writes:

> I believe a pdp 8 did the same thing. The return was an indirect
> jump to the first word.

Yes,

SUBR: +0
...
JMP I SUBR

(we only had ASR33s, no idea if PAL III would have accepted lower
case!)

--
Simon Wright 100% Ada, no bugs.

From:	Nicholas O. Lindan
Subject:	Re: Processors who's stack grows up
Date:	Sun, 16 Jan 2005 16:36:19 GMT

"Dick Wesseling" wrote
> "Nicholas O. Lindan" writes:
> >
> > by such subtle methods as writing a JMP instruction to the caller's
> > "return-to" address at the end of the called subroutine -
>
> That would require the caller to know the end of the subroutine.

And? The caller has to know the entry point, yah? Knowing the
exit point is somehow interdict?

> You are probably referring to the CDC.

No, I am not. Why, because as you so state:

> [A CDC mainframe] would write a jump back
> to the caller at the *first* word of the callee and begin execution
> at the 2nd word

This was an improvement, for modern day dilettantes.

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

From:	Nicholas O. Lindan
Subject:	Re: Processors who's stack grows up
Date:	Sun, 16 Jan 2005 20:41:34 GMT

"Dick Wesseling" wrote:
> "Nicholas O. Lindan" writes:
> >
> > The

"A traditional ..." would have been a better choice of words.

> > traditional method (like we got traditions in computer design)
> > of returning from subroutines was by forming a linked list. Sometimes
> > by such subtle methods as writing a JMP instruction to the caller's
> > "return-to" address at the end of the called subroutine -
>
> That would require the caller to know the end of the subroutine.
>
> You are probably referring to the CDC. It would write a jump back
> to the caller at the *first* word of the callee and begin execution
> at the 2nd word.

I should not these methods are all software implementations. Where
the return address and parameters are stored in older [and some newer]
machines is a matter of software convention.

Whirlwind, CDC, PDP-8 ... methods can be used on [almost] any processor.
PPP [People who Program Pics] know of even more bizarre methods.

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

From:	Tauno Voipio
Subject:	Re: Processors who's stack grows up
Date:	Sun, 16 Jan 2005 21:29:17 GMT

Nicholas O. Lindan wrote:
>
> Whirlwind, CDC, PDP-8 ... methods can be used on [almost] any processor.
> PPP [People who Program Pics] know of even more bizarre methods.
>

Plenty of the PIC bizarrities are directly from the minis
of the sixties: PDP-8, HP-2116, Honeywell DDP-312 and
DDP-516 & co.

----

The method of storing the return address at the
subroutine entry location and starting the execution
at the next instruction was an industry standard
in the minis of those times. The notable exceptions
were Data General Nova and Digital PDP-11 which
stored the return address in a register.

--

Tauno Voipio
tauno voipio (at) iki fi

From:	mc
Subject:	Re: Processors who's stack grows up
Date:	Sun, 16 Jan 2005 16:56:34 -0500

"Tauno Voipio" wrote in message
news:N0BGd.698$ar4.124@read3.inet.fi...

> The method of storing the return address at the
> subroutine entry location and starting the execution
> at the next instruction was an industry standard
> in the minis of those times. The notable exceptions
> were Data General Nova and Digital PDP-11 which
> stored the return address in a register.

Interesting. I knew of the Control Data XJ (Exchange Jump).

In those days there was almost no recursion. As recently as 1980, recursion
was an "advanced" technique that ordinary programmers weren't expected to
master.

From:	Paul Keinanen
Subject:	Re: Processors who's stack grows up
Date:	Wed, 19 Jan 2005 10:34:30 +0200

On Sun, 16 Jan 2005 16:56:34 -0500, "mc" wrote:

>"Tauno Voipio" wrote in message
>news:N0BGd.698$ar4.124@read3.inet.fi...
>
>> The method of storing the return address at the
>> subroutine entry location and starting the execution
>> at the next instruction was an industry standard
>> in the minis of those times. The notable exceptions
>> were Data General Nova and Digital PDP-11 which
>> stored the return address in a register.

While it is technically correct to say that PDP-11 stored in the
return address in a register and it was also used extensively in some
older code when using R0 .. R5 as the link register, in which case it
was easy to use the link register to access the in-line parameters.
However, some compiler generated code pushed the parameters on the SP
stack and then called the subroutine, using the PC as the link
register, which effectively pushed the return address on top of the
stack, thus creating a pure stack architecture.

>Interesting. I knew of the Control Data XJ (Exchange Jump).
>
>In those days there was almost no recursion. As recently as 1980, recursion
>was an "advanced" technique that ordinary programmers weren't expected to
>master.

IMHO, recursion is highly overrated, some people even want to convert
a simple loop to a recursion :-).

Languages which were commonly used in 1960/70, such as Cobol and
Fortran did not even support recursion. This caused some problems in
some very rare cases .e.g. when evaluating complex arithmetic
expressions with complex function parameter list, but it is
definitively doable, while of course this would be easier to do with
recursion.

In high reliability systems (which are often discussed in these
newsgroups), it is not acceptable that the thread/process stack would
_ever_ overflow. If recursion is used on such systems, there must be a
well defined absolute maximum number of recursions that can occur, in
order to fit into the allocated stack.

For instance walking through a binary tree with a recursive routine is
nice, but what if the binary tree is due to the creation order
actually a simple linear linked list, then the levels of recursions is
the same as the number of elements in the linked list. With a large
stack frame in the recursive routine, the stack size requirement can
be larger than the size of the linked list.

Thus, in order to use a recursive binary tree routine, some
precautions must be done to reorganise (balance) the tree to avoid
such pathological cases as the binary tree becoming a linear linked
list, before calling the recursive binary tree walker routine.

Paul

From:	Everett M. Greene
Subject:	Re: Processors who's stack grows up
Date:	Wed, 19 Jan 2005 09:27:34 PST

Paul Keinanen writes:
> On Sun, 16 Jan 2005 16:56:34 -0500, "mc" wrote:
> >Interesting. I knew of the Control Data XJ (Exchange Jump).
> >
> >In those days there was almost no recursion. As recently as 1980, recursion
> >was an "advanced" technique that ordinary programmers weren't expected to
> >master.
>
> IMHO, recursion is highly overrated, some people even want to convert
> a simple loop to a recursion :-).
>
> Languages which were commonly used in 1960/70, such as Cobol and
> Fortran did not even support recursion. This caused some problems in
> some very rare cases .e.g. when evaluating complex arithmetic
> expressions with complex function parameter list, but it is
> definitively doable, while of course this would be easier to do with
> recursion.

Fortran not supporting recursion is an industry myth
probably a side-effect of early implementation techniques.
There is nothing in the ANSI Fortran standard which
precludes a stack-oriented implementation thus allowing
recursion.

From:	Paul Keinanen
Subject:	Re: Processors who's stack grows up
Date:	Thu, 20 Jan 2005 10:08:31 +0200

On Wed, 19 Jan 2005 09:27:34 PST, mojaveg@mojaveg.iwvisp.com (Everett
M. Greene) wrote:

>Fortran not supporting recursion is an industry myth
>probably a side-effect of early implementation techniques.
>There is nothing in the ANSI Fortran standard

That may be the case with Fortran 77 and later versions, but I was
referring to Fortran II and Fortran IV.

>which
>precludes a stack-oriented implementation thus allowing
>recursion.

If you put the local variables into a stack, it would break quite a
lot old Fortran programs (including some widely used library code)
that assume that the local variable values are maintained between
calls.

Paul

From:	Everett M. Greene
Subject:	Re: Processors who's stack grows up
Date:	Thu, 20 Jan 2005 11:41:38 PST

Paul Keinanen writes:
>mojaveg@mojaveg.iwvisp.com (Everett M. Greene) wrote:
>
> >Fortran not supporting recursion is an industry myth
> >probably a side-effect of early implementation techniques.
> >There is nothing in the ANSI Fortran standard
>
> That may be the case with Fortran 77 and later versions, but I was
> referring to Fortran II and Fortran IV.
>
> >which
> >precludes a stack-oriented implementation thus allowing
> >recursion.
>
> If you put the local variables into a stack, it would break quite a
> lot old Fortran programs (including some widely used library code)
> that assume that the local variable values are maintained between
> calls.

I just said the standard doesn't preclude reentrancy.

Since the standard doesn't define the behavior, different
programs written for different implementations may rely on
the behavior of a particular implementation.

From:	Pat Ford
Subject:	Re: Processors who's stack grows up
Date:	Wed, 19 Jan 2005 13:12:49 -0500

"Everett M. Greene" wrote in message
news:20050119.79EFC40.8B9E@mojaveg.iwvisp.com...
> Paul Keinanen writes:
> > On Sun, 16 Jan 2005 16:56:34 -0500, "mc" wrote:
> > >Interesting. I knew of the Control Data XJ (Exchange Jump).
> > >
> > >In those days there was almost no recursion. As recently as 1980,
recursion
> > >was an "advanced" technique that ordinary programmers weren't expected
to
> > >master.
> >
> > IMHO, recursion is highly overrated, some people even want to convert
> > a simple loop to a recursion :-).
> >
> > Languages which were commonly used in 1960/70, such as Cobol and
> > Fortran did not even support recursion. This caused some problems in
> > some very rare cases .e.g. when evaluating complex arithmetic
> > expressions with complex function parameter list, but it is
> > definitively doable, while of course this would be easier to do with
> > recursion.
>
> Fortran not supporting recursion is an industry myth
> probably a side-effect of early implementation techniques.
> There is nothing in the ANSI Fortran standard which
> precludes a stack-oriented implementation thus allowing
> recursion.

I just proted a compile and virtual machine write in fortran in the early
70's that ran on a PDP11. both the compiler and the virtual machine handled
recursion.
Pat

From:	Hans-Bernhard Broeker
Subject:	Re: Processors who's stack grows up
Date:	19 Jan 2005 18:32:41 GMT

In comp.arch.embedded Everett M. Greene wrote:

> Fortran not supporting recursion is an industry myth probably a
> side-effect of early implementation techniques. There is nothing in
> the ANSI Fortran standard which precludes a stack-oriented
> implementation thus allowing recursion.

You're missing the point, I think. The fact that the Fortran standard
doesn't preclude a stack-based implementation allowing allow
recursion, by no means implies that Fortran "supports recursion". To
back up a claim that Fortran (as such, rather than a particular
implementation) supported recursion, the language standard would have
to *enforce* that it's possible. I'm quite sure it doesn't

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

From:	Grant Edwards
Subject:	Re: Processors who's stack grows up
Date:	19 Jan 2005 18:02:49 GMT

On 2005-01-19, Everett M. Greene wrote:

>>>In those days there was almost no recursion. As recently as
>>>1980, recursion was an "advanced" technique that ordinary
>>>programmers weren't expected to master.
>>
>> IMHO, recursion is highly overrated, some people even want to
>> convert a simple loop to a recursion :-).

Recursion aside, it's re-entrancy that really matters. I
suppose if the OS doesn't support multiple processes, then that
doesn't matter either.

--
Grant Edwards grante Yow! It's OKAY -- I'm an
at INTELLECTUAL, too.
visi.com

From:	Neo
Subject:	Re: Processors who's stack grows up
Date:	Wed, 5 Jan 2005 09:49:39 +0530

"Adam Messer" 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

From:	Al
Subject:	Re: Processors who's stack grows up
Date:	4 Jan 2005 20:36:07 GMT

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

From:	Adam Messer
Subject:	Re: Processors who's stack grows up
Date:	Wed, 05 Jan 2005 16:07:32 GMT

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

From:	CBFalconer
Subject:	Re: Processors who's stack grows up
Date:	Wed, 05 Jan 2005 20:58:50 GMT

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.
USE worldnet address!

From:	Hans-Bernhard Broeker
Subject:	Re: Processors who's stack grows up
Date:	5 Jan 2005 20:55:33 GMT

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

In comp.arch.embedded Adam Messer 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.

From:	Al
Subject:	Re: Processors who's stack grows up
Date:	5 Jan 2005 20:29:28 GMT

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.

From:	Anton Erasmus
Subject:	Re: Processors who's stack grows up
Date:	Thu, 06 Jan 2005 12:02:42 +0200

On 5 Jan 2005 20:29:28 GMT, Al wrote:

[Snipped]
>
>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.

[Snipped]

Regarding the point above. Normally when using a preprocessor to strip
out the conditional code. It expands everything. Is there an option or
other tool that will only strip out the conditionals ?

Regards
Anton Erasmus

From:	Grant Edwards
Subject:	Re: Processors who's stack grows up
Date:	05 Jan 2005 16:27:22 GMT

On 2005-01-04, Al 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!!

From:	Al
Subject:	Re: Processors who's stack grows up
Date:	5 Jan 2005 20:34:57 GMT

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

From:	Grant Edwards
Subject:	Re: Processors who's stack grows up
Date:	05 Jan 2005 21:13:29 GMT

On 2005-01-05, Al wrote:

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

Not relevent.

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

That's an unrealistic expection.

--
Grant Edwards grante Yow! I want another
at RE-WRITE on my CEASAR
visi.com SALAD!!

From:	Alex Colvin
Subject:	Re: Processors who's stack grows up
Date:	Thu, 6 Jan 2005 18:34:40 +0000 (UTC)

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

Such as my paper design for a balanced-ternary number system
reconfigurable array processor? Which is unlikely to ever exist.

--
mac the naïf

From:	Ulf Samuelsson
Subject:	Re: Processors who's stack grows up
Date:	Thu, 6 Jan 2005 07:12:56 +0100

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

If you want to product that always work , then you cannot select
a CPU where the stack grows up, so Nucleus will work for you anyway.
Thus no motivation to keep that code in Nucleus...

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

From:	Nicholas O. Lindan
Subject:	Re: Processors who's stack grows up
Date:	Tue, 04 Jan 2005 19:13:03 GMT

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

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/