[M3devel] multi-threaded m3front?

Jay K jay.krell at cornell.edu
Wed Aug 12 00:44:19 CEST 2015


I suspect using Debian or Ubuntu is the quickest route to a suite of cross tools.

 https://wiki.debian.org/CrossToolchains 
at least to Linux, not necessarily to BSD/NT/Solaris/Mac.

We could add "support" to that -- having the default config noticethat host = is debian or ubuntu and host != target and target is linux and invoke those toolsand tell you to apt-get install whatever if they aren't present..

But I still think the "fair" / "flat" / "consistent" story is to make boot archives something like 3.6and user then completes the build on the target with native tools.

We'd distribute like three archives per target:   boot -- no binaries, all assembly/C source, to just cm3/libm3/m3core (not just cm3 like current)    binmin -- binaries -- cm3, cm3cg (except for NT386), m3core (maybe just static), libm3 (ditto)    binall -- all binaries, nothing to build 

The C source might be somewhat target-independent, but getting it to be fully target-independentI can't yet commit to.
binmin has a pretty narrow use case, maybe strike it   - Jay


From: jay.krell at cornell.edu
To: hendrik at topoi.pooq.com; m3devel at elegosoft.com
Date: Tue, 11 Aug 2015 22:33:22 +0000
Subject: Re: [M3devel] multi-threaded m3front?




Hendrik: exactly

My longer blurbe from earlier.

 > https://github.com/modula3/cm3/blob/master/m3-sys/m3cc/src/buildmany.sh


builds cm3cg for every target.

Seems like overkill, but which ones?
Do we make a bunch of single file downloads?
Notice how buildmany.sh is trivial.
m3cc/src/m3makefile does the "real" work, and it isn't complicated.
And, btw, I didn't write it. It's been there "forever".

 https://github.com/modula3/cm3/blob/master/m3-sys/cminstall/src/config-no-install/cm3cfg.common 
 look for the lines: "for cross builds" 
 knows about the *unshipped* structure that 
 https://github.com/modula3/cm3/blob/master/m3-sys/m3cc/src/m3makefile 
 creates for cross cm3cg -- instead of host-target/cm3cg.

 We could consider: 
   always buildmany (all) and ship them 
   and adapt cm3cg.common to look in the shipped location instead, 
   like bin/target/cm3cg.

 But is this useful though? 
 
 
i.e. w/o the cross-c-compiler/linker/assembler? 

 There are larger problems. 
 "Many things are configurable".  More than people often consider.
 "Linux" could be using glibc, or eglibc, or newlib, etc. 
 For the most part, they are probably ABI-compatible. 
 But are they completely? 
 Is struct stat always the same? 
 Do all the libcs even have pthreads? (I doubt lacking pthreads is a useful system though.)

 This is why, btw, I had proposed, like m3core/src/thread/linux.

 to replace, on Linux, m3core/src/PTHREAD, 
 to skip through the varying libc's and go to the less varying kernel. 
 The futexes and clone and all that. 

 Maybe research the packages that Debian and Gentoo have? 
 And just recommend whatever apt-get, and invoke gcc/ld/as by the names 
 we know they use? 

They likely have mingw in there, so you can cross from Linux to NT.

I believe Debian has a general story btw, of using cross building compilers to
bootstrap, but then giving up on cross building otherwise. Too many autoconf's depend on being native builds.
And using qemu if it is faster than the native hardware.

Really, I think the problem is cross compilation of C. Solve/automate that, and finishing
the Modula-3 work shouldn't be difficult.

 You can go the other way, but I don't want to: 
  - eliminate all C (undoing everything I did in m3core/src/unix) 
  - write all integrated backends 
  - write our own linker  
  - including writing our own startup code and pthreads (the futex/clone proposal) 

But if you look into this, esp. the startup code and syscall stubs, you realize it is a very large taskfor very little payoff. 

 - Jay




> Date: Tue, 11 Aug 2015 16:57:21 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] multi-threaded m3front?
> 
> On Tue, Aug 11, 2015 at 06:56:03PM +0000, Jay K wrote:
> >  The problem with cross compiling is you need: 
> >   a working cross-compiler for C/C++  
> 
> Slightly clumsier is just haveing a C/C++ compiler on the target system.
> But it's often easier to get that than a cross-compiler. 
> 
> -- hendrik
> 
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  

_______________________________________________
M3devel mailing list
M3devel at elegosoft.com
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150811/c02d2541/attachment-0002.html>


More information about the M3devel mailing list