Direction of Stack Growth

Hi,

Why some processors have stack growing downwards and others have stack growing upwards ? Any advantages/disadvantages w.r.t both these designs. Which is the best model ?

I serached the internet, but i did not find a good link that explains these stuffs in detail.

Thx in advans, Karthik Balaguru

Reply to
karthikbalaguru
Loading thread data ...

In the beginning, it was customary to start a peogram at or near the bottom of memory and start the return stack at or near the top. That allowed the largest amount of RAM for stack space. When there are two stacke, it is usual to make one grow down andthe other grow up and then to hope that they never meet.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

I don't think it makes a big difference one way or another. After a designer has decided where to vector the program counter on reset, and where to put the interrupt vector table, there may be some slight advantage.

But mostly I think the decision is arbitrary.

--
Tim Wescott
Control systems and communications consulting
 Click to see the full signature
Reply to
Tim Wescott

Tradition.

Not especially.

Your choice.

There are some processors that can't perform negative offset indexing in which case an upward-growing stack is awkward to program.

Reply to
Everett M. Greene

Obviously either works. One old trick for allocating a memory block between two different uses when you don't know the amount needed before hand is to start allocating one from the bottom of the block and start allocating the second from the top of the block and allow the two increasing blocks to grow towards each other. This allows total use of the memory block without knowing the individual sizes in advance.

Allocating the stack from the top down is sometimes used in conjunction with allocating heap storage from the bottom up within the same memory block.

--
Thad
Reply to
Thad Smith

The designers had different preferences.

Not really.

The one that's supported by your CPU. :)

--
Grant Edwards                   grante             Yow!  Yow! Are we wet yet?
                                  at               
 Click to see the full signature
Reply to
Grant Edwards

Beginning of what? The earliest computer I used that had hardware stack support was the PDP-6, designed circa 1963, and its stacks grew upwards. The B5000 which was designed around the same time or slightly earlier also had upward growing stacks.

I see two motivations for the switch in modern computers to stacks that grow downward. One was the use of programming techniques that used heap storage in a fixed address space, which made it attractive to have the heap and stack grow toward each other. (Back in the 60s memory was so valuable that you laid it all out when you wrote your program, and the stack was just one of the areas you laid out.)

The other is the influence of the IBM S/360. Its desigers didn't put in explicit stack hardware because they knew it was easy to do a stack in software if you have base and index registers. But its addressing modes have a 12 bit unsigned offset that is added to the base register. If a stack grows upward, a program either needs a frame register separate from the base register to address local variables, or else use extra instructions to simulate negative offsets. If the stack grows down, locals are at positive offsets from the stack pointer. Most (all?) modern computers have signed offsets so it'd work either way, but once you're used to a programming style, why mess with it?

Reply to
John L

Because they can.

Neither. If there were one that was "the best", just like that, the other would probably no longer be around.

Reply to
Hans-Bernhard Bröker

My experience (which dates from about 1978) supports your observations and Jerry's original explanation.

--
%  Randy Yates                  % "Remember the good old 1980's, when 
%% Fuquay-Varina, NC            %  things were so uncomplicated?"
 Click to see the full signature
Reply to
Randy Yates

(snip)

I thought of that, but I didn't see why programs couldn't load at the top and the stack grow from the bottom. I suppose, though, that it helps not to need to do relocation, if the load point is always the same.

This is all without virtual storage (dynamic address translation), and a single task (no need to leave memory for anyone else).

-- glen

Reply to
glen herrmannsfeldt

In article , snipped-for-privacy@iecc.com (John L) writes: |> |> The other is the influence of the IBM S/360. Its desigers didn't put |> in explicit stack hardware because they knew it was easy to do a stack |> in software if you have base and index registers. But its addressing |> modes have a 12 bit unsigned offset that is added to the base |> register. If a stack grows upward, a program either needs a frame |> register separate from the base register to address local variables, |> or else use extra instructions to simulate negative offsets. If the |> stack grows down, locals are at positive offsets from the stack |> pointer. Most (all?) modern computers have signed offsets so it'd |> work either way, but once you're used to a programming style, why |> mess with it?

Actually, handling upwards-growing stacks on the System/360 was as easy as downwards-growing ones, and you DON'T need a separate frame pointer for most languages - but that doesn't deny your point.

I lost track of the number of people I tried to explain the major methods of doing it to, generally unsuccessfully. There was definitely a belief (i.e. myth) that upwards-growing ones were inefficient or even impossible and, as always, pointing out counter- examples and explaining the techniques didn't kill the myth.

Regards, Nick Maclaren.

Reply to
Nick Maclaren

I don't see how that results in a preference for a downward growing stack. It just means that the heap and stack need to grow in opposite directions -- it doesn't matter which grows up and which grows down.

--
Grant Edwards                   grante             Yow! Please come home with
                                  at               me ... I have Tylenol!!
 Click to see the full signature
Reply to
Grant Edwards

That would work equally as well.

--
Grant Edwards                   grante             Yow! Are we THERE yet?
                                  at               My MIND is a SUBMARINE!!
 Click to see the full signature
Reply to
Grant Edwards

karthikbalaguru schrieb:

With downwards growing stacks you can address the "top" element of the stack at address sp + 0 and this results often in smaller opodes of the machine-instructions adressing that elements. With upwards growing stacks you either would have to know the size of the top element when pushing another element to the stack or you would have to address the top element at sp - N, you you couldn't address it with an offset-less instruction. So it's best to grow stack downwards: you can address the "top" element without an offset and you don't have to know its size to push another element on the stack.

Reply to
Elcaro Nosille

I agree with others that the direction does not matter. You can prove this if you take your preferred scheme (up or down) and invert the address bits. An 'up' scheme becomes a 'down' scheme and vice versa, but nothing else changes. It still works as well.

Regards, John

Reply to
John Monro

If you don't do relocation, and machines come with different amounts of memory all starting at zero, then it is convenient to load programs near the bottom of memory.

Note, though, that the 8080 starts with the PC at 0, while the 8086 (and other x86 machines) start near the top. The interrupt vectors for real mode x86 start at 0, though.

For an 8080 system with ROM at high addresses and RAM at low addresses, starting with the PC at zero was not convenient. The solution was special logic to map ROM at 0 for the first few clock cycles, long enough to jump to a higher address.

With x86 and segment registers, there isn't such a big advantage to starting at low memory, but x86 was designed to maintain 8080 source compatibility. (You could reassemble 8080 assembly code to run on an 8086.)

It might be that the 8080 got its decrementing stack from the PDP-11, and later microprocessors from the 8080.

-- glen

Reply to
glen herrmannsfeldt

Wouldn't it be just as easy to have SP point at the current "top", using pre-increment and post-decrement addressing?

-- glen

Reply to
glen herrmannsfeldt

How about some attribution? I see posts in date order -- my thread mechanism is temporarily kaput -- and If I hadn't recognized my deathless prose, I would have been boorishly unresponsive.

In the beginning of the microprocessor revolution, when the more prescient among us recognized that front-panel switches on computers would not be around for long, and that the PC would have to preload at powerup.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

Programs must start low if the program counter is to count up.

Yes. Computers were like that once.

...

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

I still think that the simple answer is that program counters count up by design. My first useful computer had 1K of RAM, quickly augmented to

  1. My first disk-based system had 24K. With such systems, it's convenient to start the stack at the top of memory and let it work down.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.