[M3devel] link failure on NT386

[Jay K]

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/7668a6c1/attachment-0002.html>