<html><head><base href="x-msg://1229/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I still don't understand what you are proposing?  M3CG.alloca?<div><br>
<br><div><div>On Feb 1, 2011, at 4:12 PM, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">Why? You do realize, though it doesn't really matter, that the function cannot be implemented in Modula-3, or C, and isn't implemented on most platforms. It is only implemented on NT, in assembly.<br>Maybe RTHooks is the holder for most function calls from generated code?<br>The interface between any library and m3front?<br>No matter how and if they are implemented?<br> <br>(it could perhaps be implemented in C, void* m3_alloca(size_t n) { return alloca(n); } but I have a "problem" with that, not sure it is a real problem or not, that it strongly resembles returning the address of a local, and if tools had enough visibility into our code, they would flag it as a bug and/or misoptimize it.)<br> <br>As well, this still requires the backend to recognize and special-case the function.<br>As well, it seems like atomics could fit the same model. Why are they in m3cg?<br> <br>I'm trying not to insist on anything in particular, but I'd like to understand why the different options.<br>m3cg offers the most direct, easily implemented, easily optimized, special-case free approach, though it makes m3cg "wider" and m3cg is kind of scary and large. But making special-case functions is just a way to hide the interface widening..in a way that is easier to remove or omit per-target if applicable perhaps..<br> <br> <br> - Jay<br> <br><hr id="stopSpelling">From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Date: Tue, 1 Feb 2011 15:01:44 -0500<br>To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: Re: [M3devel] link failure on NT386<br><br><div>RTHooks makes most sense. <br><br>Sent from my iPhone</div><div><br>On Feb 1, 2011, at 2:20 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br><br></div><div></div><blockquote><div>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="ecxstopSpelling">CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com"></a><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu"></a><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>Subject: Re: [M3devel] link failure on NT386<br>Date: Tue, 1 Feb 2011 09:46:22 -0500<br>To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><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"></a><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:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu"></a><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:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com"></a><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="text-transform: none; text-indent: 0px; border-collapse: separate; font: normal normal normal medium/normal Helvetica; white-space: normal; letter-spacing: normal; word-spacing: 0px; "><div class="ecxhmmessage" style="font-family: Tahoma; font-size: 10pt; ">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"></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"></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="padding-bottom: 0px; padding-left: 0px; padding-right: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; padding-top: 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="padding-bottom: 0px; padding-left: 0px; padding-right: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; padding-top: 0px; ">Do you have a plan to fix?</div><div style="padding-bottom: 0px; padding-left: 0px; padding-right: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; padding-top: 0px; ">Anything I can do to help?</div><div style="padding-bottom: 0px; padding-left: 0px; padding-right: 0px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; padding-top: 0px; ">--Randy Coleburn</div></div></div></span></blockquote></div><br></div></div></div></blockquote></div></blockquote></div></span><br class="Apple-interchange-newline"></blockquote></div><br></div></body></html>