Re: the stack


"Phil Carmody" <thefatphil_demunged@xxxxxxxxxxx> wrote in message
news:87d4snm340.fsf@xxxxxxxxxxxxxxxxxxxxxxx
"Rod Pemberton" <do_not_have@xxxxxxxxxxxxx> writes:
<bob@xxxxxxxxxxxxxx> wrote in message

news:f45b4608-fafa-4fd3-b73d-d34d84e4287d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I was just wondering why the stack grows downwards on x86 processors.


The short answer: it was designed that way.

The 8086 was compatible with the 8080. Stanley Mazor of the 8080 design
team designed the 8080 stack that way:

"Deleting the on-chip stack saved chip area, but was a net advantage to
the
user -now the stack had unlimited size. I defined the stack as growing
downward from the high end of memory; this facilitated indexing into the
stack and simplified displaying the stack. This was abandoned on the
8086."
http://www.xnumber.com/xnumber/Microcomputer_invention.htm

By "abandoned ...," I think he means the stack was put back on-chip for
the
8086.

Or does he mean that it being stuck at the high end of memory
was abandoned, as it could now reside in arbitrary locations?


That was my first thought: that the stack was SP based on x86 and not fixed
to top of memory (which I'm assuming from his statement since I don't know
much about the 8080... Altair's and Imsai's were a couple of years before I
got into computers.). But, after a reread, I said "What, that doesn't make
too much sense... Why would he mention something trivial and irrelevent
like the stack being at the top of memory being 'abandoned'? Using the word
'abandoned' would be overkill. Now, if he was talking about testing out
ideas in silicon..." The rest of the article indicated most of their
changes were intended to give a 10x speedup. So, the smallest contributors
to performance lost on-chip silicon. I suspect the designers found an in
memory stack with the 8080 to be an order of magnitude slower than an on
chip stack considering the memory speeds (500ns or slower) of the era. The
6502 (a year and a half or so after the 8080) was the first microprocessor
with a pipeline (not CPU - apparently the Cray CDC 6600) so it probably
wasn't much more than one order of magnitude. Anyway, I'd assume that once
the designers had more silicon work with, they put it back on the silicon.
I'd have to do some research to find out for sure, but it's a highly
plausible assumption to me...


Rod Pemberton

.

Relevant Pages

  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: Maybe we should stop "Paging Beth Stone" already...
    ... I'll want to work on my OS while running my OS, so the assembler that it's written with has to run under it. ... You have to swap CR3 if you want seperate memory spaces. ... The alternate stacks aren't used by the processor unless the task calls a different protection level, so they're not part of the TSS swap. ... This lets any application use up to a gigabyte of stack before Linux is forced to tell it that it's gone too far. ...
    (alt.lang.asm)
  • Re: When is "volatile" used instead of "lock" ?
    ... to get the address of a stack variable to a background thread. ... I'm suggesting that the memory model ... lock pattern works without making the instance member volatile; ... fields shared amongst more than one thread despite following the locking ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Resolving internal links
    ... You have to pass all workspace in via ... Which highlights another issue - you could not use Fortify (or similar code which uses these functions to replace the memory allocators) within the main application code unless you also used it within the module. ... At best you'll reference memory which does not exist and cause an abort. ... will only be able to use 256 bytes of stack space IIRC. ...
    (comp.sys.acorn.programmer)