[M3commit] CVS Update: cm3

Thu Jan 6 00:31:08 CET 2011

Hi all:
I wonder how we could make the static M3CG stack allocation tracing verified so not overflow can occur and so make a progress with that compiler obligation too. 
I suppose every thing we can put in the stack instead of the heap is less efficient in compiler and the checker times but in terms of execution less slower than it would without it.
I recall just an experiment with the ESC to check DISPOSE statement (side effecting) instruction will not corrupt the heap with the ESC, kind of interesting for the help M3CG to disable compiler inserted useless garbage collector calls and if so usable inside the stack boundaries for checking unused stack allocated callee  for instance inside the bug commented by Mika on see:
https://mail.elegosoft.com/pipermail/m3devel/2010-December/008330.html
perhaps a mapping of the M3CG typed implementation if we have already a reference to that unreachable code and if so will it be called or not according to the compiler code generator, in such a case there is a on-live dynamic linking it will just like it could prove it or not to not disable those callers, we would need to automatically infer the annotations for the checker to M3CG µ-instructions and feed for the checker and prover that too. This would be useful not just for the compiler, but for the programmer too, don't you think?
Also this would be straightforward to demonstrative of a program that is not to overflow or underflow by popping out anyhow, another missing check in current compilers technology as of what I currently know. Besides that one must check the arithmetic overflow, that would need more of the ESC normal technology by now, though we could explicitly check for it in the searched errors too, again typing the M3CG µ-instructions will gave some of the neeeded info I guess and by emulating ALU logic we could also warn proof that anything would happen in some point if contracts are fulfilled.

Thanks in advance 

--- El mié, 5/1/11, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3commit] CVS Update: cm3
Para: "Tony" <hosking at cs.purdue.edu>
CC: m3commit at elegosoft.com
Fecha: miércoles, 5 de enero, 2011 17:40

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

#yiv448101372 .yiv448101372ExternalClass .yiv448101372ecxhmmessage P
{padding:0px;}
#yiv448101372 .yiv448101372ExternalClass body.yiv448101372ecxhmmessage
{font-size:10pt;font-family:Tahoma;}

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/a43ffd96/attachment-0002.html>