Re: [9fans] Google search of the day

["Eris Discordia" <eris.discordia@gmail.com>]

On Fri, 15 Feb 2008 16:07:59 -0000, erik quanstrom <quanstro@quanstro.net>
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 <mattmobile@proweb.co.uk> 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/