[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MacIvory, RPC and Think C

    Date: Thu, 21 Dec 89 09:22:53 -0100
    From: gmdzi!bruening@uunet.UU.NET (Inke Bruening)
    I have  a  question  concerning  the  RPC-facility  of the
    MacIvory.  I used it with Lisp as client and C as  server.
    The C  compiler  is  the  one  used  in the example in the
    MacIvory Programmer's Reference,  Lightspeed C  (THINK C),
    version 3.01. First, I just programmed a small example and
    it  went  well;  but  then  I  wanted  to  write  a   real
    application.    It was necessary to create a RPC-structure
    of 48 c-strings.  That was the interface between Lisp  and
    C.   Unfortunateley,   the   C-programm   created  by  the
    Lispmachine was  very  large.    So,  after including some
    libraries and adding  a few  lines to  the C-program,  the
    C-compiler wasn't  able  to  build  a code resource. "Code
    resource too big".

The THINK C libraries are extremely large, and if you use most
of them, the libraries alone eat up most of the 32K segment size
allowed in THINK C version 3.  This is made worse by a bug in
THINK C version 3, known to be fixed in version 4, which tells
you that you have overflowed the 32K segment size when in fact
you have not; this is because it checks the segment size before
it eliminates library modules that are not actually used by your
program.  The workaround for this is to make a custom library
that only contains what you really need (copy the THINK C
supplied library, which is really a project, and eliminate
files from it until you get a library that suits you).  To see
what library entries you actually need, remove the library
from your project and do Check Link, which will create a
window containing a list of the undefined symbols that need to
come from libraries.

The Symbolics RPC library itself is very small, since most of its code
does not reside in your code resource, but is dynamically linked.

    It was necessary to create a RPC-structure
    of 48 c-strings.

It's possible that a fixed-length array of 48 elements, rather than a
structure with 48 components, would have produced more compact C code.