<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Modeling something as a function in m3cg does not necessarily correlate to generating a function call.<br>E.g. the existing m3_alloca.<br>And vice versa. e.g some of the set operations.<br>Almost anything can be modeled as a function call in m3cg, but not end up generating one.<br>Many things can be not modeled as a function call, but end up generating one.<br>gcc has a huge number of "builtin functions". So does Visual C++.<br>In Visual C++, basically any "new instruction" (mmx, sse2/3/4, avx) ends up modeled<br>as a function, but generates roughly one instruction per function calls.<br>It's a slightly high level assembly -- i.e. you get to chose the important algorithmic instructions,<br>the compiler does register allocation, stack/local allocation, etc.<br><br>I can add it -- surely my diff from a few weeks ago wasn't terrible?<br><br>I'm ok either way.<br>I'm more curious to understand than to "do". I admit.<br><br> - Jay<br><br><hr id="stopSpelling">CC: m3devel@elegosoft.com<br>From: hosking@cs.purdue.edu<br>Subject: Re: [M3devel] link failure on NT386<br>Date: Tue, 1 Feb 2011 09:46:22 -0500<br>To: jay.krell@cornell.edu<br><br><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><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="ecxstopSpelling">From: <a href="mailto:hosking@cs.purdue.edu"></a><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Mon, 31 Jan 2011 22:39:36 -0500<br>To: <a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC: <a href="mailto:m3devel@elegosoft.com"></a><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</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><a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a><br>To:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com"></a><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</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>