[M3commit] CVS Update: cm3

[Jay K]

I've back with full keyboard if more explanation needed. The diff is actually fairly small to read.I understand it is definitely less efficient, a few more instructions for every try/lock.No extra function call, at least with gcc backend.I haven't tested NT386 yet. Odds are so/so that it works -- the change is written so that it should workbut I have to test it to be sure, will to roughly tonight. And there probably is a function call there.
 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Wed, 5 Jan 2011 20:44:08 +0000
CC: m3commit at elegosoft.com
Subject: Re: [M3commit] CVS Update: cm3







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 University305 N. University Street | West Lafayette | IN 47907 | USAOffice +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/ddcda48d/attachment-0002.html>