From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 15 Feb 2008 17:39:51 +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: 555d7bbe-ead3-11e9-9d60-3106f5b1d025 On Fri, 15 Feb 2008 16:07:59 -0000, erik quanstrom wrote: > 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. > ' The calling conventions I have seen are the ccall, stdcall (Windows' slightly modified version of the ccall), and pascal. All of them push parameters on the stack. On x86 (the only architecture I have seen), the return address is pushed on the stack as soon as something like "call 0x04500" or "call _myfunc" is executed. Not popping the right number of parameters before executing ret has times over been a problem with my programs. I understand that the push order and marshalling strategy (by-value/by-reference) need not be the same from one language to the other. Still, all "implementations" of languages on x86 (even FORTRAN, according to my copy of Steven Holzner's Advanced Assembly Programming) "have" to push their parameters on stack. I cannot see any other way to keep the bare minimum required for a procedure call: the return address, that is. Probably because I do not understand the notion of a "callblock." > 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. You mean, if I disassemble a FORTRAN-compiled binary I will not see the classical EBP/ESP manipulation at the beginning of each procedure with automatic variables? I have disassembled C-compiled binaries and seen that (actually did it so that I could do the same in my assemly programs). ----snippet---- ;enter the stack frame push ebp mov ebp, esp ;reserve stack space for a 32-bit automatic variable sub ebp, 04h ;leave the stack frame mov esp, ebp pop ebp ;returning requires the return address ;(the previous value of EIP) pushed on the stack ret ----snippet---- On Fri, 15 Feb 2008 16:43:22 -0000, maht wrote: > The threaded / concatanative langauges such as Forth / Joy / Cat / V > don't use a call stack, though they still use a stack for parameter > manipulation. I have heard Forth is used for writing bootloaders (FreeBSD's loader was written in Forth last time I checked). If the architecture is x86, then issuing a call (op-code 0x9A+[ModRM]) certainly pushes EIP on the stack. Perhaps they use jmp for branching. > http://en.wikipedia.org/wiki/Stackless_Python > > Is it the same sort of stack ? Python is an "interpreted" language (like Perl). Everything is implemented on a semi-virtual machine (they usually call it the engine). Not sure their stack is the same as the x86 stack segment. "Stackless Python, or Stackless, is an experimental implementation of the Python programming language, so named because it avoids depending on the C call stack for its own stack. The language supports generators, microthreads, and coroutines." --Wikipedia -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/