From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 15 Feb 2008 15:44:30 +0000 To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Google search of the day From: "Eris Discordia" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.23 (Win32) Topicbox-Message-UUID: 54d3ea70-ead3-11e9-9d60-3106f5b1d025 On Fri, 15 Feb 2008 14:56:57 -0000, Brantley Coile wrote: > FORTRAN never had this problem. Its memory needs were fixed at > compile time. Neither did COBOL. But then again, you couldn't > write recursive programs either; all locals were static storage > class. The trade off to get recursion has been worth it anddoesn't > cause problems actual use. 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." 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. 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. 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. > It wasn't a problem with Algol, PL/1, Pascal, and C programs onvery > small machines. Why should it be a problem with today'smemory sizes? I remember getting a lot of "out of stack" errors from QuickBASIC, Turbo C and Borland C on MS-DOS. That was back when my computer had 8 MBs of RAM (a Win32 PE today has a default stack size of 8 MBs!) These days, stack overflows are most likely to cause problems by mingling data (return addresses and/or parameters) with executable code. I suppose segmentation mechanisms are there to precisely solve that problem. Never curse the "segfault" again ;-) -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/