[M3devel] link failure on NT386

[Tony Hosking]

I still don't understand what you are proposing?  M3CG.alloca?


On Feb 1, 2011, at 4:12 PM, Jay K wrote:

> 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.
> Maybe RTHooks is the holder for most function calls from generated code?
> The interface between any library and m3front?
> No matter how and if they are implemented?
>  
> (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.)
>  
> As well, this still requires the backend to recognize and special-case the function.
> As well, it seems like atomics could fit the same model. Why are they in m3cg?
>  
> I'm trying not to insist on anything in particular, but I'd like to understand why the different options.
> 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..
>  
>  
>  - Jay
>  
> From: hosking at cs.purdue.edu
> Date: Tue, 1 Feb 2011 15:01:44 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] link failure on NT386
> 
> RTHooks makes most sense. 
> 
> Sent from my iPhone
> 
> On Feb 1, 2011, at 2:20 PM, Jay K <jay.krell at cornell.edu> wrote:
> 
> Modeling something as a function in m3cg does not necessarily correlate to generating a function call.
> E.g. the existing m3_alloca.
> And vice versa. e.g some of the set operations.
> Almost anything can be modeled as a function call in m3cg, but not end up generating one.
> Many things can be not modeled as a function call, but end up generating one.
> gcc has a huge number of "builtin functions". So does Visual C++.
> In Visual C++, basically any "new instruction" (mmx, sse2/3/4, avx) ends up modeled
> as a function, but generates roughly one instruction per function calls.
> It's a slightly high level assembly -- i.e. you get to chose the important algorithmic instructions,
> the compiler does register allocation, stack/local allocation, etc.
> 
> I can add it -- surely my diff from a few weeks ago wasn't terrible?
> 
> I'm ok either way.
> I'm more curious to understand than to "do". I admit.
> 
>  - Jay
> 
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> Subject: Re: [M3devel] link failure on NT386
> Date: Tue, 1 Feb 2011 09:46:22 -0500
> To: jay.krell at cornell.edu
> 
> The atomics are not necessarily functions.   They approximate real instructions generated inline.
> Shall I just go ahead and add it?
> 
> Sent from my iPad
> 
> On 01/02/2011, at 2:12 AM, Jay K <jay.krell at cornell.edu> wrote:
> 
> 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/23d141a2/attachment-0002.html>