[M3devel] package groups question

Sat Aug 1 04:24:49 CEST 2009

Good to hear that you think the numeric format errors have been  
stamped out.  Not so good to hear that we don't fully support host/ 
target distinctions in the front-end.

Text .mc would need conversion to binary .mc for cm3cg to parse.

On 31 Jul 2009, at 12:43, Jay K wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090731/c05eec21/attachment-0001.html>