[M3devel] package groups question

[Jay K]

That reminds me, darn it..
 
Yes I think the INTEGER/FLOAT things are ok now.
 I had hit problems in float and/or double bootstrapping where host and target differed in endian and fixed it. There were also 32bit/64bit problems there maybe, also now believed fixed.
 
 
And gcc used to be partly to blame for problems here, but has been fixed.
  I even suggested they rev the documented caveats about building for Alpha and I think they did.
 
I do bootstrap from host-generated .s files.
 
I understand you could bootstrap from .mc files instead.
  Maybe even textual ones?
  That you use as a distribution format?
  Advantages/disadvantages?
   Minor one is that you'd have to build m3cc without the small aid of cm3..not a big deal, just configure -disable-bootstrap -disable-multilibs && make and ignore all my little tweaks in the m3makefile.
   If not textual, mc files are less readable..but assembly is unreadable to most people anyway..
 
There are bugs here though.
 -  I left in the hack you didn't like in order to bootstrap from 32bit to 64bit, where TEXTs are limited to 4gig, rather than some much larger value on 64bit systems. The front end should be doing target math there not host math.
 
 - You can't bootstrap from 64bit to 32bit due to some similar small bug in the front end.
   Probably also a target math vs. host math thing.
 
 We already have the code to simulate target math, we just have to use it a little more.
 (This is what gcc now uses gmp/mpfr for presumably, like wrt constant propagation.)
 
 
 - Jay


________________________________
> From: hosking at cs.purdue.edu
> To: wagner at elegosoft.com
> Date: Fri, 31 Jul 2009 12:31:49 -0400
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] package groups question
>
> I think cross-compilation should always be the default approach, simply because it avoids all the version issues. We should be able to bootstrap from any host to any target. I know there have been deficiencies in the gcc-based cm3cg backend (for example when host and target INTEGER or FLOAT have different formats), but I think we are on the way to eliminating those. Bootstrapping from .mc files using a native cm3cg probably avoids that though, rather than bootstrapping from host-generated .s files. Jay, perhaps you have more to add?
>
> On 31 Jul 2009, at 12:27, Olaf Wagner wrote:
>
> I meant getting the first instance of cm3 5.1 run on a certain platform.
> And there was of course a first platform. We used the SRC compiler,
> the cm3 4.1 from Critical Mass, and the PM3 compiler on different
> platforms. Later we used cross-compilation almost exclusively.
>
> I assume that cross-compilation support has improved dramatically
> with all your changes.
>
> Olaf
>
> Quoting Jay K>:
>
>
> What does it mean to boot the compiler?
>
>
> I build the compiler from nothing but the compiler itself,
> and config files, and C compiler and linker, cvs
> to get all the source.
> That's not nothing, but it about the smallest start you can have,
> unless you rewrite the compiler in C, then you can start without
> the Modula-3 compiler. But at certain points in time this
> would not work, due to m3core and/or libm3 problems.
> It does work today.
>
>
> Is that booting?
>
>
> In future I'd like to dynamically link cm3, so I'd start with
> cm3, libm3.so, libm3core.so, etc. -- just cm3 and its "static dynamic"
> dependencies. Many other systems do dynamically link to this extent
> and we can to.
>
>
> I'm not just being obnoxious.
> Really, what does it mean?
>
>
> Should we just ship std and that's it?
> And even drop the name from it?
> cm3-PPC_LINUX-5.8.2.tar.gz ?
>
>
> (No need to say "POSIX", it is redundant).
> Just one download per platform?
> Not a big matrix of packages to test?
>
>
> Or do we look too fat in that packaging? :)
>
>
> Will too much stuff confuse users?
>
>
> Or mitigate the bulk with a little documentation/tutorial?
>
>
> Something like this:
>
> There are many libraries and packages.
> You do not need to worry about them.
> Here is hello world for a command line program:
> ...
> And for a gui program:
> ...
> And a minimal sample interoperating with C:
> ...
> And a minimal sample using Modula-3's RPC called "network objects":
> ...
>
> CM3 4.1 had some like this that were nice, presumably we have them.
>
> - Jay
>
>
>
>
> ----------------------------------------
> Date: Fri, 31 Jul 2009 11:20:48 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] package groups question
>
> On Fri, Jul 31, 2009 at 11:13:58AM -0400, hendrik at topoi.pooq.com wrote:
> On Fri, Jul 31, 2009 at 04:05:46PM +0200, Olaf Wagner wrote:
> Quoting Tony Hosking :
>
> I don't care if future versions are not compilable with old cm3. But,
> vice versa, old versions should always be compilable with new cm3.
>
> My gut feelings run along the lines of what Randy has said. I do
> think that the average user should accept std as the install, while
> min is for power-users who know what they are doing. Does that jive
> with other people's expectations?
>
> Sorry, I only now caught up with _some_ of the mails on the m3devel
> list. Too much traffic for me to digest.
>
> I gather there's been a long discussion that `min' is not really
> useful as it is not enough to build the system. When we started
> the cm3 5 business many years ago with lots of uncompilable sources
> from Farshad Nayeri, we invented the following sets of packages:
>
> all - obvious meaning. most packages did not compile at all.
> std - the set of packages shipped as compilable and usable with
> every new release
> core - a useful but small set of packages including everything to
> bootstrap the compiler
> boot - the minimal set to bootstrap the compiler
> min - the minimal set useful for anyone (not wanting to compiler cm3)
>
> As of today, std = all, and boot isn't used any more as far as a I see.
>
> Is that becaouse no one ever boots the compiler any more? Or because
> there are better ways to do it?
>
> -- hendrik
>
> I guess I should mention that ebian is perfectly happy if one source
> parckage (possibly the entire working cm3 system) generates multiple
> binary packages.
>
> -- hendrik
>
>
>
>
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>