[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issues Involving ThinkC <--> MCL
- To: Info-MCL@cambridge.apple.com
- Subject: Issues Involving ThinkC <--> MCL
- From: "pierce" <email@example.com>
- Date: 27 Nov 91 11:29:21 U
Calling Think C code resources from MCL is not as useful as it sounds.
Their are several issues involved in calling multi-segment code resources.
Any Think C code which uses Think C objects needs to be muti-segment. Since
code resources use A4-addressing for accessing globals, you need to make sure
to save and restore the value of the A4 register around any evaluation of Think
C code which uses them. Also, you need to make sure all segments are loaded
from the main routine before making any calls across segments. This can be
accomplished using stub functions, one in each segment. The biggest problem
however, is that callbacks from the ROM need to make sure to save A4, store A4
in A0, and Restore A4 around their body. Unfortunately, the Think C class
library, and any other class libraries that I am familiar with do not take care
to do this since they are designed for use with applications, not code
In order to convert a Think C application that uses the Think C class library
into a callable code resource, you need to edit the class library and make sure
that any installed procedures that reference globals and get called back from
ROM setup and restore A4 around their body. This is not easy since callbacks
occur all over the place.
Also, There is no way to call Think C methods directly, so you need to define
functions which call methods for any methods that are callable from LISP.
The moral is that it is still difficult to write a significant hybrid
Lisp/Think C application that takes advantage of libraries of object based
interface code written in Think C and designed for use in Think C applications.