[M3devel] names in (hopefully) upcoming changes

Peter McKinna peter.mckinna at gmail.com
Thu Aug 6 01:45:02 CEST 2015


Just wondering if the OpenVMS port is being used or if indeed its been
tested.
I used VMS years ago but thought it went the way of the dodo when DEC bit
the dust.

Regards Peter

On Thu, Aug 6, 2015 at 1:54 AM, Daniel Alejandro Benavides D. <
dabenavidesd at yahoo.es> wrote:

> 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
>
>
> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.3982&rep=rep1&type=pdf>
>
> 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 moment
> jmpbuf_size
> Csetjmp_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
>
>
>
> _______________________________________________
> 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/20150806/a6a6d16c/attachment-0002.html>


More information about the M3devel mailing list