[M3devel] alloca/jmpbuf

[Jay K]

I am no longer able to reproduce the problem.There have been some changes since but they don't seem relevant.

Unless there are objections I'll put this back shortly -- just changingthe two booleans in Target.m3 and RTExFrame, and retaining the option to easily move back.

Thank you, - Jay


> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: alloca/jmpbuf
> Date: Sat, 2 Jan 2016 01:04:22 +0000
> 
> ok -- putting back the old jmpbuf allocation does fix the problem on caltech-parser/parserlib/parserlib/test NT386.
> I had to do the undo very manually because git was confusing.
> 
> Anyone have any idea of the exact problem?
> 
> Otherwise I'll try to figure it out but it'll take a while.
> 
> Maybe we have really good focused exception handling tests? I"ll look in m3tests.
> 
> Thank you,
>  - Jay
> 
> 
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: alloca/jmpbuf
> > Date: Fri, 1 Jan 2016 06:21:27 +0000
> >
> > NT386 has some failure in the caltech-parser/parserlib/parserlib/test directory.
> >
> >
> > I propose the following:
> > Bring back the jmpbuf-size-known-by-frontend code, but with some "sprinkled conditions":
> >
> >
> > Target.Alloca_jmpbuf: BOOLEAN in the compiler
> > and something in the runtime, like RTExFrame.Alloca_jmpbuf:BOOLEAN.
> >
> >
> > If this is/was/meant to be an option that lasted a while, then it'd also be a bit in RT0, so the runtime would make a runtime decision "informed by" the compiler.
> >
> > However this is really just hopefully just an experiment, and anyone switching the value would switch it in both places.
> >
> >
> > It really can't be in only one place, though one could communicate it to the other -- such is the dependency/independency between the compiler and runtime.
> >
> >
> > I tried to do a "git revert" and then edit, but git continues to elude me, so I'm going to do something more manual.
> >
> > Ok?
> >
> > Alternatives:
> > 1) Just debug the current state.
> > Esp. comparing MacOSX (which works) with NT386
> >
> > 2) Construct all I've said but don't commit it.
> >
> >
> > - Jay
>  		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160108/25dedca9/attachment-0002.html>