[M3devel] [M3commit] CVS Update: cm3

Tue Jan 13 15:54:38 CET 2009

 > fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER

Is that what bootstrapping should do?
 Automate that little patch for the first pass and undo it in the second?
 Then always building in dependency order?

Tonight I was trying to build from PPC_DARWIN 5.5.0.
I figured, heck, maybe it supports LONGINT already, maybe I should just try
building up in dependency order.
But then I hit the problem of Compiler.i3 mismatch due to new targets.

So...is that correct?
Does building in dependency order predictably fail if compiler has fewer targets than runtime?
But starting with existing m3core/libm3 and first building the compiler against them predictably works?

I've added targets a bunch and usually don't have a problem, but I can't say for certain what
order I do things when I do this.
Certainly "upgrade.py skipgcc" is something I run fairly often.
It is very fast on NT386 (and unlike upgrade.sh, it doesn't build all of std).

For now I put in two small hacks to sysutils, so it works with old m3core.
I was stuck otherwise.

The hacks are:
  - assume kernel threads or "single threaded"
   That is -- always pass 0 for the waitpid option.
   If sysutils client is multithreaded (always the case),
      and parent threads depend on child processes (not always the case),
      and user threads (really not always the case),
      then there risk of deadlock.

  - if status is non zero but lower 8 bits are zero, set it to 1, to ensure non-zero in lower bits
   This could be done correctly by copying the current Uexec code into sysutils.

Maybe Compiler.i3 can somehow be implemented to "just work"?
And eliminate the redundancy as well?
Have the compiler inject its definition into m3core/libm3?

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon, 12 Jan 2009 19:22:13 +1100
CC: jkrell at elego.de; m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

I think there is a straightforward fix for old compilers that can't compile LONGINT: define LongRep.T = INTEGER.  Most everything should compile from there.  That's what I recall doing to upgrade my compiler to handle LONGINT.  LONGINT is not used anywhere else in m3core, so nothing depends on it working.
On 12 Jan 2009, at 19:02, Jay wrote:If old compiler can't build m3core, such as if old compiler predates LONGINT.
You already know this.
Are we "past" such compilers?

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon, 12 Jan 2009 18:51:08 +1100
CC: jkrell at elego.de; m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Why do you not build in the following order to get a new compiler?  (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work).
m3corelibm3sysutilsm3middlem3objfilem3linkerm3backm3frontm3quakecm3
On 12 Jan 2009, at 18:25, Jay wrote:The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old.

Again, once new m3core is around, no problem.
I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet).

I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it.

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon, 12 Jan 2009 18:19:55 +1100
CC: jkrell at elego.de; m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Not true.  sysutils should be built against the m3core with which it will be linked.   I don't think this is correct.

On 12 Jan 2009, at 17:58, Jay wrote:To bootstrap I believe.

 - Jay

From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Date: Mon, 12 Jan 2009 17:53:02 +1100
CC: jkrell at elego.de; m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Why does sysutils need to be compatible with both old and new versions of m3core?

On 12 Jan 2009, at 17:39, Jay wrote:ThreadPosix is basically unaffected -- I never provided user threads on Cygwin.
 I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged.

The code in ThreadPosix is similar to but different than ThreadPThread.
It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone.

 > You are smearing implementation details across multiple files and directories

You really think it is bad to have SchedulerPosix implemented in a small separate file?
On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3?

ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWait
Plus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect.

I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho.

"Directories" hardly.

Or I can try debugging cygwin pthreads again.

 - Jay

CC: jkrell at elego.de; m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jay.krell at cornell.edu
Subject: Re: [M3devel] [M3commit] CVS Update: cm3
Date: Mon, 12 Jan 2009 12:46:54 +1100

You are smearing implementation details across multiple files and directories.  Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation.  Also, how does all of this fit with the ThreadPosix implementation?

On 12 Jan 2009, at 12:19, Jay wrote:btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used).

The SchedulerPosix implementation moved to ThreadPScheduler.m3.
What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable.

I can try again to debug Cygwin pthreads though.

 - Jay

> From: hosking at cs.purdue.edu
> To: jkrell at elego.de
> Date: Mon, 12 Jan 2009 11:03:33 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> 
> Jay,
> 
> Can you remind me again why Cygwin was unable to use pthreads? It 
> seems you have introduced a bunch of hair into the PTHREADS 
> implementation to deal with broken Cygwin pthreads. As many of us 
> have already pointed out, Cygwin should be a port that tries as much 
> as possible to be like a standard POSIX platform (pthread-based) as 
> opposed to a weird Windows/POSIX hybrid.
> 
> I have a bunch of code that will be going into the PTHREADS base that 
> I am now at a loss to integrate with the changes you have made.
> 
> Help!
> 
> -- Tony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090113/9fe0d450/attachment-0002.html>