Comments on: Nil

by: madfox

Sun, 29 May 2005 19:25:32 +0000

A pretty interesting article about Application Binary Interface of powerpc.

by: Dominik Wagner

Mon, 30 May 2005 12:51:52 +0000

Very nice insight! Keep the good stuff coming! I never thought of [nil something] to not return a kind of zero. Thanks for pointing this out. This will help in some weird debugging moment - (i already had too much of them anyway ;-) )

by: Daniel Jalkut

Mon, 30 May 2005 13:21:16 +0000

Cool stuff. I had never thought much about objc_msgSend_stret, except to know that it was “different.” Now you’ve motivated me to figure out what the new “objc_msgSend_rtp” calls are that I’m seeing all over the place in Tiger.

Hmm, nothing in the obj_msg_ppc.s file you linked to. Nothing by searching ADC. Lots of stack crawls from crash descriptions by searching Google.

Aha! Obviously, I have to look at the obj_msg_ppc.s source from Tiger. There it is, in all it’s confusing (to me) glory. It has something to do with “runtime pages.” OK, on Tiger there is a copy of objc_msgSend in high-memory at address 0xfffeff00. I guess it’s some kind of performance optimization to allow apps to do an absolute branch to the subroutine. I don’t know much beyond that, but it’s nice to know that it’s “basically just objc_msgSend” :)

I look forward to more articles like this. Good stuff!

by: Kevin Ballard

Mon, 30 May 2005 17:09:37 +0000

It’s great to get an official answer on this. After tracking down a heisenbug I figured that [nil returnFloatingPointValue] probably just returned whatever was in FP1 when called, but I wasn’t sure. Thanks for clearing this up (and pointing out the problem with long long as well - I didn’t know about that one).

by: Quarter Life Crisis

Mon, 30 May 2005 17:54:39 +0000

Running

Because it went rather well in November and many people asked to have another one, we are having another Running Dinner this weekend. We wanted this to be really...

by: Bjoern Kriews

Tue, 31 May 2005 01:16:29 +0000

Very interesting read - please keep it coming - and make sure it gets included in the docs on the runtime :-). Thank you very much.

by: Dougal

Tue, 31 May 2005 05:27:23 +0000

Cool - an interesting read there. Please keep more of them coming!

by: Cliff L. Biffle

Tue, 31 May 2005 15:21:59 +0000

This actually explains some oddities I was tracking down.

It pretty much supports my current policy, derived from one too many heisenbugs: “Don’t send to nil if you can help it.” :-)

Looking forward to more!

by: Ian Ameline

Tue, 31 May 2005 18:58:13 +0000

Awesome blog — I’ll definitely be following it.

I’ve recently switched my primary development machine to be my mac, and It’s so much nicer.

Now — how bad would it be (from a performance standpoint) to move 0 into fp1 when you go down that path for sending a message to nil, thus eliminating a class of bugs. And in the case of struct returns, how bad would it be to fill the return struct with all 0’s in the case of sending to nil?

In my opinion, it would not result in any noticable performance penalty (I’m assuming that messages passed to nil are the exception, not the rule), and could result in increased stability of apps running on this platform.

What do you think?

Regards,
Ian Ameline,
Software Architect,
Alias Sketchbook Pro.

by: ridiculous_fish

Tue, 31 May 2005 19:11:48 +0000

> Now — how bad would it be (from a performance standpoint) to move 0 into fp1 when you go
> down that path for sending a message to nil, thus eliminating a class of bugs. And in the case of
> struct returns, how bad would it be to fill the return struct with all 0’s in the case of sending to nil?

Moving 0 into fp1, to make float and double returns 0, would be very cheap. And while you’re at it, moving 0 into r4, to make long long returns 0, would be even cheaper. But doing this with structs would probably require substantial runtime changes, since the objc_msgSend_stret() function doesn’t know how big the struct return must be.

> In my opinion, it would not result in any noticable performance penalty (I’m assuming that
> messages passed to nil are the exception, not the rule), and could result in increased stability
> of apps running on this platform.

I agree with you, and I’ve asked this before. The answer I was given was that Apple doesn’t want to “special case” floats, doubles, and long longs since there’s not a ready solution for the general case.

You can see the conversation I had on Usenet.