[M3devel] threading on Windows?

Fri Feb 11 02:08:31 CET 2011

Hi all:
thanks for your suggestion yet I learn also from you and others so I try to keep improving it, I may read some English grammar too, this is the best I can do for now, sorry for that and thanks for being open about it (other suggestions are most welcome).
Please think about this, I believe this is transforming very quickly and we don't know pretty much yet where it would be in some not short time, see my point,  1.2 billions of smart phones are being ship, 3 million more than those of PCs, if you see this, this is a turn break point, you need to be able to see also this market becomes more important than some may think.
Still about the PCs, the current trend is too much research being done at the GPGPU thing, with yet another revolution of this days in computation, this is my point precisely, will be able to tackle the opportunity of the change, or be overwhelmed by it, and just wait for another time.
I just say in behalf of the things I have said that could be more common than we thought, yet there are good opportunities, who thought this was another revolution to come, I did not believe it but I'm more turned to think this is another "trend" in computing.
And I think you would not believe but in a country like mine they thought to construct hardware assisted graphics chips, it didn't turn out to be real, but many things came after this, we have self configurable hardware, what else you one want?
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: dabenavidesd at yahoo.es, "Tony" <hosking at cs.purdue.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 10 de febrero, 2011 19:36

Daniel, you generally make very little sense to me. Please consider additional English training.

"Modula-3" defines and implements its own threading library, it's own I/O library, it's own traced and untraced memory allocator (traced == garbage collected), it's own GUI library (Trestle).

It is its own portabilty layer, akin to various other options, e.g. using pthreads and then implementing pthreads on Windows, using Tk or Qt, etc., and depending on them to be ported. etc.

Yes, I am deliberately confusing "language" and "library".

Which are people interested in? One, the other, or both?

Now, granted, we are portable between essentially only two platforms Win32/NT and "Posix", where "Posix" is defined as including pthreads and X Windows, and even in a sense gcc.

  (Even if Modula-3 predates Posix, the dependencies are pretty light, such that they have mostly always been almost consistent across the board -- open/read/write/close, socket/accept/connect/recv/send/listen, a few variations for signals).

  (Personally I would like to change the backend to generate C...)

One could "get out of this (library) business" and target another intermediate portability layer, i.e. write "bindings" for Tk, Qt, etc., and then use Modula-3 "just" as a language, and not an associated large set of libraries.

In general, it is desired for portability layers to be thin in terms of performance and possibly state.

Ideally, given the choice of writing to Win32 threads and getting the smallest fastest program that runs only on Wondows, or pthreads and getting the smallest fastest program that runs on Posix, nobody should shy away from using Modula-3 threads, since they run pretty much just as well as Win32 and pthreads. Pretty much.

Actually condition variables can't be done super well on Win32 prior to Vista, but they are done in a pretty ok way now.

Still, threads and mutexes at least are very thin layers.

Implementing threading more completely yourself, on many systems, precludes you from actually running on more than one processor.

Win7's "user mode scheduling" offers an option with more control and still the ability to run on multiple processors.

But I suspect we aren't very interested, at least not currently.

 - Jay

Date: Thu, 10 Feb 2011 23:40:48 +0000
From: dabenavidesd at yahoo.es
To: hosking at cs.purdue.edu; jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] threading on Windows?

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

#yiv1956618167 .yiv1956618167ExternalClass #yiv1956618167ecxyiv295862095 .yiv1956618167ecxyiv295862095hmmessage P
{padding:0px;}
#yiv1956618167 .yiv1956618167ExternalClass #yiv1956618167ecxyiv295862095 .yiv1956618167ecxyiv295862095hmmessage
{font-size:10pt;font-family:Tahoma;}

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/20110211/5ac53b6b/attachment-0002.html>