[M3devel] alloca(jmpbuf) vs. alloca(jmpbuf + frame)?

[Jay K]

The more I think about this, the more I want to do it the other way,at least for the C backend, but only after another round of change.

For now, I prefer how it is.

The other change I want is "get_member_reference", or for load/store to indicatefield names or constant array indices, along with the "resolved" offset.

That is, I want the backend to be able to do layout, and I want the generatedC to be independent of word size. Including expressions involvingBITSIZE(INTEGER) to be rendered as  #include <stddef.h> // or stdint.h (or autoconf)   typedef ptrdiff_t INTEGER;  // or intptr_t (or autoconf)   #define BITSIZE(x) sizeof(x) * CHAR_BIT
  BITSIZE(INTEGER)  

instead of the current 32 or 64.

 Currently I have two pointers per jmpbuf. One in the frame, one in another local variable. Perhaps this can be converged to have just the one in the frame. Independently of any other change.

Once we have get_member_reference, then for C thiswould just be a nothing-special struct/record with a jmpbuf value at the end,referenced by name.

For the other backends, perhaps we could make it a record,of unspecified size, have the runtime compute the size by addingthe size of the prefix to the size of a jmpbuf and doing alloca.

I'd like C and non-C to be ABI compatible though.They have other differences already, in particular around the frame pointerfor nested functions. This bothers me.

 - Jay


From: jay.krell at cornell.edu
To: hosking at purdue.edu
Date: Sun, 9 Aug 2015 16:18:59 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] alloca(jmpbuf) vs. alloca(jmpbuf + frame)?




https://github.com/modula3/cm3/commit/5b04afe9134e5807196ba6af13fa4cd28401f054
jmpbuf in frame changed from value to pointer.
 - Jay



Subject: Re: [M3devel] alloca(jmpbuf) vs. alloca(jmpbuf + frame)?
From: hosking at purdue.edu
Date: Sun, 9 Aug 2015 20:09:36 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

What is the m3core change you refer to?

Sent from my iPad
On 9 Aug 2015, at 11:33 am, Jay K <jay.krell at cornell.edu> wrote:




I considered that I could lump the jmpbuf alloca in with its enclosing frame -- one slightly larger alloca,and the same amount of overall stack, minus the pointer or two per jmpbuf in the current scheme.

That would preclude the need for m3core change, which I'm sure will cause trouble,but is meant to be an ok thing to do.

However, that isn't perhaps as amenable to my next desired step in the C backend wrt jmp_buf.Though, I guess, I could have it both ways -- the compiler and runtime could share a flagand the frame be altered.

Thoughts?
 - Jay 		 	   		  
_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  

_______________________________________________
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/20150810/d4e5672a/attachment-0002.html>