<html><body bgcolor="#FFFFFF"><div>The atomics are not necessarily functions. They approximate real instructions generated inline.</div><div>Shall I just go ahead and add it?<br><br>Sent from my iPad</div><div><br>On 01/02/2011, at 2:12 AM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
Interesting. Me playing honestly dumb: how do you decide among runtime hooks vs. "special" functions recognized by the backend?<br>In either case, the best reason I think for an m3cg hook is that the calling convention is unusual.<br>Why are the atomics in m3cg?<br>I grant, a possible reason: in the atomics case, the transform from "regular function" to "special function" might be more significant.<br>alloca is simpler just by virtue of it only taking one parameter.<br><br>Why aren't and/or/xor/add runtime hooks, or special functions?<br>Or the set operations?<br><br>I'm very willing to accept the answer that I suspect is the truth: there isn't a cut and dry reason, and many approaches lead to almost identical results.<br><br>And that there may be a desire to in general avoid growing m3cg.<br>esp. to speed up a case that is very slow for other reasons and that we'd like to speed up in a way that would remove the need for the m3cg hook.<br><br>I'm also wishy washy. I can see it is easy to implement easily any way.<br>I'm just overly bothered when I see obvious easy to fix inefficiency, even it is just a micro-optimization.<br><br><br>At some point, I realize, you can model just about everything as function calls, except, calling functions. :)<br><br>I think runtime hooks are somewhat preferred for stuff implemented in Modula-3.<br>Since anything implemented in Modula-3 and exposed must be in some interface.<br>However runtime hooks can be implemented in C as well.<br>It depends somewhat if they are only called by generated code or also hand written Modula-3.<br>You know, if it is just implemented in C, and only called from generated code, there isn't a strict interface/module system,<br>there is just relying on m3front and m3core agreeing.<br><br><br> - Jay<br><br><br><hr id="stopSpelling">From: <a href="mailto:hosking@cs.purdue.edu"><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a></a><br>Date: Mon, 31 Jan 2011 22:39:36 -0500<br>To: <a href="mailto:jay.krell@cornell.edu"><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a></a><br>CC: <a href="mailto:m3devel@elegosoft.com"><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a></a><br>Subject: Re: [M3devel] link failure on NT386<br><br>
Why can't we just have a run-time hook that resolves differently on different targets?<div>Take a look at m3front/src/misc/Runtyme and m3core/src/runtime/RTHooks.</div><div><div><br><div><div>On Jan 31, 2011, at 7:53 PM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">Oops, I was just wondering to self if I had fixed that.<br>I can get to it fairly soon.<br>We "just" have to translate m3_alloca to _chkstk..and fiddle with the calling<br>convention (which imho is a good reason to<br>make it a separate m3cg call...)<br>(The input parameter is in eax, and the output is in esp.)<br>(Tony, you really don't want a separate m3cg call?)<br> <br> <br> - Jay<br> <br><hr id="ecxstopSpelling">From:<span class="ecxApple-converted-space"> </span><a href="mailto:rcolebur@SCIRES.COM"><a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a></a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com"><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a></a><br>Date: Mon, 31 Jan 2011 19:48:21 -0500<br>Subject: [M3devel] link failure on NT386<br><br><div class="ecxWordSection1"><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;">Jay: I note the HEAD branch is still broken for builds on NT386 due to the linker problem with unresolved symbol we talked about earlier.</div><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;">Do you have a plan to fix?</div><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;">Anything I can do to help?</div><div style="margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding: 0px;">--Randy Coleburn</div></div></div></span></blockquote></div><br></div></div>
</div></blockquote></body></html>