[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