Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!hao!hplabs!sri-unix!gwyn@brl-vld From: gwyn%brl-vld@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: Switching run-time contexts Message-ID: <16411@sri-arpa.UUCP> Date: Sat, 4-Feb-84 21:27:15 EST Article-I.D.: sri-arpa.16411 Posted: Sat Feb 4 21:27:15 1984 Date-Received: Thu, 9-Feb-84 02:48:31 EST Lines: 58 From: Doug Gwyn (VLD/VMB)Of course, the exact details of inter-language linkage depend on the specific machine architecture and on choices made by the language implementers. For most, perhaps all, UNIX C systems the "run-time context" is fairly simple: A procedure compiled by C expects information passed in a stack frame, which typically contains procedure-return address, pointer to previous frame, arguments to procedure, saved registers from calling context (except those specifically reserved for procedure return value). "Automatic" (procedure invocation local) variables are often allocated off the same stack, although this is not the only possible design. "Static" and "extern" (global) data is allocated once at link time. To successfully invoke a C procedure from another language, one needs to ensure that the proper calling frame is set up; this is usually fairly easy if there is a run-time stack, tricky otherwise. The return value of a C procedure is often passed in a general register, which is likely to be simple to deal with too. The main problem you encounter when using C library routines may be external name conflicts at link time, especially since STDIO routines invoke "read", "write", "open", etc. which may conflict with names chosen by the other language user (or, less likely, by the language run-time system implementor). Most UNIX systems support mixed F77 & C by making the assembly-level names generated for the same user-supplied name distinct; e.g. "open" becomes _open from C and _open_ from F77. C procedures require very little run-time support; you will probably need to supply malloc() and free() to allocate and free chunks of memory, since these routines are explicitly used by STDIO for buffer allocation (they are not technically part of the run-time system, but you will need them). Errors from UNIX system calls are handled by storing an error code into a global integer `errno' and returning a characteristic value (normally -1) from the syscall procedure. This is pretty minimal error handling; UNIX System V math library routines invoke a (user-supplied, if desired) matherr() routine upon error. The C environments on the VAX for UNIX System V and 4.2BSD differ very little. Since the MC68000 architecture is much like that of a VAX, I suspect that C/68000 run-time environment design is similar to C/VAX. The bottom line, then, is that you should have little trouble using C library routines from L10 if there are no global name conflicts with ANYthing in the C library that might be (indirectly) linked in support of the routines you explicitly invoke, if you provide a little call/ return linkage converter and malloc/free package, and if you have a run-time stack compatible with normal C needs. The execution cost of the interface to C is almost certain to be insignificant compared with the I/O operation cost. A very good discussion of C run-time requirements is in Bell Labs Computing Science Technical Report # 102, "The C Language Calling Sequence", by S. C. Johnson and D. M. Ritchie. One used to be able to get CSTRs for the asking from MH 2C-364 but I don't know if that is still true.