[M3devel] names in (hopefully) upcoming changes

Jay K jay.krell at cornell.edu
Wed Aug 5 09:17:42 CEST 2015


I need some names.
C has a type "jmp_buf" -- with no "u" and with an underscore.

I need a module in m3front for counting tries and managing jmp_bufs.I call it Jmpbufs.It could be Jumpbufs.Or JumpBuffers.Perhaps that is too direct.Or sjljeh (setjmp/longjmp exception handling)Or worked into the existing Marker.

A "constant variable" in C to hold sizeof(jmp_buf).So far this was called Csetjmp__Jumpbuf_size.However this "constant variable" should never be used from Modula-3.Putting in a Modula-3 interface (Csetjmp), with the two level naming and a double underscore is unnecessary and I suggest should not be done.

This name is an "interface" between m3front and m3core, i.e. m3core/src/unix/Common/Uconstants.c.It is always statically linked.

Potential names here are:

m3_jmpbuf_size my favorate at the momentjmpbuf_sizeCsetjmp_Jumpbuf_size already present by this name, but can be changed 


"alloca"

This is (will be) part of the interface between m3front and every backend.While it is *almost* pass-through, it isn't.The C backend targeting non-Win32, non-VMS, can just pass through the name.But every other case in every other backend must treat the name specially.cm3cg has to convert it to "builtin_alloca".LLVM probably is like cm3cg.Win32 non-C has to change it to __chkstk or perhaps _chkstk.Win32 C has to change it to _alloca.OpenVMS has to change it to __ALLOCA or such.That is, the symbol "alloca" is almost but not quite portable in C.

Again the function is never called from Modula-3 and need not be in an interface.

Potential names here are:
"alloca" what I'm using currently and remains my favorate."m3_alloca""m3_allocate_jmpbufs"

So far I'm calling it "alloca".

Thoughts/suggestions/criticisms?

Just wait for the larger diff?

As well, some of this could be more than "just random string function names".We could make them CONSTs in M3CG_Ops.i3.

We could make separate functions in M3CG_Ops.i3, like "allocate_jmpbufs" and leave the "lowering" always to the backend -- this isn't likely, as many backends can share part of the lowering.

But adding alloca to M3CG_Ops.i3 might be reasonable.

Thanks, - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150805/839a970c/attachment-0001.html>


More information about the M3devel mailing list