--- /dev/null
+
+GNU Objective C notes
+*********************
+
+This document is to explain what has been done, and a little about how
+specific features differ from other implementations. The runtime has
+been completely rewritten in gcc 2.4. The earlier runtime had several
+severe bugs and was rather incomplete. The compiler has had several
+new features added as well.
+
+This is not documentation for Objective C, it is usable to someone
+who knows Objective C from somewhere else.
+
+
+Runtime API functions
+=====================
+
+The runtime is modeled after the NeXT Objective C runtime. That is,
+most functions have semantics as it is known from the NeXT. The
+names, however, have changed. All runtime API functions have names
+of lowercase letters and underscores as opposed to the
+`traditional' mixed case names.
+ The runtime api functions are not documented as of now.
+Someone offered to write it, and did it, but we were not allowed to
+use it by his university (Very sad story). We have started writing
+the documentation over again. This will be announced in appropriate
+places when it becomes available.
+
+
+Protocols
+=========
+
+Protocols are now fully supported. The semantics is exactly as on the
+NeXT. There is a flag to specify how protocols should be typechecked
+when adopted to classes. The normal typechecker requires that all
+methods in a given protocol must be implemented in the class that
+adopts it -- it is not enough to inherit them. The flag
+`-Wno-protocol' causes it to allow inherited methods, while
+`-Wprotocols' is the default which requires them defined.
+
+
++initialize
+===========
+
+This method, if defined, is called before any other instance or class
+methods of that particular class. This method is not inherited, and
+is thus not called as initializer for a subclass that doesn't define
+it itself. Thus, each +initialize method is called exactly once (or
+never if no methods of that particular class is never called).
+Besides this, it is allowed to have several +initialize methods, one
+for each category. The order in which these (multiple methods) are
+called is not well defined. I am not completely certain what the
+semantics of this method is for other implementations, but this is
+how it works for GNU Objective C.
+
+
+Passivation/Activation/Typedstreams
+===================================
+
+This is supported in the style of NeXT TypedStream's. Consult the
+headerfile Typedstreams.h for api functions. I (Kresten) have
+rewritten it in Objective C, but this implementation is not part of
+2.4, it is available from the GNU Objective C prerelease archive.
+ There is one difference worth noting concerning objects stored with
+objc_write_object_reference (aka NXWriteObjectReference). When these
+are read back in, their object is not guaranteed to be available until
+the `-awake' method is called in the object that requests that object.
+To objc_read_object you must pass a pointer to an id, which is valid
+after exit from the function calling it (like e.g. an instance
+variable). In general, you should not use objects read in until the
+-awake method is called.
+
+
+Acknowledgements
+================
+
+The GNU Objective C team: Geoffrey Knauth <gsk@marble.com> (manager),
+Tom Wood <wood@next.com> (compiler) and Kresten Krab Thorup
+<krab@iesd.auc.dk> (runtime) would like to thank a some people for
+participating in the development of the present GNU Objective C.
+
+Paul Burchard <burchard@geom.umn.edu> and Andrew McCallum
+<mccallum@cs.rochester.edu> has been very helpful debugging the
+runtime. Eric Herring <herring@iesd.auc.dk> has been very helpful
+cleaning up after the documentation-copyright disaster and is now
+helping with the new documentation.
+
+Steve Naroff <snaroff@next.com> and Richard Stallman
+<rms@gnu.ai.mit.edu> has been very helpful with implementation details
+in the compiler.
+
+
+Bug Reports
+===========
+
+Please read the section `Submitting Bugreports' of the gcc manual
+before you submit any bugs.
--- /dev/null
+==============================================================================
+README.threads - Wed Nov 29 15:16:24 EST 1995
+------------------------------------------------------------------------------
+
+Limited documentation is available in the THREADS file.
+
+This version has been tested on Sun Solaris, SGI Irix, and Windows NT.
+It should also work on any single threaded system.
+
+Thanks go to the following people for help test and debug the library:
+
+ Scott Christley, scottc@ocbi.com
+ Andrew McCallum, mccallum@cs.rochester.edu
+
+galen
+gchunt@cs.rochester.edu
+
+Any questions, bug reports, etc should be directed to:
+
+Scott Christley, scottc@ocbi.com
+
+Please do not bug Galen with email as he no longer supports the code.
+
+==============================================================================
+Changes from prior releases (in revered chronological order):
+------------------------------------------------------------------------------
+
+* Fixed bug in copy part of sarray_realloc. I had an < which should
+ have been <=. (Bug report from Scott).
+
+------------------------------------------------------------------------------
+
+* Support for DEC OSF/1 is definitely broken. My programs always
+ seg-fault when I link with libpthreads.a.
+
+* Thread id's are no longer int's, but are instead of type
+ _objc_thread_t which is typedef'ed from a void *. An invalid thread
+ id is denoted by NULL and not -1 as before.
+
+------------------------------------------------------------------------------
+
+* Renamed thread-winnt.c to thread-win32.c to better reflect support
+ for the API on both Windows NT and Windows 95 platforms.
+ (Who knows, maybe even Win32s :-).
+
+* Fixed bugs in Win32 support as per report from Scott Christley.
+
+* Fixed bug in sarray_get as per report from Scott Christley.
+
+
--- /dev/null
+This file describes in little detail the modifications to the
+Objective-C runtime needed to make it thread safe.
+
+First off, kudos to Galen Hunt who is the author of this great work.
+
+If you have an comments or just want to know where to
+send me money to express your undying gratitude for threading the
+Objective-C runtime you can reach Galen at:
+
+ gchunt@cs.rochester.edu
+
+Any questions, comments, bug reports, etc. should send email either to the
+GCC bug account or to:
+
+ Scott Christley <scottc@net-community.com>
+
+* Sarray Threading:
+
+The most critical component of the Objective-C runtime is the sparse array
+structure (sarray). Sarrays store object selectors and implementations.
+Following in the tradition of the Objective-C runtime, my threading
+support assumes that fast message dispatching is far more important
+than *ANY* and *ALL* other operations. The message dispatching thus
+uses *NO* locks on any kind. In fact, if you look in sarray.h, you
+will notice that the message dispatching has not been modified.
+Instead, I have modified the sarray management functions so that all
+updates to the sarray data structure can be made in parallel will
+message dispatching.
+
+To support concurrent message dispatching, no dynamically allocated
+sarray data structures are freed while more than one thread is
+operational. Sarray data structures that are no longer in use are
+kept in a linked list of garbage and are released whenever the program
+is operating with a single thread. The programmer can also flush the
+garbage list by calling sarray_remove_garbage when the programmer can
+ensure that no message dispatching is taking place concurrently. The
+amount of un-reclaimed sarray garbage should normally be extremely
+small in a real program as sarray structures are freed only when using
+the "poseAs" functionality and early in program initialization, which
+normally occurs while the program is single threaded.
+
+******************************************************************************
+* Static Variables:
+
+The following variables are either statically or globally defined. This list
+does not include variables which are internal to implementation dependent
+versions of thread-*.c.
+
+The following threading designations are used:
+ SAFE : Implicitly thread safe.
+ SINGLE : Must only be used in single thread mode.
+ MUTEX : Protected by single global mutex objc_runtime_mutex.
+ UNUSED : Not used in the runtime.
+
+Variable Name: Usage: Defined: Also used in:
+=========================== ====== ============ =====================
+__objc_class_hash MUTEX class.c
+__objc_class_links_resolved UNUSED class.c runtime.h
+__objc_class_number MUTEX class.c
+__objc_dangling_categories UNUSED init.c
+__objc_module_list MUTEX init.c
+__objc_selector_array MUTEX selector.c
+__objc_selector_hash MUTEX selector.c
+__objc_selector_max_index MUTEX selector.c sendmsg.c runtime.h
+__objc_selector_names MUTEX selector.c
+__objc_thread_exit_status SAFE thread.c
+__objc_uninstalled_dtable MUTEX sendmsg.c selector.c
+_objc_load_callback SAFE init.c objc-api.h
+_objc_lookup_class SAFE class.c objc-api.h
+_objc_object_alloc SINGLE objects.c objc-api.h
+_objc_object_copy SINGLE objects.c objc-api.h
+_objc_object_dispose SINGLE objects.c objc-api.h
+frwd_sel SAFE2 sendmsg.c
+idxsize MUTEX sarray.c sendmsg.c sarray.h
+initialize_sel SAFE2 sendmsg.c
+narrays MUTEX sarray.c sendmsg.c sarray.h
+nbuckets MUTEX sarray.c sendmsg.c sarray.h
+nindices MUTEX sarray.c sarray.h
+previous_constructors SAFE1 init.c
+proto_class SAFE1 init.c
+unclaimed_categories MUTEX init.c
+unclaimed_proto_list MUTEX init.c
+uninitialized_statics MUTEX init.c
+
+Notes:
+1) Initialized once in unithread mode.
+2) Initialized value will always be same, guaranteed by lock on selector
+ hash table.
+
+
+******************************************************************************
+* Frontend/Backend design:
+
+The design of the Objective-C runtime thread and mutex functions utilizes a
+frontend/backend implementation.
+
+The frontend, as characterized by the files thr.h and thr.c, is a set
+of platform independent structures and functions which represent the
+user interface. Objective-C programs should use these structures and
+functions for their thread and mutex work if they wish to maintain a
+high degree of portability across platforms.
+
+The backend is composed of a file with the necessary code to map the ObjC
+thread and mutex to a platform specific implementation. For example, the
+file thr-solaris.c contains the implementation for Solaris. When you
+configure GCC, it attempts to pick an appropriate backend file for the
+target platform; however, you can override this choice by assign the
+OBJC_THREAD_FILE make variable to the basename of the backend file. This
+is especially useful on platforms which have multiple thread libraries.
+For example:
+
+ make OBJC_THREAD_FILE=thr-posix
+
+would indicate that the generic posix backend file, thr-posix.c, should be
+compiled with the ObjC runtime library. If your platform does not support
+threads then you should specify the OBJC_THREAD_FILE=thr-single backend file
+to compile the ObjC runtime library without thread or mutex support; note
+that programs which rely upon the ObjC thread and mutex functions will
+compile and link correctly but attempting to create a thread or mutex will
+result in an error.
+
+It is questionable whether it is really necessary to have both a
+frontend and backend function for all available functionality. On the
+one hand, it provides a clear, consistent differentiation between what
+is public and what is private with the downside of having the overhead
+of multiple functions calls. For example, the function to have a thread
+yield the processor is objc_thread_yield; in the current implementation
+this produces a function call set:
+
+objc_thread_yield() -> __objc_thread_yield() -> system yield function
+
+This has two extra function calls over calling the platform specific function
+explicitly, but the issue is whether only the overhead of a single function
+is necessary.
+
+objc_thread_yield() -> system yield function
+
+This breaks the public/private dichotomy between the frontend/backend
+for the sake of efficiency. It is possible to just use a preprocessor
+define so as to eliminate the extra function call:
+
+#define objc_thread_yield() __objc_thread_yield()
+
+This has the undesirable effect that if objc_thread_yield is actually
+turned into a function based upon future need; then ObjC programs which
+access the thread functions would need to be recompiled versus just
+being relinked.
+
+******************************************************************************
+* Threads:
+
+The thread system attempts to create multiple threads using whatever
+operating system or library thread support is available. It does
+assume that all system functions are thread safe. Notably this means
+that the system implementation of malloc and free must be thread safe.
+If a system has multiple processors, the threads are configured for
+full parallel processing.
+
+* Backend initialization functions
+
+__objc_init_thread_system(void), int
+ Initialize the thread subsystem. Called once by __objc_exec_class.
+ Return -1 if error otherwise return 0.
+
+__objc_close_thread_system(void), int
+ Closes the thread subsystem, not currently guaranteed to be called.
+ Return -1 if error otherwise return 0.
+
+*****
+* Frontend thread functions
+* User programs should use these functions.
+
+objc_thread_detach(SEL selector, id object, id argument), objc_thread_t
+ Creates and detaches a new thread. The new thread starts by
+ sending the given selector with a single argument to the
+ given object.
+
+objc_thread_set_priority(int priority), int
+ Sets a thread's relative priority within the program. Valid
+ options are:
+
+ OBJC_THREAD_INTERACTIVE_PRIORITY
+ OBJC_THREAD_BACKGROUND_PRIORITY
+ OBJC_THREAD_LOW_PRIORITY
+
+objc_thread_get_priority(void), int
+ Query a thread's priority.
+
+objc_thread_yield(void), void
+ Yields processor to another thread with equal or higher
+ priority. It is up to the system scheduler to determine if
+ the processor is taken or not.
+
+objc_thread_exit(void), int
+ Terminates a thread. If this is the last thread executing
+ then the program will terminate.
+
+objc_thread_id(void), int
+ Returns the current thread's id.
+
+objc_thread_set_data(void *value), int
+ Set a pointer to the thread's local storage. Local storage is
+ thread specific.
+
+objc_thread_get_data(void), void *
+ Returns the pointer to the thread's local storage.
+
+*****
+* Backend thread functions
+* User programs should *NOT* directly call these functions.
+
+__objc_thread_detach(void (*func)(void *arg), void *arg), objc_thread_t
+ Spawns a new thread executing func, called by objc_thread_detach.
+ Return NULL if error otherwise return thread id.
+
+__objc_thread_set_priority(int priority), int
+ Set the thread's priority, called by objc_thread_set_priority.
+ Return -1 if error otherwise return 0.
+
+__objc_thread_get_priority(void), int
+ Query a thread's priority, called by objc_thread_get_priority.
+ Return -1 if error otherwise return the priority.
+
+__objc_thread_yield(void), void
+ Yields the processor, called by objc_thread_yield.
+
+__objc_thread_exit(void), int
+ Terminates the thread, called by objc_thread_exit.
+ Return -1 if error otherwise function does not return.
+
+__objc_thread_id(void), objc_thread_t
+ Returns the current thread's id, called by objc_thread_id.
+ Return -1 if error otherwise return thread id.
+
+__objc_thread_set_data(void *value), int
+ Set pointer for thread local storage, called by objc_thread_set_data.
+ Returns -1 if error otherwise return 0.
+
+__objc_thread_get_data(void), void *
+ Returns the pointer to the thread's local storage.
+ Returns NULL if error, called by objc_thread_get_data.
+
+
+******************************************************************************
+* Mutexes:
+
+Mutexes can be locked recursively. Each locked mutex remembers
+its owner (by thread id) and how many times it has been locked. The
+last unlock on a mutex removes the system lock and allows other
+threads to access the mutex.
+
+*****
+* Frontend mutex functions
+* User programs should use these functions.
+
+objc_mutex_allocate(void), objc_mutex_t
+ Allocates a new mutex. Mutex is initially unlocked.
+ Return NULL if error otherwise return mutex pointer.
+
+objc_mutex_deallocate(objc_mutex_t mutex), int
+ Free a mutex. Before freeing the mutex, makes sure that no
+ one else is using it.
+ Return -1 if error otherwise return 0.
+
+objc_mutex_lock(objc_mutex_t mutex), int
+ Locks a mutex. As mentioned earlier, the same thread may call
+ this routine repeatedly.
+ Return -1 if error otherwise return 0.
+
+objc_mutex_trylock(objc_mutex_t mutex), int
+ Attempts to lock a mutex. If lock on mutex can be acquired
+ then function operates exactly as objc_mutex_lock.
+ Return -1 if failed to acquire lock otherwise return 0.
+
+objc_mutex_unlock(objc_mutex_t mutex), int
+ Unlocks the mutex by one level. Other threads may not acquire
+ the mutex until this thread has released all locks on it.
+ Return -1 if error otherwise return 0.
+
+*****
+* Backend mutex functions
+* User programs should *NOT* directly call these functions.
+
+__objc_mutex_allocate(objc_mutex_t mutex), int
+ Allocates a new mutex, called by objc_mutex_allocate.
+ Return -1 if error otherwise return 0.
+
+__objc_mutex_deallocate(objc_mutex_t mutex), int
+ Free a mutex, called by objc_mutex_deallocate.
+ Return -1 if error otherwise return 0.
+
+__objc_mutex_lock(objc_mutex_t mutex), int
+ Locks a mutex, called by objc_mutex_lock.
+ Return -1 if error otherwise return 0.
+
+__objc_mutex_trylock(objc_mutex_t mutex), int
+ Attempts to lock a mutex, called by objc_mutex_trylock.
+ Return -1 if failed to acquire lock or error otherwise return 0.
+
+__objc_mutex_unlock(objc_mutex_t mutex), int
+ Unlocks the mutex, called by objc_mutex_unlock.
+ Return -1 if error otherwise return 0.
+
+******************************************************************************
+* Condition Mutexes:
+
+Mutexes can be locked recursively. Each locked mutex remembers
+its owner (by thread id) and how many times it has been locked. The
+last unlock on a mutex removes the system lock and allows other
+threads to access the mutex.
+
+*
+* Frontend condition mutex functions
+* User programs should use these functions.
+*
+
+objc_condition_allocate(void), objc_condition_t
+ Allocate a condition mutex.
+ Return NULL if error otherwise return condition pointer.
+
+objc_condition_deallocate(objc_condition_t condition), int
+ Deallocate a condition. Note that this includes an implicit
+ condition_broadcast to insure that waiting threads have the
+ opportunity to wake. It is legal to dealloc a condition only
+ if no other thread is/will be using it. Does NOT check for
+ other threads waiting but just wakes them up.
+ Return -1 if error otherwise return 0.
+
+objc_condition_wait(objc_condition_t condition, objc_mutex_t mutex), int
+ Wait on the condition unlocking the mutex until objc_condition_signal()
+ or objc_condition_broadcast() are called for the same condition. The
+ given mutex *must* have the depth 1 so that it can be unlocked
+ here, for someone else can lock it and signal/broadcast the condition.
+ The mutex is used to lock access to the shared data that make up the
+ "condition" predicate.
+ Return -1 if error otherwise return 0.
+
+objc_condition_broadcast(objc_condition_t condition), int
+ Wake up all threads waiting on this condition. It is recommended that
+ the called would lock the same mutex as the threads in
+ objc_condition_wait before changing the "condition predicate"
+ and make this call and unlock it right away after this call.
+ Return -1 if error otherwise return 0.
+
+objc_condition_signal(objc_condition_t condition), int
+ Wake up one thread waiting on this condition.
+ Return -1 if error otherwise return 0.
+
+*
+* Backend condition mutex functions
+* User programs should *NOT* directly call these functions.
+*
+
+__objc_condition_allocate(objc_condition_t condition), int
+ Allocate a condition mutex, called by objc_condition_allocate.
+ Return -1 if error otherwise return 0.
+
+__objc_condition_deallocate(objc_condition_t condition), int
+ Deallocate a condition, called by objc_condition_deallocate.
+ Return -1 if error otherwise return 0.
+
+__objc_condition_wait(objc_condition_t condition, objc_mutex_t mutex), int
+ Wait on the condition, called by objc_condition_wait.
+ Return -1 if error otherwise return 0 when condition is met.
+
+__objc_condition_broadcast(objc_condition_t condition), int
+ Wake up all threads waiting on this condition.
+ Called by objc_condition_broadcast.
+ Return -1 if error otherwise return 0.
+
+__objc_condition_signal(objc_condition_t condition), int
+ Wake up one thread waiting on this condition.
+ Called by objc_condition_signal.
+ Return -1 if error otherwise return 0.
--- /dev/null
+This readme refers to the file thr-mach.c.
+
+Under mach, thread priorities are kinda strange-- any given thread has
+a MAXIMUM priority and a BASE priority. The BASE priority is the
+current priority of the thread and the MAXIMUM is the maximum possible
+priority the thread can assume. The developer can lower, but never
+raise the maximum priority.
+
+The gcc concept of thread priorities is that they run at one of three
+levels; interactive, background, and low.
+
+Under mach, this is translated to:
+
+interactive -- set priority to maximum
+background -- set priority to 2/3 of maximum
+low -- set priority to 1/3 of maximum
+
+This means that it is possible for a thread with the priority of
+interactive to actually run at a lower priority than another thread
+with a background, or even low, priority if the developer has modified
+the maximum priority.
+
+
--- /dev/null
+\input texinfo @c -*-texinfo-*-
+@c %**start of header
+@setfilename objc-features.info
+@settitle GNU Objective-C runtime features
+@setchapternewpage odd
+@c %**end of header
+
+@node Top, Executing code before main, , (dir), (dir)
+@comment node-name, next, previous, up
+
+@chapter GNU Objective-C runtime features
+
+This document is meant to describe some of the GNU Objective-C runtime
+features. It is not intended to teach you Objective-C, there are several
+resources on the Internet that present the language. Questions and
+comments about this document to Ovidiu Predescu
+@code{<ovidiu@@aracnet.com>}.
+
+@menu
+* Executing code before main::
+* Type encoding::
+* Garbage Collection::
+@end menu
+
+
+@node Executing code before main, What you can and what you cannot do in +load, Top, Top
+@section @code{+load}: Executing code before main
+
+
+The GNU Objective-C runtime provides a way that allows you to execute
+code before the execution of the program enters the @code{main}
+function. The code is executed on a per-class and a per-category basis,
+through a special class method @code{+load}.
+
+This facility is very useful if you want to initialize global variables
+which can be accessed by the program directly, without sending a message
+to the class first. The usual way to initialize global variables, in the
+@code{+initialize} method, might not be useful because
+@code{+initialize} is only called when the first message is sent to a
+class object, which in some cases could be too late.
+
+Suppose for example you have a @code{FileStream} class that declares
+@code{Stdin}, @code{Stdout} and @code{Stderr} as global variables, like
+below:
+
+@example
+
+FileStream *Stdin = nil;
+FileStream *Stdout = nil;
+FileStream *Stderr = nil;
+
+@@implementation FileStream
+
++ (void)initialize
+@{
+ Stdin = [[FileStream new] initWithFd:0];
+ Stdout = [[FileStream new] initWithFd:1];
+ Stderr = [[FileStream new] initWithFd:2];
+@}
+
+/* Other methods here */
+@@end
+
+@end example
+
+In this example, the initialization of @code{Stdin}, @code{Stdout} and
+@code{Stderr} in @code{+initialize} occurs too late. The programmer can
+send a message to one of these objects before the variables are actually
+initialized, thus sending messages to the @code{nil} object. The
+@code{+initialize} method which actually initializes the global
+variables is not invoked until the first message is sent to the class
+object. The solution would require these variables to be initialized
+just before entering @code{main}.
+
+The correct solution of the above problem is to use the @code{+load}
+method instead of @code{+initialize}:
+
+@example
+
+@@implementation FileStream
+
++ (void)load
+@{
+ Stdin = [[FileStream new] initWithFd:0];
+ Stdout = [[FileStream new] initWithFd:1];
+ Stderr = [[FileStream new] initWithFd:2];
+@}
+
+/* Other methods here */
+@@end
+
+@end example
+
+The @code{+load} is a method that is not overridden by categories. If a
+class and a category of it both implement @code{+load}, both methods are
+invoked. This allows some additional initializations to be performed in
+a category.
+
+This mechanism is not intended to be a replacement for @code{+initialize}.
+You should be aware of its limitations when you decide to use it
+instead of @code{+initialize}.
+
+@menu
+* What you can and what you cannot do in +load::
+@end menu
+
+
+@node What you can and what you cannot do in +load, Type encoding, Executing code before main, Executing code before main
+@subsection What you can and what you cannot do in @code{+load}
+
+The +load implementation in the GNU runtime guarantees you the following
+things:
+
+@itemize @bullet
+
+@item
+you can write whatever C code you like;
+
+@item
+you can send messages to Objective-C constant strings (@@"this is a
+constant string");
+
+@item
+you can allocate and send messages to objects whose class is implemented
+in the same file;
+
+@item
+the @code{+load} implementation of all super classes of a class are executed before the @code{+load} of that class is executed;
+
+@item
+the @code{+load} implementation of a class is executed before the
+@code{+load} implementation of any category.
+
+@end itemize
+
+In particular, the following things, even if they can work in a
+particular case, are not guaranteed:
+
+@itemize @bullet
+
+@item
+allocation of or sending messages to arbitrary objects;
+
+@item
+allocation of or sending messages to objects whose classes have a
+category implemented in the same file;
+
+@end itemize
+
+You should make no assumptions about receiving @code{+load} in sibling
+classes when you write @code{+load} of a class. The order in which
+sibling classes receive @code{+load} is not guaranteed.
+
+The order in which @code{+load} and @code{+initialize} are called could
+be problematic if this matters. If you don't allocate objects inside
+@code{+load}, it is guaranteed that @code{+load} is called before
+@code{+initialize}. If you create an object inside @code{+load} the
+@code{+initialize} method of object's class is invoked even if
+@code{+load} was not invoked. Note if you explicitly call @code{+load}
+on a class, @code{+initialize} will be called first. To avoid possible
+problems try to implement only one of these methods.
+
+The @code{+load} method is also invoked when a bundle is dynamically
+loaded into your running program. This happens automatically without any
+intervening operation from you. When you write bundles and you need to
+write @code{+load} you can safely create and send messages to objects whose
+classes already exist in the running program. The same restrictions as
+above apply to classes defined in bundle.
+
+
+
+@node Type encoding, Garbage Collection, What you can and what you cannot do in +load, Top
+@section Type encoding
+
+The Objective-C compiler generates type encodings for all the
+types. These type encodings are used at runtime to find out information
+about selectors and methods and about objects and classes.
+
+The types are encoded in the following way:
+
+@c @sp 1
+
+@multitable @columnfractions .25 .75
+@item @code{char}
+@tab @code{c}
+@item @code{unsigned char}
+@tab @code{C}
+@item @code{short}
+@tab @code{s}
+@item @code{unsigned short}
+@tab @code{S}
+@item @code{int}
+@tab @code{i}
+@item @code{unsigned int}
+@tab @code{I}
+@item @code{long}
+@tab @code{l}
+@item @code{unsigned long}
+@tab @code{L}
+@item @code{long long}
+@tab @code{q}
+@item @code{unsigned long long}
+@tab @code{Q}
+@item @code{float}
+@tab @code{f}
+@item @code{double}
+@tab @code{d}
+@item @code{void}
+@tab @code{v}
+@item @code{id}
+@tab @code{@@}
+@item @code{Class}
+@tab @code{#}
+@item @code{SEL}
+@tab @code{:}
+@item @code{char*}
+@tab @code{*}
+@item unknown type
+@tab @code{?}
+@item bitfields
+@tab @code{b} followed by the starting position of the bitfield, the type of the bitfield and the size of the bitfield (the bitfields encoding was changed from the NeXT's compiler encoding, see below)
+@end multitable
+
+@c @sp 1
+
+The encoding of bitfields has changed to allow bitfields to be properly
+handled by the runtime functions that compute sizes and alignments of
+types that contain bitfields. The previous encoding contained only the
+size of the bitfield. Using only this information it is not possible to
+reliably compute the size occupied by the bitfield. This is very
+important in the presence of the Boehm's garbage collector because the
+objects are allocated using the typed memory facility available in this
+collector. The typed memory allocation requires information about where
+the pointers are located inside the object.
+
+The position in the bitfield is the position, counting in bits, of the
+bit closest to the beginning of the structure.
+
+The non-atomic types are encoded as follows:
+
+@c @sp 1
+
+@multitable @columnfractions .2 .8
+@item pointers
+@tab @code{'^'} followed by the pointed type.
+@item arrays
+@tab @code{'['} followed by the number of elements in the array followed by the type of the elements followed by @code{']'}
+@item structures
+@tab @code{'@{'} followed by the name of the structure (or '?' if the structure is unnamed), the '=' sign, the type of the members and by @code{'@}'}
+@item unions
+@tab @code{'('} followed by the name of the structure (or '?' if the union is unnamed), the '=' sign, the type of the members followed by @code{')'}
+@end multitable
+
+Here are some types and their encodings, as they are generated by the
+compiler on a i386 machine:
+
+@sp 1
+
+@multitable @columnfractions .25 .75
+@item Objective-C type
+@tab Compiler encoding
+@item
+@example
+int a[10];
+@end example
+@tab @code{[10i]}
+@item
+@example
+struct @{
+ int i;
+ float f[3];
+ int a:3;
+ int b:2;
+ char c;
+@}
+@end example
+@tab @code{@{?=i[3f]b128i3b131i2c@}}
+@end multitable
+
+@sp 1
+
+In addition to the types the compiler also encodes the type
+specifiers. The table below describes the encoding of the current
+Objective-C type specifiers:
+
+@sp 1
+
+@multitable @columnfractions .25 .75
+@item Specifier
+@tab Encoding
+@item @code{const}
+@tab @code{r}
+@item @code{in}
+@tab @code{n}
+@item @code{inout}
+@tab @code{N}
+@item @code{out}
+@tab @code{o}
+@item @code{bycopy}
+@tab @code{O}
+@item @code{oneway}
+@tab @code{V}
+@end multitable
+
+@sp 1
+
+The type specifiers are encoded just before the type. Unlike types
+however, the type specifiers are only encoded when they appear in method
+argument types.
+
+
+@node Garbage Collection, , Type encoding, Top
+
+@page
+@section Garbage Collection
+
+Support for a new memory management policy has been added by using a
+powerful conservative garbage collector, known as the
+Boehm-Demers-Weiser conservative garbage collector. It is available from
+@w{@url{http://reality.sgi.com/employees/boehm_mti/gc.html}}.
+
+To enable the support for it you have to configure the compiler using an
+additional argument, @w{@kbd{--enable-objc-gc}}. You need to have
+garbage collector installed before building the compiler. This will
+build an additional runtime library which has several enhancements to
+support the garbage collector. The new library has a new name,
+@kbd{libobjc_gc.a} to not conflict with the non-garbage-collected
+library.
+
+When the garbage collector is used, the objects are allocated using the
+so-called typed memory allocation mechanism available in the
+Boehm-Demers-Weiser collector. This mode requires precise information on
+where pointers are located inside objects. This information is computed
+once per class, immediately after the class has been initialized.
+
+There is a new runtime function @code{class_ivar_set_gcinvisible()}
+which can be used to declare a so-called @strong{weak pointer}
+reference. Such a pointer is basically hidden for the garbage collector;
+this can be useful in certain situations, especially when you want to
+keep track of the allocated objects, yet allow them to be
+collected. This kind of pointers can only be members of objects, you
+cannot declare a global pointer as a weak reference. Every type which is
+a pointer type can be declared a weak pointer, including @code{id},
+@code{Class} and @code{SEL}.
+
+Here is an example of how to use this feature. Suppose you want to
+implement a class whose instances hold a weak pointer reference; the
+following class does this:
+
+@example
+
+@@interface WeakPointer : Object
+@{
+ const void* weakPointer;
+@}
+
+- initWithPointer:(const void*)p;
+- (const void*)weakPointer;
+@@end
+
+
+@@implementation WeakPointer
+
++ (void)initialize
+@{
+ class_ivar_set_gcinvisible (self, "weakPointer", YES);
+@}
+
+- initWithPointer:(const void*)p
+@{
+ weakPointer = p;
+ return self;
+@}
+
+- (const void*)weakPointer
+@{
+ return weakPointer;
+@}
+
+@@end
+
+@end example
+
+Weak pointers are supported through a new type character specifier
+represented by the @code{'!'} character. The
+@code{class_ivar_set_gcinvisible()} function adds or removes this
+specifier to the string type description of the instance variable named
+as argument.
+
+
+@bye
+
projects / gcc.git / commitdiff