
Mulle-objc: A New Objective-C Compiler and Runtime - WoodenChair
https://mulle-objc.github.io
======
pavlov
The biggest change so far seems to be a new memory management style called
AAM, "Always Autorelease Mode". It's described on the compiler's Github page:

[https://github.com/Codeon-GmbH/mulle-clang](https://github.com/Codeon-
GmbH/mulle-clang)

 _" The transformed methods will return objects that are autoreleased. Hence
the name of the mode. The net effect is, that you have a mode that is ARC-
like, yet understandable and much simpler."_

This is like a halfway house between traditional Objective-C's "semi-manual"
memory management, and the modern ARC (Automatic Reference Counting).
Autorelease pools were a cornerstone of the traditional model: autoreleased
objects will typically stick around until the end of the event loop cycle,
which was a reasonable way to do garbage collection in mostly UI-centric Obj-C
apps.

ARC replaced this model with static reference tracking in the compiler:
instances are freed when the compiler knows that the last reference has gone
out of scope. This is obviously more memory-efficient than the autorelease
pool, and that was probably a big factor in Apple's decision to go with ARC
(as the primary focus of Obj-C had shifted to iOS).

In summary, the Mulle compiler tries to combine the programmer ease-of-use of
ARC with the simpler compiler/runtime implementation of traditional Obj-C
memory management. The tradeoff is memory usage and incompatibility with some
modern code that assumes an ARC compiler.

Here's a list of language features that the compiler will support:

[https://www.mulle-
kybernetik.com/weblog/2015/mulle_objc_pres...](https://www.mulle-
kybernetik.com/weblog/2015/mulle_objc_present_and_absent.html)

Personally I agree with the author's positions in principle, but not entirely
in practice. In particular, not supporting the property dot syntax will make
it unnecessarily difficult to compile most Obj-C code written since about
2009. Same goes for blocks -- they're very integrated in Obj-C APIs by now,
even though it does add substantial runtime complication.

~~~
mpweiher
> autoreleased objects will typically stick

> around until the end of the event loop cycle

They stick around until their reference count drops to zero. The -autorelease
is turned into a -release when the containing autorelease pool is released, so
you have full control over when that happens.

    
    
       @autoreleasepool {
          [[[NSObject alloc] init] autorelease];
       } 
    

The object is freed at the end of that block.

Yes, there is a default autorelease pool for the event loop.

~~~
pavlov
I know. That's why I wrote "typically".

------
pjmlp
The best thing of this was the link about "Spirit of C", which shows that even
ANSI agrees thrusting the programmer is no longer a good idea.

"12\. Trust the programmer, as a goal, is outdated in respect to the security
and safety programming communities. While it should not be totally disregarded
as a facet of the spirit of C, the C11 version of the C Standard should take
into account that programmers need the ability to check their work."

~~~
generic_user
In practical terms its not very dramatic. C11 allows you to check and set
exact alignment with alignof alignas. There are also bounds checking (_s)
functions that set errno messages on overflow. Also _Generic can give
automatic type deduction in certain cases.

All of these things simply help you 'check your work'. Bounds checking has
been standard good practice for years now so its not a surprise they put that
in the standard library. There is still no magic and its the programmer who
has to put forward the effort to check for errors.

~~~
pjmlp
> Bounds checking has been standard good practice for years now so its not a
> surprise they put that in the standard library.

Not really, It has been removed from the standard library and made an optional
Annex. A C11 compliant compiler is not required to provide them.

For me those "secure" functions are just as insecure as their cousins, because
they still require C developers to track pointers and bounds separately.

The only thing they improve in regards to security is not forcing us to
manually place a null character at the very end, in case the destinations are
filled up. But the danger of passing the wrong length, origin or destination
is still there.

~~~
generic_user
I think threads, atomics and bounds checking were all TR proposals up until
C11. Then they added the conditional (optional) features. Threads and atomics
are mandatory and bounds checking and 'analyzability' are conditional.

If you have to deal with strings in C more then likely you have written a
string interface with bounds checking. Its not clear if it needs to be
standard so its good that its optional. Icc, gcc and clang support it so I
would not hesitate to use it.

My point was that 'safety' in C is still more or less a process of training
the programmer rather then a language feature. And that was and still is a
design goal. But at least now you can point to the bounds checking functions
and other new features as an example of how to get there.

I'm not going to argue whether C is safe. Or whether XYZ is safer then C.
Thats way of topic.

------
ori_b
I wasn't aware that there was something wrong with the old compilers. Reading
the page, I'm still not aware of the motivations behind this.

What does this compiler do better/different than clang or gcc?

~~~
rweichler
Apple's objective C runtime is not portable. There's a lot of assembly code
and platform specific code. This is trying to fix that.

~~~
eridius
Doesn't at least objc_msgSend have to be assembly?

~~~
chrisseaton
No. Why? What's magic about assembly code that means you couldn't do the same
thing in C?

~~~
ksherlock
the objc_msgSend function doesn't know what it's return type is or how many
arguments it has. It needs to lookup the actual function then jump to it
without modifying the stack or any of the parameter registers. It simply
doesn't follow the calling conventions and C can't handle it.

~~~
chrisseaton
Right, true. I guess I'm used to working on languages where you can stick
everything into a uint64, but that isn't the case with something like returned
structs. if you controlled the calling convention you could do it in C.

~~~
eridius
It appears that controlling the calling convention is exactly what Mulle-objc
is doing. It's layering a new convention on top of C calling conventions,
where objc_msgSend() is given a pointer to a struct containing the arguments.
This way the compiler can synthesize the struct for you, and objc_msgSend()
itself can be written in vanilla C.

------
heisenbit
Apple used to be the sponsor of Objective C for a long time. Was Apple's focus
on Swift prompting this? From his documentation page:

> About mulle-objc

> When I wrote the Optimizing Objective-C Article Series, Objective-C had
> pretty much weathered its first hostile obsolesence attempt by Java. Now a
> decade later, it looks like the time has come, that I have to save
> Objective-C - at least for myself.

~~~
pjmlp
Apple is pretty open that they plan to use Swift to replace C and Objective-C
on their stack.

[https://developer.apple.com/swift/](https://developer.apple.com/swift/)

"Swift is a successor to both the C and Objective-C languages."

Of course this is something that will not happen overnight and the language is
still has some corners to fine tune.

Objective-C improved a lot since the NeXT days, but the C part is still there,
regardless of the safety improvements it got on top.

Also since Swift has been announced, the only language improvements
Objective-C got were related to improving the interoperability between both
languages.

So I imagine some devs that are passionate about Objective-C might not like
the day Objective-C joins Carbon and MPW.

I surely did not like when that hapenned to Object Pascal, Mac Common Lisp or
Dylan.

~~~
groovy2shoes
> I surely did not like when that hapenned to Object Pascal, Mac Common Lisp
> or Dylan.

The difference here being that Objective-C is unsafe, and its relatively low
level of abstraction in comparison to the aforementioned languages, make it
less than ideal as an applications language, especially compared to those
languages. As you say, "the C part is still there".

I'm with you. I want to be using safer languages, both because there is
inherent value in safety, and because safety tends to come with more and
better tools for building abstractions.

While I lament the loss of Obj-Pas, MCL, and Dylan, I whole-heartedly welcome
the arrival of Swift. Even if it means nothing to me directly anymore as an
apostate of the Apple platform, I hope that it will fuel a push for better,
safer languages across the board. In many ways, I think technologies like MCL
and Dylan were victims of being ahead of their time.

These are exciting times to live in as a programming language geek/snob, as
the lessons of the past are finally rediscovered, absorbed, and made
practical, popular, and cool :)

~~~
pjmlp
Fully agree with you.

------
coldcode
While I find this an interesting experiment, after nearly 18 years of
Objective-C dating back to NeXT I have no desire to go back after switching to
Swift. The future (at least some part of it) belongs to modern languages like
Swift, Rust, Clojure, etc.

------
EddieSpeaks
Why?

------
cagataygurturk
"Let's make Objective-C great again"

