[M3devel] threading on Windows?

[Daniel Alejandro Benavides D.]

Hi all:
is useful to say here that the compiler linker approach at some extent was done in the same way as was in Modula-3, now Open Watcom, used same runtime structure and required as far as I know no better enlightment in the original versions of it, I read it some quite time ago in its sources, hard to tell you where it was, but if OpenWatcom sold it as a Windows solution in its runtime why not in the Modula-3 one, indeed how it would be to port its linker to work for Modula-3 and tune it for the  required  works of it. Is better to adapt to a better portable (Linux, etc) solution than  to adapt to a  non-portable still solution as I believe.
Thanks in advance

--- El jue, 10/2/11, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: Re: [M3devel] threading on Windows?
Para: "Tony" <hosking at cs.purdue.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 10 de febrero, 2011 17:11




Why is it better?  Because rebinding to a different function is just a matter of changing an INTERFACE in the libraries, rather than hacking the compiler.



On Feb 10, 2011, at 6:01 AM, jay.krell at cornell.edu wrote:



1. I never understood why this any better.
2. It how things are currently.
3. Why not m3cg.alloca? (but see #2)

 - Jay/iPad

 
You really think there's a way to do this w/o a special case in the compiler? I highly doubt that.
Granted, I haven't looked at it and I will spend a few minutes doing so, but again, I highly doubt this can be anything but a very special case.
Maybe runtime hooks allow for an enum comparison instead of a string comparison.
m3cg.alloca allows the most direct route w/o discovering the special case in a general purpose path.
 
 
Inlining...well, on NT, the stack pages must be touched in order.
Code that does merely: void f() { char foo[4097]; } incurs a function calls in the prolog.
The function called is _chkstk.
It is a long standing bug in the NT/x86 backend that it doesn't do this.
Given that jmpbuf is always way smaller than 4K, doing merely sub esp,Jmpbuf__size is probably reasonable.
As well, oh...well, that's not m3cg.Alloca, that's reall m3cg.AllocaJmpbufSize...which is specific enough,
that if the backend wants to know the target jmpbuf size, it can optimize slightly thereof.
We could make it be m3cg.AllocaSmallValue(name: TEXT).
I'm torn. Many many many almost identical options.
 
 
As well, Target.i3 could contain a jumpbuf size, default it to 0. If it is zero, use the code I have now.
If it isn't zero, use the old code. Something like that.
Yes, I realize there are changes in the EH code possibly implied.
 
 
Again, _chkstk has a highly custom calling convention, both its input parameter and output don't follow convention.
RTHooks makes that not a special case? I'll look later..
 
 
- Jay 		 	   		  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110210/e4be1464/attachment-0002.html>