[M3devel] proposal for m3cgtype.jmpbuf etc.?

[Jay K]

I propose the following:

 - A flag to m3front indicating if the backend "knows" what a jmpbuf is.
 - extend M3CG.Type = { int8, uint8, ... addr ... struct }   by adding a jmpbuf element

 - if the backend "knows" what a jmpbuf is, then, vs. the current code,   the frontend shall just declare a jmpbuf per try, leaving the backend   to size it, and w/o using the upcoming alloca approach.   
 - if the backend does not "know" what a jmpbuf is, then, well, there   is the current approach of making a sized struct, or my approach   that is almost working where we use alloca. The frontend   will not output cgtype.jmpbuf unless the backend "knows" what it is.

   ok?

The information as to the backend's knowledge of a jmpbuf shall beyet another internal m3front flag, like what guides nested functionoutput order.

I was going to propose something slightly different, likem3front always use this new jmpbuf type, and existing backendscan just change it "back" to struct. The problem with that approach..it works easily with the current code, but does not addressmy upcoming alloca(sizeof_jmpbuf) change.

In this way, what the C backend will do is: #include <setjmp.h>  jmp_buf buf1;  jmp_buf buf2;  etc.

leaving the size of the jmpbuf completely absent in the generated code,and allocating in the slightly more efficient way than alloca.

Exception handling is special, so accomodating this seems reasonable.

Yes, it might be temporary, replaced by libunwind stuff.

Thank you, - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150802/e4341f84/attachment-0001.html>