[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

On 14 Jan 2009, at 01:54, Jay wrote:

>  > 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?

I would prefer to get all the bootstrap archives LONGINT-capable.   
Just do the patch by hand to build the initial archives and then  
forget about it.

> 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?

Yes, it 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).

Sounds like your upgrade script

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

No!  I did not want to do have this hack.  Let's just fix the boot  
archives to handle new m3core and have sysutils work as expected.  The  
alternative is to fold sysutils into m3core, where it can be used  
directly.  That might be a better solution given the dependency.   
Thoughts?

> 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).
>
> m3core
> libm3
> sysutils
> m3middle
> m3objfile
> m3linker
> m3back
> m3front
> m3quake
> cm3
>
> 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/20090114/dde62cf3/attachment-0002.html>