From owner-freebsd-sparc Sun Jan 12 14:32:50 2003 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D05237B401 for ; Sun, 12 Jan 2003 14:32:49 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 715DA43F7C for ; Sun, 12 Jan 2003 14:32:42 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h0CKtPjb005743; Sun, 12 Jan 2003 15:55:25 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h0CKtPqV005742; Sun, 12 Jan 2003 15:55:25 -0500 (EST) Date: Sun, 12 Jan 2003 15:55:25 -0500 From: Jake Burkholder To: John Polstra Cc: sparc@FreeBSD.ORG Subject: Re: Question about odd stack pointer values on sparc64 Message-ID: <20030112155525.K212@locore.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdp@polstra.com on Sun, Jan 12, 2003 at 12:44:44PM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Sun, Jan 12, 2003 at 12:44:44PM -0800, John Polstra said words to the effect of; > Still working on getting Modula-3 going on Sparc64. I think I'm > getting close ... > > In GDB I notice that the stack pointer and frame pointer are often > (always?) odd numbers, e.g.: > > (gdb) p/x $sp > $1 = 0x7fdffffdec1 > (gdb) p/x $fp > $2 = 0x7fdffffdfb1 > > What is the reason for that? Are the low-order bits simply ignored? > Surely the stack is more aligned than that. > > I'm pretty sure this is confusing the M3 garbage collector. It just > might be the proverbial Last Bug. :-) Its because the stack is offset by -2047, to get the real stack pointer add 2047. If you look at how gcc addresses stack variables you'll see it adding in the bias. As for reasons why this was done, apparently it allows a larger region of stack to be addressed with 13 bit immediate offsets, also 32 bit sparc code doesn't use a stack bias so it can be distinguished by testing the alignment of the unmodified stack pointer. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message