I have been learning to program in C over the last few weeks and have put some examples together. These include how to call Pascal from C and how to call C from Pascal. I am grateful to other people for their help, particularly The African Chief. Please see: http://www.staff.ncl.ac.uk/chris.hicks/programming.htm
Please bear in mind that I am not an expert. I would welcome any constructive comments.
Best regards, Chris
Dr Christian Hicks Senior Lecturer, School of Mechanical & Systems Engineering, Stephenson Building, University of Newcastle upon Tyne, NE1 7RU. Phone: +44 191 222 6238 Mobile 0795 8317804 Fax: + 44 191 222 8600 Homepage: http://www.staff.ncl.ac.uk/chris.hicks
Dr Christian Hicks wrote:
I have been learning to program in C over the last few weeks and have put some examples together. These include how to call Pascal from C and how to call C from Pascal. ... snip ...
What you are looking for is not a language dependency, but a run-time system dependency. This sort of interaction cannot be understood in general, so you would be better off understanding the basic mechanisms used in various systems. Move to a different machine or even compiler and the rules may be entirely different.
Most popular systems are built around the concept of a stack today, and usually (but not always) use this to pass parameters. Parameters can be passed in two basic forms, by value, or by reference. In C there is no reference, instead a pointer to the "referenced" parameter is passed by value. In Pascal, a parameter passed by reference is characterised by the VAR attribute, i.e. its value can be varied by the called function/procedure, and the default parameter passing mechanism is by value.
Parameters, or pointers (references) can also be passed in registers. This is less regular and requires more detailed knowledge of the actual system, so I am only mentioning it in passing.
The next fundamental thing to know about a parameter passing mechanism is the order. Some systems pass them in the order mentioned in the function header, and some in the reverse direction. Pascal *tends* to use the order mentioned, and C *tends* to use the reverse order, so that the first C parameter will normally be at the top of the stack when the call is made. The purpose of this is to ease the so-called varargs parameter lists of C, which do not occur in Pascal.
Another fundamental variation is "who is responsible for removing parameters from the stack". In Pascal a function is always called with a fixed list of parameters, so the code to remove it need be only in one place, and this is most efficiently done in the called function. In C, only the caller actually knows how many parameters were passed, so the caller is usually responsible for removal. Notice usually, these are not hard and fast rules, just tendencies.
A further kettle of worms is 'what is the mechanism for returning function values'. In C the caller can simply ignore the returned value, thus discarding it. In Pascal such failure is an error. Thus C tends to return values in registers, where they can be simply overwritten at any time, and Pascal oftern returns them on the stack, where they must be specifically removed to avoid fouling the stack.
Let me repeat - there is nothing dogmatic about any of these mechanisms. The implementor can do whatever s/he wishes, as long as the language rules are followed.
AFAIK the only language to specify general means of calling routines written in other languages is Ada. C++ has provisions for calling C routines. However these abilities only apply to the use of specified compilers and libraries.
A hardware platform may also specify specific calling protocols and mechanisms, which can ease creation of compilers etc. that provide interoperability. The IBM 360 and successors, and the HP3000, had such specifications.
CBFalconer wrote:
What you are looking for is not a language dependency, but a run-time system dependency. This sort of interaction cannot be understood in general, so you would be better off understanding the basic mechanisms used in various systems. Move to a different machine or even compiler and the rules may be entirely different.
Most popular systems are built around the concept of a stack today, and usually (but not always) use this to pass parameters.
Indeed modern architectures use (also) registers to pass parameters. However, the passing conventions are the same between GPC and GCC (by the shared backend) and also between GCC and most other C compilers (by platform ABIs). So this should not actually be an issue.
Parameters can be passed in two basic forms, by value, or by reference. In C there is no reference, instead a pointer to the "referenced" parameter is passed by value. In Pascal, a parameter passed by reference is characterised by the VAR attribute, i.e. its value can be varied by the called function/procedure, and the default parameter passing mechanism is by value.
Correct.
The next fundamental thing to know about a parameter passing mechanism is the order. Some systems pass them in the order mentioned in the function header, and some in the reverse direction. Pascal *tends* to use the order mentioned, and C *tends* to use the reverse order, so that the first C parameter will normally be at the top of the stack when the call is made.
However, GPC by default (i.e., unless overriden by attributes) uses the "C convention" (right to left). So also no problem WRT C vs. GPC here.
Another fundamental variation is "who is responsible for removing parameters from the stack". In Pascal a function is always called with a fixed list of parameters, so the code to remove it need be only in one place, and this is most efficiently done in the called function.
Also here, GPC's default is the C convention. BTW, it's not necessarily worse: The caller can choose to do several calls in sequence and remove all parameters at the end (provided there are no control flow breaks, and parameters are not too large), which the GCC backend actually does. So the number of such pop statements in the binary might be the same or higher, and but number of pops done at runtime can actually be smaller.
A further kettle of worms is 'what is the mechanism for returning function values'. In C the caller can simply ignore the returned value, thus discarding it. In Pascal such failure is an error. Thus C tends to return values in registers, where they can be simply overwritten at any time, and Pascal oftern returns them on the stack, where they must be specifically removed to avoid fouling the stack.
I'm not sure if that's really so common. I've seen other Pascal compilers (even one of the less optimizing ones out there ...) return values in registers. Again, GPC defaults to the C convention.
AFAIK the only language to specify general means of calling routines written in other languages is Ada. C++ has provisions for calling C routines. However these abilities only apply to the use of specified compilers and libraries.
Yes, there's no compiler-independent way. But talking compiler specific, calling between GPC and GNU C (and also GNU C++ when using the C compatibility features on both sides) is quite reliable -- and then it's system-portable. (We use this mechanism in the RTS and some of the included units, so if it failed on some platform, we'd know quickly.)
A hardware platform may also specify specific calling protocols and mechanisms, which can ease creation of compilers etc. that provide interoperability. The IBM 360 and successors, and the HP3000, had such specifications.
I think almost any platform has such an ABI -- whether it was written by the processor, OS or (first) compiler makers, I don't know in general. GCC generally follows the system ABI where one exists, and provides its own one where it's the default compiler (GNU Hurd, Linux).
Frank
On 23 Nov 2003 at 2:29, Frank Heckenbach wrote:
However, GPC by default (i.e., unless overriden by attributes) uses the "C convention" (right to left).
I've looked through:
http://www.gnu-pascal.de/gpc/attribute.html
and:
http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Function-Attributes.html
...and I don't see an attribute that changes the parameter-passing order. Is it undocumented, or did I overlook it?
-- Dave
J. David Bryan wrote:
On 23 Nov 2003 at 2:29, Frank Heckenbach wrote:
However, GPC by default (i.e., unless overriden by attributes) uses the "C convention" (right to left).
I've looked through:
http://www.gnu-pascal.de/gpc/attribute.html
and:
http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Function-Attributes.html
...and I don't see an attribute that changes the parameter-passing order. Is it undocumented, or did I overlook it?
there is `regparm (number)' attribute (which causes some parameters to be passed in registers). I leave to others to decide if that count as change in parameter-passing order.
On 23 Nov 2003 at 2:29, Frank Heckenbach wrote:
However, GPC by default (i.e., unless overriden by attributes) uses the "C convention" (right to left).
On 23 Nov 2003 at 21:03, Waldek Hebisch wrote:
there is `regparm (number)' attribute (which causes some parameters to be passed in registers).
The implication I read in Frank's statement is that there is an attribute that causes parameters to be stacked left-to-right. But perhaps I have misunderstood what was meant?
-- Dave
J. David Bryan wrote:
The implication I read in Frank's statement is that there is an attribute that causes parameters to be stacked left-to-right. But perhaps I have misunderstood what was meant?
I never claimed this.
Frank
Dr Christian Hicks wrote:
I have been learning to program in C over the last few weeks and have put some examples together. These include how to call Pascal from C and how to call C from Pascal. I am grateful to other people for their help, particularly The African Chief. Please see: http://www.staff.ncl.ac.uk/chris.hicks/programming.htm
Please bear in mind that I am not an expert. I would welcome any constructive comments.
I don't have the time to really look at it, but the first paragraph strikes me:
: The first thing that you need is a Linux operating system. I use : either Red Hat 9 or Cygwin which can be installed and run on : computers running Microsoft Windows.
Cygwin is not Linux. I think what you mean is a Unix compatible or a POSIX system which Cygwin is (I think the latter is more appropriate).
Linux is actually just the kernel which together with many GNU and other programs (many of which are also included with Cygin) form a full system, but AFAIK there's no Linux code in Cygwin.
Frank
-
CBFalconer -
Dr Christian Hicks -
Frank Heckenbach -
J. David Bryan -
Waldek Hebisch