From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <f8ee78396de4f03af037019a49204eee@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Google search of the day
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 15 Feb 2008 11:07:59 -0500
In-Reply-To: <op.t6koogexc6yvfe@computer>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 54e73382-ead3-11e9-9d60-3106f5b1d025

> My understanding has always been that the stack is a fundamental element
> of the x86 architecture. SP and BP registers, later ESP and EBP, are all
> about the stack. All return addresses are stored on the stack. Parameter
> passing relies on it. And I know of no other means of implementing them.
> Except by avoiding call/ret instructions and solely jmp'ing around in a
> true mess of a code. No true "procedures."

while this is true, you are confusing calling convention and architecture.
the arch puts some limits on calling convention, but there is no requirement
to use the stack if you have one.

you could have a calling convention that every function emits a call block
with the arguments at callblock+offset and the return value(s) at callblock-
offset.  doesn't matter if the arch has a stack or not.  you are free to ignore it.
'
> I am almost sure the modern incarnations of FORTRAN (90, or even 77?) do
> support both true procedures and recursion. Though, I have not tried them
> so I do not have a say there.

fortran 95 supports recursion.  this does not imply that the *language*
requires a stack.  it could be done via heap allocation.  i don't know enough
fortran to comment intelligently on how its done.

> Automatic/scoped variables are allocated on the stack frame for procedure
> calls and/or nested code blocks (Flat Assembler's rendition of the IA-32
> "enter" instruction supports up to 32 stack frames). And without them,
> programming would be a lot harder.

some languages -- notibly c -- assume a stack frame.  there are many languages,
like fortran that do not.  you wouldn't notice what the compiler is doing in
those languages.

> There is also the "growing" heap for
> implementing dynamic variables which is quite as problematic as the stack
> because it, too, can grow beyond bounds and give one headaches.

this is an entirely different problem as heap allocations in most languages
are *explicit* thus allowing the programmer to respond to the situation
appropriately.  iirc, v7 sort used a binary search algorithm to figure out
how much memory it could sbrk().  e.g.

	int memsize;

	for(memsize = 1024*1024; memsize >= 4*1024;)
		if(sbrk(memsize)>0)
			break;

- erik