site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com the 40 probably comes from Thanks, that's cleared up a lot of things! Cheers, -- M. Uli Kusterer http://www.zathras.de _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Am 03.11.2006 um 23:43 schrieb Jonas Maebe: All PPC ABI's used by Apple have always required a 16 byte aligned stack afaik, there's nothing G4-specific about that. Well, I just remember that RealBASIC or somesuch compiler had a problem with menu text colors all going wonky because they didn't align the stack properly, and apparently that didn't show on G3s, but showed on G4s when Apple used more AltiVec-optimized code. I guess that also fits your explanation below. and later hearing Intel was the same, but Intel's docs said differently. Well, the Intel cpus don't require a 16 byte aligned stack, but several MMX/SSE instructions do require a 16 byte aligned addresses and having the stack aligned at 16 bytes makes it easier to guarantee that. If that's also true for AltiVec, that would explain what I saw. It may have been recommended to be 16-byte-aligned on G3, but it wasn't strictly necessary. Thanks for clearing that up. that would be 8. Instead it's 40. Without the corresponding C code, it's hard to say why exactly the compiler is doing that. The code is ridiculously simple: As Eric mentioned, if you turn on optimizations the stack frame disappears. Without optimization, Well, I just tried O1, and that actually prints out slightly better code. I was avoiding that initially because I thought unoptimized code would be closest to the original C source code. E.g. O3 would have been pretty stupid, because it does constant folding and thus not even calls addNumbers() but rather just inserts 12 in its place... * 8 to align the stack pointer to a multiple of 16 (it was at 8 because of the return address of the caller and the "push %ebp") * 4 for the local variable, rounded up to a multiple of 16 * 8 for the parameters to the subroutine, rounded up to a multiple of 16. So, my app will be launched with a mis-aligned stack? Aha! That also explains the (seemingly pointless) subl $8, %esp at the start of even empty functions. So, whenever I enter a function, the stack will be at 4 because the return address has been pushed? This email sent to site_archiver@lists.apple.com