From mboxrd@z Thu Jan 1 00:00:00 1970 References:

In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-3719E12A-E35B-4E98-A714-3CD23A3758F5 Message-Id: Content-Transfer-Encoding: 7bit From: Bakul Shah Date: Mon, 16 Jan 2012 07:41:47 -0800 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] assembly syntax in plan 9 Topicbox-Message-UUID: 5d1f7434-ead7-11e9-9d60-3106f5b1d025 --Apple-Mail-3719E12A-E35B-4E98-A714-3CD23A3758F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A frame pointer is needed for C99's variable length arrays but not otherwise= . Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to= do the right thing even with -fno-frame-pointer. On Jan 16, 2012, at 5:08 AM, Charles Forsyth wro= te: >=20 > You should read /sys/doc/asm.pdf first.=20 > careful: TOS is only for 68k. nothing else defines or uses it. >=20 > Plan 9 doesn't use a base pointer, because everything can be addressed rel= ative to the stack pointer, > and the loader keeps track of the SP level. thus FP is a virtual register,= that the loader implements > by replacing offsets relative to it by the current appropriate offset from= the hardware stack pointer register (whatever > that might be on a given platform). That's esp on the x86. the TEXT direct= ive specifies the space a function > requires for its stack frame, and the loader then adds appropriate code at= start and end to provide it. > 0(FP) is the first argument, 4(FP) is the second, and so on. 0(SP) is the b= ottom of the current frame, > and 0(SP), 4(SP) etc are referenced to build the arguments for outgoing ca= lls (but that space must > be accounted for in the TEXT directive). >=20 > (it's probably not very different in effect from -fno-frame-pointer or wha= tever it is for gcc, > which also doesn't use ebp except that is implemented entirely by the comp= iler.) >=20 > On 16 January 2012 12:30, Alexander Kapshuk w= rote: > i have a question about putting things on the stack for x86 arch under pla= n 9... >=20 > under unix/linux, when defining a function, i would: > (1). push the address the base pointer is pointing to prior to this functi= on being called, onto the stack; e.g. pushl %ebp > (2). then i would have the base pointer point to the current stack pointer= ; e.g. movl %esp, %ebp > (3). then i would allocate space on the stack for local variables, if any;= e.g. subl $n, %esp; > (4). then follows the function body; > to return from the function i would: > (1). restore the stack pointer; e.g. movl %ebp, %esp; > (2). restore the base pointer, e.g. popl %ebp; > (3). then return to the calling function; >=20 > i searched the 9fans archives for posts on assembly programming under plan= 9; found some bits and pieces; e.g. in one of the posts it was mentioned th= at BP is a general purpose register, not the base pointer; and that FP is wh= at ebp is under unix/linux; >=20 > in the paper for the plan 9 assembler, it says that there are three regist= ers available to manipulate the stack, FP, SP, and TOS; would the following c= omparison stand true then? > plan9 unix/linux > ------- ------------- > FP EBP > SP -4(%EBP)...-n(%EBP) /* local variables */ > TOS ESP >=20 > thanks; >=20 > sasha kapshuk >=20 >=20 --Apple-Mail-3719E12A-E35B-4E98-A714-3CD23A3758F5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8

A frame pointer is needed for C99's variable length arrays but not otherwise. Only an issue if ever plan9 C is extended to handle C99 or C1x. gcc has to do the right thing even with -fno-frame-pointer.

On Jan 16, 2012, at 5:08 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote:

You should read /sys/doc/asm.pdf first.
careful: TOS is only for 68k. nothing else defines or uses it.

Plan 9 doesn't use a base pointer, because everything can be addressed relative to the stack pointer,

and the loader keeps track of the SP level. thus FP is a virtual register, that the loader implements
by replacing offsets relative to it by the current appropriate offset from the hardware stack pointer register (whatever

that might be on a given platform). That's esp on the x86. the TEXT directive specifies the space a function
requires for its stack frame, and the loader then adds appropriate code at start and end to provide it.

0(FP) is the first argument, 4(FP) is the second, and so on. 0(SP) is the bottom of the current frame,
and 0(SP), 4(SP) etc are referenced to build the arguments for outgoing calls (but that space must

be accounted for in the TEXT directive).

(it's probably not very different in effect from -fno-frame-pointer or whatever it is for gcc,
which also doesn't use ebp except that is implemented entirely by the compiler.)

On 16 January 2012 12:30, Alexander Kapshuk <alexander.kapshuk@gmail.com> wrote:
i have a question about putting things on the stack for x86 arch under plan 9...

under unix/linux, when defining a function, i would:
(1). push the address the base pointer is pointing to prior to this function being called, onto the stack; e.g. pushl %ebp

(2). then i would have the base pointer point to the current stack pointer; e.g. movl %esp, %ebp
(3). then i would allocate space on the stack for local variables, if any; e.g. subl $n, %esp;
(4). then follows the function body;

to return from the function i would:
(1). restore the stack pointer; e.g. movl %ebp, %esp;
(2). restore the base pointer, e.g. popl %ebp;
(3). then return to the calling function;

i searched the 9fans archives for posts on assembly programming under plan 9; found some bits and pieces; e.g. in one of the posts it was mentioned that BP is a general purpose register, not the base pointer; and that FP is what ebp is under unix/linux;

in the paper for the plan 9 assembler, it says that there are three registers available to manipulate the stack, FP, SP, and TOS; would the following comparison stand true then?
plan9 unix/linux

------- -------------
FP EBP
SP -4(%EBP)...-n(%EBP) /* local variables */
TOS ESP

thanks;

sasha kapshuk

--Apple-Mail-3719E12A-E35B-4E98-A714-3CD23A3758F5--