[M3devel] Well, I'm impressed!

[Jay K]

 Cool. 


 > to upload an archive or something, to let other intrepid Raspber 


 scripts/make-dist.py ?
 And then you can scp the results to modula3.elegosoft.com/var/www/cm3/uploaded-archives. 


 Feel free to do that for whatever are your favorite systems, maybe switching
 them to the C backend as you go. :)


 > SYSTEM_CC and SYSTEM_AS are set up for cross building 

 
  Only for ARM. I thought only ARM_DARWIN.  
  I guess that wasn't ideal in retrospect. 
  Or rather, there is more work to do here, so we have
  a complete native and cross story with reasonable ease of use.  
  I am so tempted to throw out quake and the config files and just
  generate a little automake/autoconf/cmake input and let them
  deal with it.. 

 
 > MIPSEL_LINUX 


 Why is MIPS relevant? 
 I guess I didn't get far there, on my Loongson I replaced Debian with OpenBSD. 
 Anyway, with the C backend, it likely just works.


 Did you mean ARMEL_LINUX? And the pragma thing? I fixed that. 
 Problem is, when upgrading cm3cg, one I guess should build for every target, to catch this. 
 I guess I should do that. But this is hopefully going away. 
 I built some cm3cg backends last night..and hit OpenBSD missing in 4.7..


 > I'd say the hardest thing for me to figure out was actually how to upgrade


 Upgrade.py?


  The version sensitivity has always been there, it is just that we go long durations
  without changing things. But things are changable and do get changed. Tony added LONGINT 
  and the atomics. Good. And upgrade.py deals with that. 
  I modified the M3CG enum slightly. Upgrade.py deals with that. 


  It isn't a bunch of special cases, it is just a particular ordering. 
  We depend on a working system to give us cm3, m3core, and libm3. 
  That is all you need for a native upgrade. 


 One thing upgrade.py is touchy about is, that someone hit recently,
 is that I replaced upgrade.h's uname use with looking at what cm3's host is.
 But older cm3 doesn't report it. So he didn't use ugprade.py. 


  If you don't have native cm3, then you can cross build cm3. 


  You went through both of those paths. Good! 
  I'm hoping additional people can become comfortable with this, so more people 
  can work on it. 


  And maybe we need to restructure some. In particular, upgrade should not be so in-place. 
  make-dist.py does this better -- it builds a whole new system, but w/o changing the 
  existing one at all. At the end you can copy the new onto the old.  


  Realize upgrade.py was based on upgrade.sh, for better and worse. 
  I did miss that upgrade.sh built everything and not just cm3/m3core/libm3, so upgrade.py 
  doesn't build everything.  


 > Finally, SYSTEM_CC and SYSTEM_AS are set up for cross building in the
 > configs.  That leads to a ton more editing (as the settings propagate
 > to a few places).


 There is a version of cm3.cfg that reachs back into the CVS checkout.  
 I did that as a response to my often editing the wrong files. 
 But this also is hazardous sometimes wrt upgrade, sometimes these
 need to be separate. 


 - Jay


> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Well, I'm impressed!
> Date: Tue, 15 Oct 2013 15:49:49 -0700
> From: mika at async.caltech.edu
> 
> Jay,
> 
> Yes I am impressed!
> 
> raspberrypi:/big/home/mika/xxx# cat Hello.m3 
> MODULE Hello EXPORTS Main;
> IMPORT IO;
> 
> BEGIN
>   IO.Put("Hi!\n");
> END Hello.
> raspberrypi:/big/home/mika/xxx# cm3 
> --- building in ARMEL_LINUX ---
> 
> new source -> compiling Hello.m3
>  -> linking prog
> raspberrypi:/big/home/mika/xxx# ARMEL_LINUX/prog 
> Hi!
> raspberrypi:/big/home/mika/xxx# 
> 
> It's slow, that's for sure... not done rebuilding the compiler yet.
> 
> A few notes:
> 
> I'd say the hardest thing for me to figure out was actually how to upgrade
> the compiler on the AMD64 system.  When I tried to rebuild cm3 first,
> I got tons of errors.  When I tried to rebuild cm3cg first, I also got
> tons of errors!  What gives?  Well... you can do it by realizing that
> while upgrading cm3 makes a broken compiler, it's still good enough to
> run the bit of quake code needed to recompile cm3cg.
> 
> Or you can compile cm3cg, and keep it around, not install it, and
> then recompile cm3, and only at that point copy cm3cg into place.
> That works too.
> 
> Then recompile everything with the matching toolsets.
> 
> To be honest I wouldn't even have been able to guess a method to solve
> this problem without reading between the lines of your emails.  Totally
> non-obvious.
> 
> On the Raspberry, yes, you were right, the jmpbuf was wrong size.  I already
> fixed this in Target.m3 (committed to CVS).  I added some extra padding for
> good measure.  "49" looks too weird.  64 it is.
> 
> I had to update ARMEL_LINUX config file to have
> 
> M3_BACKEND_MODE="C"
> M3_FRONT_FLAGS += ["-unfold_nested_procs"]
> 
> I noticed things are VERY touchy with versioning at this point.
> Everything has to match closely (much more so than I'm used to with
> Modula-3) to bootstrap properly.
> 
> The fact that cm3cg/m3cc won't build right on MIPSEL_LINUX is a big
> hassle.  It's in pkginfo.txt.  Then it's in build2.sh.  Then it's in
> various other places.  It has to be removed from everywhere before
> rebuilding.
> 
> Finally, SYSTEM_CC and SYSTEM_AS are set up for cross building in the
> configs.  That leads to a ton more editing (as the settings propagate
> to a few places).
> 
> The system is slow but does seem to work.  It's not through building
> anything much yet, it looks like it will run for the rest of the day.
> 
> Thanks for some very good work, Jay.  This seems very promising, but of
> course I can't promise I won't be emailing m3devel a lot more soon.
> 
> Is there anything I can do, assuming all works well, to upload an
> archive or something, to let other intrepid Raspberry users skip most
> of the steps?
> 
>     Mika
> ~
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131015/f87d3425/attachment-0002.html>