[M3devel] "crazy cross"

Wed Jan 16 04:29:40 CET 2008

Yeah, but many small bits of string are hard to put together into a useful ball. :)
Platitude (I think is the word): Finding the right balance can be difficult, and it is neither one extreme nor the other.
I don't like having to search so many different directories and files, I like more stuff readily at hand.
And layering so many things together..do-cm3-std calls do-pkg calls syinfo calls cm3 can also be confusing, at least at first, but once known, I guess not, whereas smushed together code can remain confusing to maintain longer term.
I'm the odd one out here though.
I'd rather the current liberal BSD-ish licenses.

I think multithreading would be good.

I'm leary of what functionality is in cm3 vs. above.
I think more should be in it.
I actually like a model where you cd around and run some command it builds from the current directory and on down.
But possibly escaping that part of the tree to rebuild dependencies, if they are out of date.

Currently we have two choices:
  cd around to specific packages and run cmd 
  cd to the specific scripts directory and do-pkg a specific list

Kind of not not ideal somehow.
Maybe all I really want is do-pkg to leave the cm3 command line options -- the local defines -- in its callers environment somehow for cm3 to pickup. So run do-pkg env and then cd around and run cm3.

Anyway, much more bugs me than is important and these things are by far not the most important.
I'd be happier merely to have quake provide move_file. :)
And for it to batch up compilation of C perhaps.
But then I get creedy and want to batch up cm3cg runs..back to where I was.. :)

So -- dynamic linking is where people draw the line, but not one process running another?
That seems dubious.

Debugging-wise, there is this issue of "entry points".
Where can I easily stop and resume?
You are referring to cm3 outputs .ic (I think it is) files and then cm3cg can be run over them, easily, independently, without starting the pipeline all the way back before Modula-3 parsing.
The entry points remain in the shipping product/configuration, even though they are "never" taken advantage of there..even if cm3 doesn't run cm3cg, the cost of mapping in a larger executable in a demand-paged environment is neglible, except as it pulls in dependencies on additional .dlls/.sos, though I expect (I will check), cm3cg's dependencies are light and a subset or equal to cm3's, so that's zero.

I don't have an answer here, debugging entry points vs. optimized runtime.
Debuggability and performance are very often open opposing forces (see the static_link thread :) )
Sometimes you can have the debug path as an option and the perf path by default, but of course, every fork, every if, (every conditional branch, conditional move (x86), predicated instruction (IA64) -- though I guess sometimes the conditions are the same) is another multiplication out of test cases and inevitably reduced coverage.

 - Jay

> CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] "crazy cross"> Date: Tue, 15 Jan 2008 18:51:44 -0500> To: jayk123 at hotmail.com> > > 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> 
_________________________________________________________________
Watch “Cause Effect,” a show about real people making a real difference.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080116/6082df14/attachment-0002.html>