[M3devel] "crazy cross"

[Tony Hosking]

On Jan 15, 2008, at 6:24 PM, Jay wrote:

>
> I forgot some vaguely related things.
>
> Do people worry about optimizing away creating new processes?

Perhaps.

> Could m3cg be built as an .so/.dll? Probably.

Tricky given gcc's nature.

But, m3middle could be glued to gcc to build gcc's trees  
directly...though I strongly prefer the current arrangement.

> And ok license-wise?

Um, no.  FSF have been generally opposed to the way the Modula-3  
backend is a thin front-end veneer over gcc, since we get to use  
their compiler without infecting M3 with the GPL/LGPL.  Of course, it  
would probably be preferable to have CM3 under the GPL/LGPL

> Could m3cg be run once per package instead of once per source?

Possibly, though right now m3cg does not use the gcc front-end  
driver.  To be honest, I prefer the separation of concerns between  
m3middle and the gcc-based backend.  It is much easier for debugging  
and development.

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

I would strongly prefer to see functionality remain decomposed as it  
currently is.  Tangled balls of string are tough to understand,  
maintain, and develop.

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