[M3devel] "crazy cross"

[Jay]

I forgot some vaguely related things.

Do people worry about optimizing away creating new processes?

Could m3cg be built as an .so/.dll? Probably.
And ok license-wise?

Could m3cg be run once per package instead of once per source?
gcc and cl both can be:
  cl -c foo.c bar.c 
  gcc -c foo.c bar.c 
   Currently in NT386GNU I depend on -o, 
    gcc -c foo.c -o foo.obj 
Would need to handle that, not a big deal.

Also, in the scheme below, either cm3.sh/cm3.cmd would have a switch to merely print the "real" cm3's path, or, just as well, sysinfo.sh et. al. would know how to find it, save that process.

Furthermore -- multithreaded build?

I believe, maybe absent bootstrapping, that cm3 could read "all" the m3makefiles, work out the dependency graph trivially, and build things in parallel. Bootstrappinging works too. It builds only what you say, in the right order. The Python scripts can implement this easily enough.

 - Jay

----------------------------------------
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> Subject: Re: [M3devel] "crazy cross"
> Date: Tue, 15 Jan 2008 08:47:13 -0500
> To: jayk123 at hotmail.com
> 
> 
> On Jan 15, 2008, at 2:00 AM, Jay wrote:
> 
>> It looks like at least cm3 is "always" target-independent.
>> Whatever target is defined to in cm3.cfg, if it is one of the built  
>> in known ones, cm3 will generate code for. Except maybe NT386,  
>> though it need not be -- cm3 could have both the .obj and "gcc  
>> tree" writing backends both linked into it and dynamically chose  
>> between them.
> 
> Yes, the cm3 front-end will generate .mo/.io files for any target on  
> any other host.  The gcc-based backend runs as a separate process  
> (there are license issues with linking the gcc-based backend directly  
> with the front-end).
> 
>> Maybe it already does.
>> cm3 operates at a fairly high level when using gcc, and the target  
>> specific stuff is just some data about the name of setjmp, the  
>> sizeof jmp_buf, etc..
>>
>> The "only" "problem" is then m3cg/as/ld/link.
>> m3cg could be moved to $CM3_INSTALL/pkg/x/HOST/TARGET.
> 
> True!
> 
>> cm3, along with everything else, could be $CM3_INSTALL/pkg/x/HOST
>> leaving $CM3_INSTALL/bin/cm3 that is sh and $CM3_INSTALL/bin/cm3.py  
>> or cm3.cmd that calls out to cm3.
> 
> Possibly.
> 
>> "Fixing" as/ld, well, I don't suppose they tend to be target  
>> neutral do they? You'd have to import them like gcc and build them  
>> n times. Gaining a much slower build, much larger tree.
> 
> Indeed.
> 
>> I suppose anyone could do this themselves, and change cm3.cfg  
>> appropriately. Doing things "officially" this way for one "big"  
>> distribution, probably folks would not go for.
> 
> This is how bootstraps to other targets typically go:  cm3 *.m3- 
> >*.mo.  Copy .mo files to target.  Build cm3cg for target.  cm3cg  
> *.mo->*.ms  as *.ms->*.o ld *.o->libs/execs.
> 
> 
>>
>>
>>  - Jay
>>
>>
>>
>> From: jayk123 at hotmail.com
>> To: m3devel at elegosoft.com
>> Subject: "crazy cross"
>> Date: Sat, 5 Jan 2008 01:22:13 +0000
>>
>> You've all heard of "Canadian cross"?
>>
>> It is cross-building a cross-compiler.
>> I'm sitting in Windows. I'm going to build a compiler that is going  
>> to run on Linux that is going to target Solaris.
>> For one example.
>>
>> You've all seen that Apple has switches like so:
>>
>> gcc -arch i386 ppc ppc64 x86_64 hello.c
>> and poof out comes a binary that runs natively on four architectures
>>
>> I don't like the "inconvenience" of non cross systems and having to  
>> have all the machines/OSes just to build the binaries.
>> I realize that you hit the wall if you actually want to test the  
>> results. So cross building only gets so much.
>> Of course I also don't want to multiply out build times for tools...
>>
>> Ok, well what is the possibility of:
>>
>> cm3 -target NT386
>> cm3 -target NT386 -target PPC_DARWIN
>>
>> ? In my crazy imagination, you have:
>>
>>  \cm3\bin\cm3.cmd
>>      %~dp0..\libexec\%processor_architecture%\%TARGET%\cm3.exe %*
>>
>>  \cm3\bin\cm3
>>      #!/bin/sh
>>      dirname(dirname($0))/libexec/`uname whatever`/$TARGET/cm3 $@
>>
>> Thus it becomes POSSIBLE to have an n x m matrix, host x target,  
>> and be able to build
>> "anything" from one environment.
>>
>> Actually the targets could all be merged into one .exe or  
>> be .dll/.sos.
>> Except the code isn't setup for that.
>>
>> Interesting?
>>
>> I guess the hard part is the C code and linking?
>> The Modula-3 stuff is already setup to do most of this?
>>   (partly by virtue of all that header rewriting that I labeled  
>> sleazy)
>>
>>  - Jay
>>
>>
>>
>> Share life as it happens with the new Windows Live. Start sharing!
>>
>> Share life as it happens with the new Windows Live. Start sharing!
> 

_________________________________________________________________
Watch “Cause Effect,” a show about real people making a real difference.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause