[M3commit] CVS Update: cm3
Tony Hosking
hosking at cs.purdue.edu
Thu Jan 6 02:21:11 CET 2011
Do you alloca on every TRY or once in procedures that have a TRY?
Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484
On Jan 5, 2011, at 3:44 PM, Jay K wrote:
> I only have phone right now. I think it is fairly clear: the jumpbuf in EF1 is now allocated with alloca, and a pointer stored. It is definitely a bit less efficient, but the significant advantage is frontend no longer needs to know the size or alignment of a jumpbuf.
>
>
> As well, there is no longer the problem regarding jumpbuf aligned to more than 64 bits. I at least checked on Linux/PowerPC and alloca seems to align to 16 bytes. I don't have an HPUX machine currently to see if the problem is addressed there.
>
>
> The inefficiency of course can be dramatically mitigated via a stack walker. I wanted to do this first though, while more targets using setjmp.
>
> - Jay/phone
>
> Subject: Re: [M3commit] CVS Update: cm3
> From: hosking at cs.purdue.edu
> Date: Wed, 5 Jan 2011 13:35:59 -0500
> CC: jkrell at elego.de; m3commit at elegosoft.com
> To: jay.krell at cornell.edu
>
> Can you provide a more descriptive checkin comment? I don't know what has been done here without diving into the diff.
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
> On Jan 5, 2011, at 9:37 AM, Jay K wrote:
>
> diff attached
>
> > Date: Wed, 5 Jan 2011 15:34:55 +0000
> > To: m3commit at elegosoft.com
> > From: jkrell at elego.de
> > Subject: [M3commit] CVS Update: cm3
> >
> > CVSROOT: /usr/cvs
> > Changes by: jkrell at birch. 11/01/05 15:34:55
> >
> > Modified files:
> > cm3/m3-libs/m3core/src/C/Common/: Csetjmp.i3
> > cm3/m3-libs/m3core/src/C/I386_CYGWIN/: Csetjmp.i3
> > cm3/m3-libs/m3core/src/C/I386_MINGW/: Csetjmp.i3
> > cm3/m3-libs/m3core/src/C/I386_NT/: Csetjmp.i3
> > cm3/m3-libs/m3core/src/C/NT386/: Csetjmp.i3
> > cm3/m3-libs/m3core/src/runtime/ex_frame/: RTExFrame.m3
> > cm3/m3-libs/m3core/src/unix/Common/: Uconstants.c
> > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
> > cm3/m3-sys/m3front/src/misc/: Marker.m3
> > cm3/m3-sys/m3front/src/stmts/: TryFinStmt.m3 TryStmt.m3
> > cm3/m3-sys/m3middle/src/: M3RT.i3 M3RT.m3 Target.i3 Target.m3
> >
> > Log message:
> > use: extern INTEGER Csetjmp__Jumpbuf_size /* = sizeof(jmp_buf);
> > alloca(Csetjmp__Jumpbuf_size)
> >
> > to allocate jmp_buf
> >
> > - eliminates a large swath of target-dependent code
> > - allows for covering up the inability to declare
> > types with alignment > 64 bits
> >
> > It is, granted, a little bit slower, in an already prety slow path.
> > Note that alloca isn't actually a function call, at least with gcc backend.
> >
> <jmpbuf_alloca.txt>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20110105/15f072b9/attachment-0002.html>
More information about the M3commit
mailing list