And the result was
lis r2,ha16(L_kCFAllocatorDefault$non_lazy_ptr)
li r4,0
li r5,0
lwz r2,lo16(L_kCFAllocatorDefault$non_lazy_ptr)(r2)
li r6,0
lwz r3,0(r2)
b L_CFDictionaryCreateMutable$stub
(I tried enabling no-dynamic-PIC but it didn't make a difference.)
Then I substituted in NULL and got:
li r3,0
li r4,0
li r5,0
li r6,0
b L_CFDictionaryCreateMutable$stub
That is, in fact, a two instruction difference, which is about what I
was thinking it would be.
That's also not counting the extra space in the linker's load table
for the kCFAllocatorDefault symbol; I truly wouldn't worry about that
in the least, but it is a non-zero space cost.
Anyway, you can't synthesize a load out of thin air :)
On Jul 31, 2005, at 10:44 PM, Laurence Harris wrote:
On 7/31/05 1:46 PM, John Stiles didst favor us with:
I was never actually a fan of kCFAllocatorDefault. The biggest
reason was that early versions of CarbonLib didn't even export that
symbol, so you can't use it in code that targets pre-OS 9.0. That's
a non- issue nowadays, but there's still no advantage to using the
named "constant"--there is a disadvantage, however, because in this
case it's not as efficient as a regular constant! The headers define
it as
/* This is a synonym for NULL, if you'd rather use a named
constant. */
CF_EXPORT const CFAllocatorRef kCFAllocatorDefault;
Which means that every time you use it, the compiler goes and looks
it up in memory instead of just sticking a zero into r3 like it
could if you use NULL. Larger code size for no benefit.
Neither of these issues are really a big deal--the cost of the load
is one or two extra opcodes, and nobody supports Mac OS 8 any more.
So nowadays you can use whichever technique you prefer. Personally
I'll stick with the smaller code size, since I'm used to seeing NULL
as the allocator anyway.
Just for the record, I tested this and there is no difference in
code size.
Since there's no difference in the size or the performance of the
resulting
code, and any difference in time to compile would be impossible to
quantify
in a real application, I see no reason not to use the
kCFAllocatorDefault
constant name.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
