From owner-pro64-contrib@oss.sgi.com Tue Jul 31 03:08:36 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VA8aH15362 for pro64-contrib-outgoing; Tue, 31 Jul 2001 03:08:36 -0700 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VA8XV15358 for ; Tue, 31 Jul 2001 03:08:33 -0700 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 314F249BF for ; Tue, 31 Jul 2001 09:43:29 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 925DA4961; Tue, 31 Jul 2001 09:43:33 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2A1381846 for ; Tue, 31 Jul 2001 09:43:33 +0000 (GMT) Received: from harpo ([164.129.14.93] helo=st.com) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 15RW3j-0002wt-00 for pro64-contrib@oss.sgi.com; Tue, 31 Jul 2001 10:43:27 +0100 Message-ID: <3B667F5C.D4E17637@st.com> Date: Tue, 31 Jul 2001 10:50:20 +0100 From: "Benedict R. Gaster" Organization: STMicroelectronics X-Mailer: Mozilla 4.7 [en-gb] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: pro64-contrib@oss.sgi.com Subject: Layout of stack frame Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk Hello, We have been working on porting the Pro64 to a new risc style processor and have for the last week or so had the compiler generating code, albeit not completly correct due to stack frame layout being wrong. Our ABI states that, in general, a stack frame takes the form: |--------------------------------| Previous SP 8-byte aligned | Parameter Register Save Area | |--------------------------------| 8-byte aligned | Register Save Area | | |--------------------------------| | direction of stack growth | Local variables Area | \/ |--------------------------------| <--- SP or FP, 8-byte aligned | Dynamic Variable Area | |--------------------------------| | Argument Area (for calls) | |---------------------------------| 8-byte aligned The default stack alignment, set in data_layout.cxx, is 8-bytes, unlike the IA64, which seems to be 16. Currently compiling the following program, at -O0,: int foo(int x, int y) { int local = 100; return x + y + local; } produces the stackframe |-----------------| | SP-0: local | |-----------------| | SP-8: x | | SP-12: y | |-----------------| <------ SP after function prolog. The problem is that this does not conform to our ABI, as the locals appear before the formals! For simplicity we are currently we are using at small stack frame model (SMODEL_SMALL), which does not require a frame pointer The Pro64 compiler builds the stack frame from a set of sub-segments, of type SF_SEGMENT, again defined in data_layout.cxx. How are these sections ordered? Is it possible to change the ordering of these sections so that the final stack frame calculations apply to our ABI rather than that of the IA64? thank you for any help on this subject. cheers, ben. From owner-pro64-contrib@oss.sgi.com Tue Jul 31 10:52:25 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f6VHqPF05338 for pro64-contrib-outgoing; Tue, 31 Jul 2001 10:52:25 -0700 Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f6VHqNV05335 for ; Tue, 31 Jul 2001 10:52:23 -0700 Received: from rohi.engr.sgi.com (rohi.engr.sgi.com [130.62.180.74]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA09685 for ; Tue, 31 Jul 2001 10:50:09 -0700 (PDT) mail_from (mpm@rohi.engr.sgi.com) Received: (from mpm@localhost) by rohi.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA40103; Tue, 31 Jul 2001 10:51:43 -0700 (PDT) Date: Tue, 31 Jul 2001 10:51:43 -0700 (PDT) From: mpm@rohi.engr.sgi.com (Michael Murphy) Message-Id: <200107311751.KAA40103@rohi.engr.sgi.com> To: pro64-contrib@oss.sgi.com, "Benedict R. Gaster" Subject: Re: Layout of stack frame Sender: owner-pro64-contrib@oss.sgi.com Precedence: bulk From: "Benedict R. Gaster" Hello, We have been working on porting the Pro64 to a new risc style processor and have for the last week or so had the compiler generating code, albeit not completly correct due to stack frame layout being wrong. Our ABI states that, in general, a stack frame takes the form: |--------------------------------| Previous SP 8-byte aligned | Parameter Register Save Area | |--------------------------------| 8-byte aligned | Register Save Area | | |--------------------------------| | direction of stack growth | Local variables Area | \/ |--------------------------------| <--- SP or FP, 8-byte aligned | Dynamic Variable Area | |--------------------------------| | Argument Area (for calls) | |---------------------------------| 8-byte aligned The default stack alignment, set in data_layout.cxx, is 8-bytes, unlike the IA64, which seems to be 16. Currently compiling the following program, at -O0,: int foo(int x, int y) { int local = 100; return x + y + local; } produces the stackframe |-----------------| | SP-0: local | |-----------------| | SP-8: x | | SP-12: y | |-----------------| <------ SP after function prolog. The problem is that this does not conform to our ABI, as the locals appear before the formals! For simplicity we are currently we are using at small stack frame model (SMODEL_SMALL), which does not require a frame pointer The Pro64 compiler builds the stack frame from a set of sub-segments, of type SF_SEGMENT, again defined in data_layout.cxx. How are these sections ordered? Is it possible to change the ordering of these sections so that the final stack frame calculations apply to our ABI rather than that of the IA64? Yes, in data_layout.cxx, the Merge_Fixed_Stack_Frame() and Finalize_Stack_Frame() routines control the order of the frame sections. You can think of data layout as operating on a tree of blocks. When you allocate something, you assign its base to another object, with an offset pointing into that base object. So all the formals are allocated (based) on the formal_stack_segment, and then the formal stack segment (together with local stack segment) is based on the sp_sym object. The MERGE_SEGMENT calls are doing that allocation, and those can be changed to be done in a different order. An interesting thing about your example is that somehow you are not doing the ia64 abi either, as IA64 also has formals appearing before locals. -- Mike Murphy -- mpm@sgi.com -- quote of the day: -- "Air power is an unusually seductive form of military strength -- because, like modern courtship, it appears to offer gratification -- without commitment." (Eliot Cohen)