[M3devel] more crashers

Jay K jay.krell at cornell.edu
Tue Aug 18 03:23:00 CEST 2009


Yes, something like that.

I was likely mistaken -- no try/except/finally here.

 

Still need to look into a bit more, make sure the resulting stack is now very small as I removed all the locals and put them in nested functions -- the function is a big switch and most arms of the switch have their own locals, and some are recursive, every recursion paid for every arm's locals, I assume. 900+ bytes of locals, in a recursive function! That recurses hundreds of times! Blech.

 

The front-end IMHO should "stack pack" "parallel scopes" as a matter of course, not just depend on the optimizer. That wouldn't reduce it as much as my transform though. My transform can sometimes increase stack usage, but not typically. Also of course my transform slows it down in multiple ways, more function calls, slower access to parameters. But preserving stack is important imho. Interesting little area..

 

 - Jay
 
> From: dragisha at m3w.org
> To: hosking at cs.purdue.edu
> Date: Mon, 17 Aug 2009 16:59:23 +0200
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] more crashers
> 
> Isn't that setjmp/longjmp bussiness direct intruction set dependant?
> Some pushall or something like that?
> 
> On Mon, 2009-08-17 at 10:47 -0400, Tony Hosking wrote:
> > Indeed, we might be better off investing effort in getting rid of
> > try-blocks implemented using setjmp/longjmp so as to avoid the
> > stack-allocated jmpbuf state. Or perhaps allocate that state in the
> > heap.
> -- 
> Dragiša Durić <dragisha at m3w.org>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090818/56b7c579/attachment-0002.html>


More information about the M3devel mailing list