Re: NSMakePoint and such - what about memory allocation?
Re: NSMakePoint and such - what about memory allocation?
- Subject: Re: NSMakePoint and such - what about memory allocation?
- From: Jim Witte <email@hidden>
- Date: Fri, 21 May 2004 22:16:58 -0500
Couldn't a smart compiler, just as it turns NSPoint(50,50) into the
direct-assignment statements, do something similar to this (in
something almost resembling ARM assembly):
ehm... you do know that C is a standard, and compilers should adhere
to it rather than introduce "smart" new notation on their own? :)
Yes, but if p = NSPoint(50,50) where p is an automatic variable, and
is thus allocated as a record on the stack, which is then assigns
directly, as
(p is at StackPtr)
50 <- StackPtr
50 <- StackPtr+4
then it isn't much of a stretch to take NSMakeLine(NSPoint(x,y) ,
NSPoint(x1,y1) ) which is equivalent to
p1 = NSPoint(x,y)
p2 = NSPoint(x1,y1)
NSMakeLine(p1, p2)
where p1 and p2 are still automatic variables, so this sequence becomes
(p1 is at stackPtr, p2 is at stackPtr+8)
x <- stackPtr
y <- stackPtr+4
x1 <- stackPtr+8
y2 <- stackPtr+16
NSMakeLine(stackPtr, stackPtr+8)
Okay, since 1) these automatic stack-allocated variables from NSPoint()
will (by the definition of automatic variables) be erased when the
function scope ends, AND 2) since they are not stored in any variable,
they can be put into registers, instead of on the (more) permanent
stack, since the CANNOT be used after NSMakeLine, as they are not
stored in any variable.
So the register optimization can be performed (if this doesn't
conflict with any other register-coloring going on, such as a
loop-counter placement), with the certainty that the original intent of
the code is NEVER disrupted, as all the above transformations all
preserve the truth of the statement.
Jim
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.