[M3devel] "crazy cross"

[Tony Hosking]

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!