[M3devel] names in (hopefully) upcoming changes

Wed Aug 5 17:54:48 CEST 2015

Hi all:long time ago, a proposal for supporting more higher level R like Aimer Diwan et al, would benefit, support C -> Fortran compilation to further parallelize in big machines (Virtual Speculative Parallel Machine), see [1]:http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.3982&rep=rep1&type=pdfear 

Anyway, hearing of what you are trying to do especially support OPenVMS, etc, is nice
Thanks in advance

  [1]R. L. Kennel y R. Eigenmann, «Automatic Parallelization of C by Means of Language Transcription», en Languages and Compilers for Parallel Computing, S. Chatterjee, J. F. Prins, L. Carter, J. Ferrante, Z. Li, D. Sehr, y P.-C. Yew, Eds. Springer Berlin Heidelberg, 1999, pp. 166-180.   

     El Miércoles 5 de agosto de 2015 2:17, Jay K <jay.krell at cornell.edu> escribió:

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 
_______________________________________________
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/20150805/e35b10e2/attachment-0002.html>