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

[Jay K]

Right -- I would have just said, add a name or such parameter to load/store, but I'm aware of LLVM GetElementPointer so came up with a name like it.But, I'm not sure we want a separate call -- GetElementPointer, followed by a load/store of whatever is stacked -- or build it into the load/store.
I've always found the presence of the offset parameter in load/store "surprising".I'd'a'naively'thunk that'd a be a separate add operation.But I also suspect the original authors knew what they were doing and had possiblydone it several times already, and this parameter's presence was an easy lesson they learnedfrom experience.

Heck, perhaps they had my current desires in mind?

Then again, I was also /initially/ surprised by both the low level nature of the IR, all the layout done already, and that I was able to get it to work generating C. But ultimately it makes a lot of sense in the current form. If you look at the "level" and sophistication of M3x86 -- it doesn't do layout. Even M3C doesn't really do layout -- it echoes/renders the information in another form, leaving the C compiler to do the layout. 

> something that suits LLVM and C

And presumably for the time being, gcc and M3x86? :)

My actual extremely long term goal that I might never get to is that once we have something very portable -- C. And I guess something everyone likes -- LLVM.Perhaps try to write more of our backends. Like starting with M3x86.m3.I know I'll never achieve the reach of C/gcc/LLVM though. Merely targeting AMD64 across NT/Linux/Mac will be difficult -- three file formats and at least two ABIs.

 - Jay


Subject: Re: [M3devel] alloca(jmpbuf) vs. alloca(jmpbuf + frame)?
From: hosking at purdue.edu
Date: Mon, 10 Aug 2015 14:31:50 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Ideally, we would also converge on something that suits both LLVM and C.Your notion of get_member_reference is similar to LLVM getelementptr, which allows the backend to do layout for structs.It would be very nice if the front-end used this level of abstraction.I assume that is what you are talking about.
On Aug 10, 2015, at 2:19 PM, Jay K <jay.krell at cornell.edu> wrote: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.comhttps://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150810/d137ee6d/attachment-0002.html>