* RENAMED: too many methods to list

* did some work on the big bang, for MulleObjC benefit

Author: mulle-nat

RELEASENOTES.md

@@ -8,7 +8,7 @@
 ## 0.12.1
 
 * _MULLE_OBJC_CLASS_HAS_CLEARABLE_PROPERTY replaces _MULLE_OBJC_CLASS_HAS_RELEASABLE_PROPERTY
-* _mulle_objc_object_nonatomic_infiniteretain replaces _mulle_objc_object_nonatomic_infinite_retain
+* _mulle_objc_object_infiniteretain_noatomic replaces _mulle_objc_object_nonatomic_infinite_retain
 * Adapt runtime to __MULLE_OBJC_FMC__ to compile without fast methods
 * adapt search so that we a root class inheriting from protocolclasses, also inherits the infraclass methods from the first protocolclass
 * adapted call functions to the new way of calling super, where the classid of the calling class is passed (no longer the superclassid)
@@ -87,7 +87,7 @@ It should now be possible to initialize a global universe from multiple threads.
 It should not be necessary to set the global universe up from a single thread,
 before starting other threads.
 
-Only use `mulle_objc_get_or_create_universe` during loading. Makes it easier.
+Only use `mulle_objc_register_universe` during loading. Makes it easier.
 
 Also distribute mulle-objc-uniqueid.
 
@@ -134,7 +134,7 @@ collisions
 * renamed _size_of_ functions to _sizeof_ as its more c like
 * renamed has_category/has_protocol and related functions to has_categoryid/has_protocolid,
 because it is less confusing
-* removed misleading mulle_objc_string_for_ivarid and friends (use class to get
+* removed misleading mulle_objc_describe_ivarid and friends (use class to get
 the names)
 
 ## 0.7.1
@@ -144,7 +144,7 @@ the names)
 * moved some more call functions into "...call.c" (duh)
 * moved version and new "path" up for easier debugging and easier version
 checks its kinda useful if version is at a fixed offset
-* `__get_or_create_objc_runtime` has been renamed to `__get_or_create_mulle_objc_runtime`
+* `__get_or_create_objc_runtime` has been renamed to `__register_mulle_objc_universe`
 for clarity in the debugger and multi-universe code.
 * moved forward into a fixed position in the class structure for a future
 debugger

cmake/_Headers.cmake

@@ -43,6 +43,7 @@ src/mulle-objc-fnv1.h
 src/mulle-objc-infraclass.h
 src/mulle-objc-ivar.h
 src/mulle-objc-ivarlist.h
+src/mulle-objc-jit.inc
 src/mulle-objc-kvccache.h
 src/mulle-objc-load.h
 src/mulle-objc-metaabi.h

dox/API_CLASS.md

@@ -31,7 +31,7 @@ int   mulle_objc_class_add_methodlist( struct _mulle_objc_class *cls,
                                        struct _mulle_objc_methodlist *list)
 ```
 
-Add methodlist `list` to `cls`. The methodlist isn't copied, so be sure that is sticks around for the lifetime of the runtime. (Check out `mulle_objc_runtime_unfailing_add_gift`)
+Add methodlist `list` to `cls`. The methodlist isn't copied, so be sure that is sticks around for the lifetime of the runtime. (Check out `mulle_objc_universe_add_gift_nofail`)
 
 
 ### `mulle_objc_classpair_add_protocolid`

dox/API_EXCEPTION.md

@@ -28,6 +28,6 @@ This may be of interest if you are writing a compiler for the runtime.
 Relevant links:
 
 [clang](//github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CGObjCMac.cpp#L4020)
-[mulle_objc_exception_try_enter.h](../src/mulle_objc_exception_try_enter.h)
-[mulle_objc_exception_try_enter.c](../src/mulle_objc_exception_try_enter.c)
+[mulle_objc_exception_tryenter.h](../src/mulle_objc_exception_tryenter.h)
+[mulle_objc_exception_tryenter.c](../src/mulle_objc_exception_tryenter.c)
 

dox/API_LOADINFO.md

@@ -1,25 +1,25 @@
 # LoadInfo : Loading Classes, Categories, Strings
 
 Classes, categories, static strings are all added with the same function
-`mulle_objc_loadinfo_unfailing_enqueue`. Usually the compiler produces these calls automatically for you.
+`mulle_objc_loadinfo_enqueue_nofail`. Usually the compiler produces these calls automatically for you.
 
 ## Functions
 
-### `mulle_objc_loadinfo_unfailing_enqueue`
+### `mulle_objc_loadinfo_enqueue_nofail`
 
 ```
-void   mulle_objc_loadinfo_unfailing_enqueue( struct _mulle_objc_loadinfo *info)
+void   mulle_objc_loadinfo_enqueue_nofail( struct _mulle_objc_loadinfo *info)
 ```
 
 Take `info` and queue the contained classes, categories, strings up for inclusion into the runtime. If the base class of a class or category is already present, it will be added immediately to the runtime. Otherwise the inclusion will be delayed until the base class appears.
 
-The **unfailing** in `mulle_objc_loadinfo_unfailing_enqueue` indicates, that the function will throw an exception or abort, if the runtime is not properly setup or if it detects errors in `info`.
+The **unfailing** in `mulle_objc_loadinfo_enqueue_nofail` indicates, that the function will throw an exception or abort, if the runtime is not properly setup or if it detects errors in `info`.
 
-This information is usually created by the compiler, but if you want to add a class at runtime, you would also do it via `mulle_objc_loadinfo_unfailing_enqueue`.
+This information is usually created by the compiler, but if you want to add a class at runtime, you would also do it via `mulle_objc_loadinfo_enqueue_nofail`.
 
 Checkout [demo1.c](../tests/demo/demo1.c) for a fairly well documented example, how to do this.
 
-> `mulle_objc_loadinfo_unfailing_enqueue` will treat the contents of
+> `mulle_objc_loadinfo_enqueue_nofail` will treat the contents of
 >  `_mulle_objc_loadinfo` as if they are in read only memory, with all
 > its implications, with respect to lifetime and mutability.
 

dox/API_OBJECT.md

@@ -24,37 +24,37 @@ The non-inlining variant of sending a message to an object (calling an objects m
 `obj` must be a pointer to a valid object or NULL.
 
 
-### `mulle_objc_object_constant_methodid_call`
+### `mulle_objc_object_partialinlinecall_constantmethodid`
 
 ```
-void  *mulle_objc_object_constant_methodid_call( void *obj,
-                                                 mulle_objc_methodid_t methodid,
-                                                 void *parameter)
+void  *mulle_objc_object_partialinlinecall_constantmethodid( void *obj,
+                                                             mulle_objc_methodid_t methodid,
+                                                             void *parameter)
 ```
 
 This is an optimized variant of `mulle_objc_object_call` in cases, where
 `methodid` is a known constant. The compiler uses this method when optimizing
 with -O1.
 
-Right: `mulle_objc_object_constant_methodid_call( self, 0x1848, NULL)`,
-Wrong: `mulle_objc_object_constant_methodid_call( self, _cmd, NULL)
+Right: `mulle_objc_object_partialinlinecall_constantmethodid( self, 0x1848, NULL)`,
+Wrong: `mulle_objc_object_partialinlinecall_constantmethodid( self, _cmd, NULL)
 
 
-### `mulle_objc_object_inline_constant_methodid_call`
+### `mulle_objc_object_inlinecall_constantmethodid`
 
 ```
-void  *mulle_objc_object_inline_constant_methodid_call( void *obj,
-                                                        mulle_objc_methodid_t methodid,
-                                                        void *parameter)
+void  *mulle_objc_object_inlinecall_constantmethodid( void *obj,
+                                                      mulle_objc_methodid_t methodid,
+                                                      void *parameter)
 ```
 
 This is an even further optimized variant of `mulle_objc_object_call` in cases,
 where `methodid` is a known constant. The compiler uses this method when
 optimized with -O2 and up. Frequent use of this function can increase the size
 of your executable by quite a bit.
 
-Right: `mulle_objc_object_inline_constant_methodid_call( self, 0x1848, NULL)`,
-Wrong: `mulle_objc_object_inline_constant_methodid_call( self, _cmd, NULL)
+Right: `mulle_objc_object_inlinecall_constantmethodid( self, 0x1848, NULL)`,
+Wrong: `mulle_objc_object_inlinecall_constantmethodid( self, _cmd, NULL)
 
 
 ### `mulle_objc_object_call_classid`

dox/API_UNIVERSE.md

@@ -65,7 +65,7 @@ other.
 
 Parametername       |  Description
 --------------------|----------------------
-`universe`          | Pointer to the universe, must not be NULL. Use `__get_or_create_mulle_objc_universe` (not `mulle_objc_get_universe`) to get the proper one for your thread
+`universe`          | Pointer to the universe, must not be NULL. Use `__register_mulle_objc_universe` (not `mulle_objc_get_universe`) to get the proper one for your thread
 `classid`           | Compute the `classid` from `name` with `mulle_objc_classid_from_string`
 `name`              | The name of the class, this must be a non-empty ASCII string. This string is not copied. It must remain alive for the duration of the class's existence.
 `instance_size`     | The space needed for instance variables (don't add the header size)
@@ -97,7 +97,7 @@ struct _mulle_objc_class       *cls;
 char                           *name;
 mulle_objc_classid_t           classid;
 
-universe =  __get_or_create_mulle_objc_universe();
+universe =  __register_mulle_objc_universe();
 name    = "Foo";
 classid = mulle_objc_classid_from_string( name);
 pair    = mulle_objc_universe_new_classpair( universe, classid, name, 0, NULL);

dox/USE.md

@@ -6,49 +6,34 @@ error-prone.
 (See the few examples in `tests/`).
 
 
-## The missing function `__get_or_create_mulle_objc_runtime`
+## The missing function `__register_mulle_objc_universe`
 
 The runtime needs an external function to work. This initializer function
-is called `__get_or_create_mulle_objc_runtime`.
+is called `__register_mulle_objc_universe`.
 
 Here is a minimal implementation:
 
 ```
 MULLE_C_CONST_RETURN  // always returns same value (in same thread)
-struct _mulle_objc_runtime  *__get_or_create_mulle_objc_runtime( void)
+struct _mulle_objc_universe  *__register_mulle_objc_universe( void)
 {
-   struct _mulle_objc_runtime  *runtime;
+   struct _mulle_objc_universe   *universe;
 
-   runtime = __mulle_objc_get_runtime();
-   if( ! _mulle_objc_runtime_is_initalized( runtime))
-      __mulle_objc_runtime_setup( runtime, NULL);
-   return( runtime);
+   universe = __mulle_objc_get_universe();
+   if( ! _mulle_objc_universe_is_initialized( universe))
+      _mulle_objc_universe_bang( universe, bang, NULL, NULL);
+
+   return( universe);
 }
 ```
 
-You may want to tweak the runtime when running the `__mulle_objc_runtime_setup`
+You may want to tweak the runtime when running the `_mulle_objc_universe_bang`
 branch of the `if`.
 
 > You should not change this runtime after returning it to the caller for the first time.
 
 If you want to write a Foundation yourself, check out the "foundation" spaces
-available to you in `struct _mulle_objc_runtime` and `struct _mulle_objc_threadconfig`.
-
-
-# Headers
-
-MulleObjC wants to serve several masters
-
-* C code compiled as C code (.c)
-* Any C or Objective-C code compiled as Objective-C code (.m)
-
+available to you in `struct _mulle_objc_universe` and `struct _mulle_objc_threadinfo`.
 
-Objective-C code gets everything, you #import <MulleObjC/MulleObjC.h>.
-If you want to compile .c, you usually don't want the inclusion of
-mulle-objc-runtime. Then you include <MulleObjC/ns-c.h>. This gives you
-access to a runtime-independent subset. (maybe should be elsewhere ?)
 
-If you have for some strange reason a C-compiler but no mulle-clang compiler,
-and the compiled binaries, yet want to use some more MulleObjC + the runtime
-yo include <MulleObjC/C.h
 

dox/global_runtime.dot

@@ -7,8 +7,8 @@ digraph global_concept
 
   "thread (1)" -> "_mulle_objc_runtime"
   "thread (n)" -> "_mulle_objc_runtime"
-  "thread (1)" -> "_mulle_objc_threadconfig (1)"
-  "thread (n)" -> "_mulle_objc_threadconfig (n)"
+  "thread (1)" -> "_mulle_objc_thread_config (1)"
+  "thread (n)" -> "_mulle_objc_thread_config (n)"
 
    node [shape="note"];
 

dox/load/LOAD.md

@@ -61,8 +61,8 @@ GNUStep basically guarantees nothing. `+load`s are performed as they are coming
 
 ## Call `+load` before or after addition to runtime ?
 
-One question is, if `+load` should be called before the class or category 
-is added to the runtime system or after. If the `+load` is called before 
+One question is, if `+load` should be called before the class or category
+is added to the runtime system or after. If the `+load` is called before
 the addition, the following functionality is unavailable in `+load`:
 
 #### For classes
@@ -78,9 +78,9 @@ This is not desirable and expected by the user (class programmer). Is it avoidab
 
 ## +load in mulle-objc-runtime
 
-The **mulle-objc-runtime** allows classes and categories to specify arbitrary dependencies on other classes and categories for `+load` calls. It is the 
+The **mulle-objc-runtime** allows classes and categories to specify arbitrary dependencies on other classes and categories for `+load` calls. It is the
 burden of the `+load` author to ensure, that there are no cycles.
- 
+
 The **mulle-objc-runtime** automatically detects dependencies on superclasses and
 protocolclasses for classes. It detects dependencies on its base class and protocolclasses for categories.
 
@@ -111,7 +111,7 @@ Each dependency either specifies the missing classid for a class, or the missing
 5. A class or category who's dependencies are not satisfied, is not added to
    the runtime system immediately. Instead its addition is postponed, until
    the requirements are met.
-   
+
 ### Other consequence of this design
 
 Other C `__attribute__(constructor)` code and C++ initializers are unsequenced in relationship to `+load`. Shared libraries do not impose a sequencing order nor do they imply `+load` execution guarantees for contained loadable.
@@ -123,7 +123,7 @@ If a category does override `+initialize`, it should query the state bit with `_
 The MulleObjCFoundation for example guarantees, that its classes or categories
 do not trigger `+initialize` during `+load`.
 
-   
+
 ## How classes and categories are loaded in mulle-objc-runtime
 
 
@@ -132,7 +132,7 @@ do not trigger `+initialize` during `+load`.
 > is called a loadable for short.
 
 
-If we assume, that the executable is composed of a complete set of loadcategories and loadclasses without missing dependencies, then all classes and categories will be installed ahead of `main`. They get installed via `__attribute__((constructor))` function calls to `mulle_objc_loadinfo_unfailing_enqueue`, the **mulle-clang** compiler emits:
+If we assume, that the executable is composed of a complete set of loadcategories and loadclasses without missing dependencies, then all classes and categories will be installed ahead of `main`. They get installed via `__attribute__((constructor))` function calls to `mulle_objc_loadinfo_enqueue_nofail`, the **mulle-clang** compiler emits:
 
 ![Excecutable](executable.svg)
 

dox/load/executable.dot

@@ -15,11 +15,11 @@ digraph executable
    }
 
 
-   "executable"     -> "a.o"    -> "__attribute_constructor( a.o)"    -> "mulle_objc_loadinfo_unfailing_enqueue( &a.loadinfo)";
-   "executable"     -> "b.o"    -> "__attribute_constructor( b.o)"    -> "mulle_objc_loadinfo_unfailing_enqueue( &b.loadinfo)";
-   "executable"     -> "main.o" -> "__attribute_constructor( main.o)" -> "mulle_objc_loadinfo_unfailing_enqueue( &main.loadinfo)";
+   "executable"     -> "a.o"    -> "__attribute_constructor( a.o)"    -> "mulle_objc_loadinfo_enqueue_nofail( &a.loadinfo)";
+   "executable"     -> "b.o"    -> "__attribute_constructor( b.o)"    -> "mulle_objc_loadinfo_enqueue_nofail( &b.loadinfo)";
+   "executable"     -> "main.o" -> "__attribute_constructor( main.o)" -> "mulle_objc_loadinfo_enqueue_nofail( &main.loadinfo)";
    "executable"     -> "shared library"
-   "shared library" -> "c.o"    -> "__attribute_constructor( c.o)"    -> "mulle_objc_loadinfo_unfailing_enqueue( &c.loadinfo)";
+   "shared library" -> "c.o"    -> "__attribute_constructor( c.o)"    -> "mulle_objc_loadinfo_enqueue_nofail( &c.loadinfo)";
 
    { rank = same; "int main( argc, argv)" }