<div dir="ltr">Just wondering if the OpenVMS port is being used or if indeed its been tested.<div>I used VMS years ago but thought it went the way of the dodo when DEC bit the dust.</div><div><br></div><div>Regards Peter</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 6, 2015 at 1:54 AM, Daniel Alejandro Benavides D. <span dir="ltr"><<a href="mailto:dabenavidesd@yahoo.es" target="_blank">dabenavidesd@yahoo.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div>Hi all:</div><div dir="ltr">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]:</div><div dir="ltr"><a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.3982&rep=rep1&type=pdf" target="_blank">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.3982&rep=rep1&type=pdfear <br></a></div><div dir="ltr"><br></div><div dir="ltr">Anyway, hearing of what you are trying to do especially support OPenVMS, etc, is nice</div><div dir="ltr"><br></div><div dir="ltr">Thanks in advance<br></div><div dir="ltr"><br></div><div style="line-height:1.35">
<div style="clear:left">
<div style="float:left;padding-right:0.5em;text-align:right;width:1em">[1]</div><div style="margin:0 .4em 0 1.5em">R. L. Kennel y R. Eigenmann, «Automatic Parallelization of C by Means of Language Transcription», en <i>Languages and Compilers for Parallel Computing</i>, 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.</div>
</div><div dir="ltr">
<span title="url_ver=Z39.88-2004&ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fzotero.org%3A2&rft_id=urn%3Aisbn%3A978-3-540-66426-0%2C%20978-3-540-48319-9&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Automatic%20Parallelization%20of%20C%20by%20Means%20of%20Language%20Transcription&rft.publisher=Springer%20Berlin%20Heidelberg&rft.series=Lecture%20Notes%20in%20Computer%20Science&rft.aufirst=Richard%20L.&rft.aulast=Kennel&rft.au=Richard%20L.%20Kennel&rft.au=Rudolf%20Eigenmann&rft.au=Siddhartha%20Chatterjee&rft.au=Jan%20F.%20Prins&rft.au=Larry%20Carter&rft.au=Jeanne%20Ferrante&rft.au=Zhiyuan%20Li&rft.au=David%20Sehr&rft.au=Pen-Chung%20Yew&rft.date=1999&rft.pages=166-180&rft.spage=166&rft.epage=180&rft.isbn=978-3-540-66426-0%2C%20978-3-540-48319-9&rft.language=en"></span>
</div></div><div><span></span></div> <br><div><br><br></div><div style="display:block"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"> <font face="Arial" size="2"> El Miércoles 5 de agosto de 2015 2:17, Jay K <<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>> escribió:<br> </font> </div> <br><br> <div><div>
<div><div dir="ltr">I need some names.<div><br></div><div>C has a type "jmp_buf" -- with no "u" and with an underscore.</div><div><br></div><div><br></div><div>I need a module in m3front for counting tries and managing jmp_bufs.</div><div>I call it Jmpbufs.</div><div><span style="font-size:12pt">It could be Jumpbufs</span><span style="font-size:12pt">.</span></div><div><span style="font-size:12pt">Or JumpBuffers.</span></div><div>Perhaps that is too direct.</div><div>Or sjljeh (setjmp/longjmp exception handling)</div><div>Or worked into the existing Marker.</div><div><br></div><div><div><br></div><div>A "constant variable" in C to hold sizeof(jmp_buf).</div><div>So far this was called Csetjmp__Jumpbuf_size.</div><div>However this "constant variable" should never be used from Modula-3.</div><div>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.</div><div><br></div><div><br></div><div>This name is an "interface" between m3front and m3core, i.e. m3core/src/unix/Common/Uconstants.c.</div><div>It is always statically linked.</div><div><br></div><div><br></div><div>Potential names here are:</div><div><br></div><div><br></div><div>m3_jmpbuf_size my favorate at the moment</div><div>jmpbuf_size</div><div>Csetjmp_Jumpbuf_size already present by this name, but can be changed </div><div><br></div><div><br></div><div><span style="font-size:12pt"><br></span></div><div><span style="font-size:12pt">"alloca"</span></div><div><br></div><div><br></div><div>This is (will be) part of the interface between m3front and every backend.</div><div>While it is *almost* pass-through, it isn't.</div></div><div>The C backend targeting non-Win32, non-VMS, can just pass through the name.</div><div>But every other case in every other backend must treat the name specially.</div><div>cm3cg has to convert it to "builtin_alloca".</div><div>LLVM probably is like cm3cg.</div><div><span style="font-size:12pt">Win32 non-C has to change it to __chkstk or perhaps _chkstk.</span></div><div>Win32 C has to change it to _alloca.</div><div>OpenVMS has to change it to __ALLOCA or such.</div><div><span style="font-size:12pt">That is, the symbol "alloca" is almost but not quite portable in C.</span></div><div><br></div><div><br></div><div>Again the function is never called from Modula-3 and need not be in an interface.</div><div><br></div><div><br></div><div>Potential names here are:</div><div><br></div><div>"alloca" what I'm using currently and remains my favorate.</div><div>"m3_alloca"</div><div>"m3_allocate_jmpbufs"</div><div><br></div><div><br></div><div>So far I'm calling it "alloca".</div><div><br></div><div><br></div><div>Thoughts/suggestions/criticisms?</div><div><br></div><div><br></div><div>Just wait for the larger diff?</div><div><br></div><div><br></div><div>As well, some of this could be more than "just random string function names".</div><div>We could make them CONSTs in M3CG_Ops.i3.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>But adding alloca to M3CG_Ops.i3 might be reasonable.</div><div><br></div><div><br></div><div>Thanks,</div><div> - Jay</div> </div></div>
</div><br>_______________________________________________<br>M3devel mailing list<br><a href="mailto:M3devel@elegosoft.com" target="_blank">M3devel@elegosoft.com</a><br><a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br><br><br></div> </div> </div> </div></div></div><br>_______________________________________________<br>
M3devel mailing list<br>
<a href="mailto:M3devel@elegosoft.com">M3devel@elegosoft.com</a><br>
<a href="https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel" rel="noreferrer" target="_blank">https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel</a><br>
<br></blockquote></div><br></div>