[M3devel] link failure on NT386
Jay K
jay.krell at cornell.edu
Tue Feb 1 08:12:13 CET 2011
Interesting. Me playing honestly dumb: how do you decide among runtime hooks vs. "special" functions recognized by the backend?
In either case, the best reason I think for an m3cg hook is that the calling convention is unusual.
Why are the atomics in m3cg?
I grant, a possible reason: in the atomics case, the transform from "regular function" to "special function" might be more significant.
alloca is simpler just by virtue of it only taking one parameter.
Why aren't and/or/xor/add runtime hooks, or special functions?
Or the set operations?
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.
And that there may be a desire to in general avoid growing m3cg.
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.
I'm also wishy washy. I can see it is easy to implement easily any way.
I'm just overly bothered when I see obvious easy to fix inefficiency, even it is just a micro-optimization.
At some point, I realize, you can model just about everything as function calls, except, calling functions. :)
I think runtime hooks are somewhat preferred for stuff implemented in Modula-3.
Since anything implemented in Modula-3 and exposed must be in some interface.
However runtime hooks can be implemented in C as well.
It depends somewhat if they are only called by generated code or also hand written Modula-3.
You know, if it is just implemented in C, and only called from generated code, there isn't a strict interface/module system,
there is just relying on m3front and m3core agreeing.
- Jay
From: hosking at cs.purdue.edu
Date: Mon, 31 Jan 2011 22:39:36 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] link failure on NT386
Why can't we just have a run-time hook that resolves differently on different targets?Take a look at m3front/src/misc/Runtyme and m3core/src/runtime/RTHooks.
On Jan 31, 2011, at 7:53 PM, Jay K wrote:Oops, I was just wondering to self if I had fixed that.
I can get to it fairly soon.
We "just" have to translate m3_alloca to _chkstk..and fiddle with the calling
convention (which imho is a good reason to
make it a separate m3cg call...)
(The input parameter is in eax, and the output is in esp.)
(Tony, you really don't want a separate m3cg call?)
- Jay
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 31 Jan 2011 19:48:21 -0500
Subject: [M3devel] link failure on NT386
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.Do you have a plan to fix?Anything I can do to help?--Randy Coleburn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110201/28aa45de/attachment-0002.html>
More information about the M3devel
mailing list