<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1438779944870_8465">Hi all:</div><div id="yui_3_16_0_1_1438779944870_8496" 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 id="yui_3_16_0_1_1438779944870_9427" dir="ltr"><a id="yui_3_16_0_1_1438779944870_9509" href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.3982&rep=rep1&type=pdf">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.3982&rep=rep1&type=pdfear <br></a></div><div id="yui_3_16_0_1_1438779944870_9517" dir="ltr"><br></div><div id="yui_3_16_0_1_1438779944870_9765" dir="ltr">Anyway, hearing of what you are trying to do especially support OPenVMS, etc, is nice</div><div id="yui_3_16_0_1_1438779944870_10225" dir="ltr"><br></div><div id="yui_3_16_0_1_1438779944870_10315" dir="ltr">Thanks in advance<br></div><div id="yui_3_16_0_1_1438779944870_9022" dir="ltr"><br></div><div id="yui_3_16_0_1_1438779944870_9272" style="line-height: 1.35; " class="">
<div id="yui_3_16_0_1_1438779944870_9271" style="clear: left; " class="">
<div style="float: left; padding-right: 0.5em;text-align: right; width: 1em;" class="">[1]</div><div id="yui_3_16_0_1_1438779944870_9270" style="margin: 0 .4em 0 1.5em;" class="">R. L. Kennel y R. Eigenmann, «Automatic Parallelization of C by Means of Language Transcription», en <i id="yui_3_16_0_1_1438779944870_9269" class="">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-off="" class="" 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 id="yui_3_16_0_1_1438779944870_8446"><span></span></div> <br><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <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 <jay.krell@cornell.edu> escribió:<br> </font> </div> <br><br> <div class="y_msg_container"><div id="yiv1755934078">
<style><!--
#yiv1755934078 .yiv1755934078hmmessage P
{
margin:0px;padding:0px;}
#yiv1755934078 body.yiv1755934078hmmessage
{
font-size:12pt;font-family:Calibri;}
--></style>
<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 ymailto="mailto:M3devel@elegosoft.com" href="mailto:M3devel@elegosoft.com">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></body></html>