[M3devel] link failure on NT386

Tue Feb 1 22:12:05 CET 2011

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