C call interface (was: 2nd RfD: Separate FP Stack)
- From: anton@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl)
- Date: Sat, 01 Jul 2006 13:33:45 GMT
"George Hubert" <georgeahubert@xxxxxxxxxxx> writes:
Anton Ertl wrote:
"Charles Melice" <cm@xxxxxxxxxxxx> writes:
Unfortunately, ForthCAD uses also a unified stack. It is very practical
to pass single floats parameters towards C.
I guess that you mean that it makes it easier to implement a C-calling
interface on a particular platform (apparently the IA-32 architecture
for ForthCAD) with a particular Forth system.
It's not the only C-calling interface that does that; OpenGL in Windows
also expects floats on the stack.
OpenGL is a library where the interface is defined as C prototypes, so
of course it uses the C calling convention of the platform. For Win32
on IA-32 this is parameter passing on the stack. For Win32 on Alpha
they were not passed on the stack, and for Win64 on "x64" or IA-64
they are not passed on the stack, either.
Finally, being lazy with C call implementation on IA-32 leads to a C
calls where the order of arguments is the reverse of the order in the
manual, which is a bad idea (it puts the reversing load on the
programmer just to make the system implementor's job slightly easier).
The problem is that C (unlike Pascal) lists the parameters in the wrong
order.
What do you mean by that? Let's take a look at the OpenGL function
void glGetMapdv(GLenum target, GLenum query, GLdouble *v)
What's wong about that order? And I am sure that, if you call that
function from Pascal, you will call it with the same parameter order
(i.e., target leftmost). And a proper Forth-to-C interface will have
the stack effect ( target query v -- ). However, looking at the
description, I would probably make a wrapper for that function with
the stack effect ( target query -- r ).
Quite often the reverse order is better since it makes for
easier factoring of Forth code, since the first parameter (by C
standards) is often an object address or handle so (certainly in OO
programming) is in the right place.
You got me confused. Which order is better IYO? For the example
above, ( target query v -- ) looks better to me, because v will
typically be a variable address or somesuch, and query is probably
also a constant, whereas target has a slightly higher probability of
coming from a longer computation.
In general, my impression is that both the C order and its reversal
are often not the best order for Forth. But if the programmer has to
reverse the order from the documentation in addition to rearranging
the stack items for Forth needs, he will make more mistakes on average
than if he just has to rearrange the stack items for his needs. And
simularly, for someone reading the program, it will be easier to
understand if the parameters are just in the same order as in the
documentation.
For an optimising compiler
eliminating all the stack juggling is feasable, but for plain old ITC
(and DTC) IMO it's easier to have the programmer do it.
What stack juggling do you mean? The one that the programmer has to
write? I don't see that the compiler can do something about that.
The juggling that may happen internally on some systems and platforms
when calling a C function? Who cares? As you mention, optimizing
compilers will minimize that juggling in any case, and the users of
plain threaded-code systems don't expect extreme speed anyway.
Moreover, I would expect that in most cases when you call a C function
from Forth, the function will run for a relatively long time, so even
a large function call overhead will be in the noise.
An interesting aspect is that, even if Gforth used %esp as stack
pointer and had a unified stack, the function call overhead would be
the same for either parameter passing order, even on the IA-32
architecture, with any of the two (soon to be three) mechanisms we use
for calling C functions.
Also on Windows
given 99% of what's in the manual has errors in it (which vary between
different updates anyway) is the order they give likely to be that
accurate. Sometimes different parts of the manual contradict each other
so most of the time experimentation is the only way to find out what
works (as an example the latest MS docs state that W98 and ME don't
support a couple of the Critical Section calls that Win32Forth has been
using for 3 years on both OS's; only W95 doesn't support them, a fact
we only found out when somebody using W95 told us he got a compler
error when loading the multi-tasker).
Here's a nickel, kid. Get yourself a real OS.
I always wanted to use that line ever since I read it on Dilbert, but,
frell, it does not work, since you can get a real OS for free (the
original used "computer" instead of OS).
Anyway, the calling conventions of one particular platform are no
reason to put a bad C function call interface into Forth in general,
and documentation deficiencies of one particular OS are an even weaker
reason.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2006: http://www.complang.tuwien.ac.at/anton/euroforth2006/
.
- Follow-Ups:
- Re: C call interface (was: 2nd RfD: Separate FP Stack)
- From: George Hubert
- Re: C call interface (was: 2nd RfD: Separate FP Stack)
- References:
- Re: 2nd RfD: Separate FP Stack
- From: Charles Melice
- Re: 2nd RfD: Separate FP Stack
- From: Anton Ertl
- Re: 2nd RfD: Separate FP Stack
- From: George Hubert
- Re: 2nd RfD: Separate FP Stack
- Prev by Date: Re: 2nd RfD: Separate FP Stack
- Next by Date: Re: How do you do this?
- Previous by thread: Re: 2nd RfD: Separate FP Stack
- Next by thread: Re: C call interface (was: 2nd RfD: Separate FP Stack)
- Index(es):
Relevant Pages
|
