Re: Patch to fix i960 objc runtime build

[Ovidiu Predescu <ovidiu at cup dot hp dot com>]

On Thu, 15 Mar 2001 20:03:45 -0800, Jim Wilson <wilson@cygnus.com> wrote:

> >> + #define REAL_TYPE       _C_DBL
> >
> >OK, I give up.  How is this supposed to work?  REAL_TYPE as used in
> >ROUND_TYPE_ALIGN is unrelated to the ObjC encoding char _C_DBL, at
> >least as I understand the code.
> 
> The entire file is a hack.  It looks like objc has some kind of way to
> create new types at run-time.  That requires a way to layout types at
> runtime.  This was implemented by copying most of layout_type from
> stor-layout.c into the objc runtime file encoding.c.  This includes various
> macros that rely on gcc internals, such as ROUND_TYPE_ALIGN.  To make that
> work, the file tries to map tree.h macros into the objc runtime equivalents.
> The i960 port is failing here because it uses a bit of tree.h that isn't
> already mapped to some objc runtime equivalent.
> 
> The whole approach looks risky to me.  A builtin function that calls into
> the real layout_type function is probably a better solution.
> 
> Or maybe generalize the macros for type layout, so that it is easier
> for libraries or other compilers to get the same type layout as gcc.

OK, let's see if I remember this, it's been a while since I
implemented it...

The Objective-C runtime can make use of the Boehm's garbage collector
as a way to clean-up the memory. It uses an advanced feature of the
collector, called typed memory allocation to essentially do the
following:

1) provide a better performance, by instructing the collector where
pointers are inside an object,

2) to allow for some nice features, like weak pointers, to be
available in the runtime, so they can be used by the developers.

To be able to use typed memory, Boehm's collector essentially requires
that for each object created by the runtime, a map of where pointers
are located inside it should be passed at the time of memory
allocation.

There is code in the runtime that computes these maps for each class
in the running program. For this code to work, the only reliable way
to do it correctly appears to be to replicate the algorithm in
stor-layout.c. Unfortunately this code heavily depends on the target
machine, which translates into macros, thus all the problems we
have.

The runtime does only an approximative job, because on some machines
the memory layout depends on flags passed at compilation time. There
is no way for the runtime to find out how a file was compiled, as
these flags are not put in the generated object file. The runtime
assumes some reasonable defaults, thus you see some of the target
macros defined in encoding.c to fixed values, even though in the
target files they expand into a complex logic.

Now I agree that the maps can also be computed at compile time. But
the code which identifies fields in an object or a structure, code
which implements the above mentioned hacks, is used by user level
libraries that implement distributed objects and other nice
Objective-C goodies. There is no way for these user level libraries to
have access to structure fields in a machine independent way, other
than using these functions in the runtime.

Regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

Hope to see you at my presentation, "Using Cocoon to build Web sites
for wireless devices" at ApacheCon 2001 at the Santa Clara Convention
Center, 5001 Great America Parkway, Santa Clara, CA 95054.