[M3devel] proposal for m3cgtype.jmpbuf etc.?

[Jay]

The alloca approach is fairly sound, w/o this change. However in the "cake and eat it too" dept..the C backend could instead say: 
#include setjmp.h
.
.
.
jmp_buf x;


thereby still not knowing the size of a jmp_buf but generating correct portable slightly more efficient code. Also doing a better job of telling the C compiler that setjmp is being used -- rather than e.g. declaring setjmp ourselves, which I think is somewhat dubious, though faster to compile...


I admit that the efficiency still stinks & we have much greater efficiency goals here.



 - Jay

On Aug 3, 2015, at 7:05 PM, Antony Hosking <hosking at purdue.edu> wrote:

> Remind me again what the issue is with the alloca approach?
> 
>> On Aug 2, 2015, at 1:36 PM, Jay K <jay.krell at cornell.edu> wrote:
>> 
>> 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 be
>> yet another internal m3front flag, like what guides nested function
>> output order.
>> 
>> 
>> I was going to propose something slightly different, like
>> m3front always use this new jmpbuf type, and existing backends
>> can just change it "back" to struct. The problem with that approach..
>> it works easily with the current code, but does not address
>> my 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
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150803/292ccaea/attachment-0002.html>