[M3devel] M3 on Raspberry Pi cont'd...

[Jay K]

 > I found that CVS had mangled RTMachine.i3 


 Maybe you had edited it?  
 Maybe also I deleted it? In general we had way more than necessary 
 target-specific code and files and in general I have significantly reduced it. 
 CVS doesn't deal well with merge conflicts. It leaves merge markers in, and 
 isn't quick to remind of the need to merge. Perforce is vastly superior here. 
 


 > make: *** No rule to make target `c-family/c-pragma.h', needed by `arm.o'.  Stop 


 This is probably easy. 
 I removed the gcc C frontends from the gcc backends. 
 But its "tentacles" could be target-specific, and I didn't try building 
 every target. 


 >  C backend requires M3_FRONT_FLAGS 


 I *might* be sitting on a small config file change.  
   I'm trying to flush my CVS checkouts of any pending changes. 
 Either way, not a big deal.  
 The error actually is good, if you know what it is talking about.  


  While everyone sees just cm3 with very few command line options, interally  
  there are many options. If you look at the 3.6 era config files, you'll  
  start to get an idea. Or read through all of our config files -- we do  
  use two of the three options available here.  


  There are three orders the frontend (m3front) is wiling to output nested procedures,  
  presumably: 
   1 before the functions they are in 
   2 at the point they are seen in the source 
   3 after the functions they are in 


  There are advantages and disadvantages to each choice, and various backends  
  might require one choice or the other. The frontend is I believe fairly stateful  
  so it is easy to report things in different orders.   


  #2 requires the backend to maintain more state, since it can see a function  
  in the middle of a function. i.e. it has to merely push what it is working in
  when it sees begin_procedure, and pop when it sees end_procedure, instead of
  just maintaining a "current procedure".    


  I believe the gcc backend can handle any order.  


  Though I recall one/some of the orders introduce a psuedo call to the backend "note_procedure_origin"
  that the serializer between frontend and gcc errors on, deliberately. 



  The integrated backend is very simple and relatively stateless, so I think it   
  can't handle #2. Not that it is so difficult.  


  The C backend was originally very stateless, so also couldn't deal with #2. 
  IF nested functions aren't declared ahead of time -- I don't remember -- then 
  the original C backend required #3. 


  The C backend is now very stateful and I almost finished making it not care about the order here. 
  But I didn't finish that quite yet. 
  It maintains an in-memory array of records corresponding to the M3CG calls. 
  It loops over them multiple times. With an ability to easily filter certain operations. 
  I added the ability to loop over a range (i.e. begin_procedure to end_procedure),
  which should make this easy, but it doesn't work yet. 



 The ramification is very minor. 
 Look for M3_FRONT in the config files. 
 I thought I already handled it based on the backend mode. 
 For that matter, the "builder" could or C backend initialization could probably make it so. 


 Ideally this configuration knob would go away. One order picked that works and all backends
 deal with it. 



 As you mention, computers have gotten a lot faster since DEC SRC was designed/implemented. 
 This desire to not require backends to hold an entire "program" in memory is largely antiquated. 
 Mainstream commercial C and C++ compilers regularly do whole program codegen/optimization now and have been 
 doing so for over 10 years. 


 (our mklib.exe actually is in the way of using Visual C++'s whole program codegen..it reads .obj files..,
 but given our historical code quality being pretty poor anyway, and nobody noticing, I'm not too worried..) 



 > but after fixing that I get a boot archive!  Very exciting.  What do I do now? 


 One of two options: 

 1) Less usual: If you have a cross C compiler/linker, ignore the archive, cd into the directory 
 it was built from, edit the Makefile, make 
 I had built ARM_DARWIN this way, and the Makefile for that target assumes it, just the few
 lines at the top that set the C compiler name/flags. 


 2) Usual: If you don't have a cross C compiler/linker, and you do have a native C compiler/linker,  
  copy the boot archive (or the directory it is built from) to the target machine, extract it, cd into it, make,  
  possibly first editing the Makefile (you know, we don't use autoconf/automake, and a lot   
  of what we do is duplicating them..)  


 If that succeeds, you will have cm3. 
 On the new target machine:  
  Run it 
   If it says "can't find cm3.cfg", that is success so far. 
   If it doesn't say that, or crashes, debug it. 
  mkdir -p /usr/local/cm3/bin   
  cp cm3 /usr/local/cm3/bin  
  cd somewhere (again, on the new target machine) 
  cvs checkout 
  scripts/python/boot2.py that will build the entire system starting from just the cm3 (and a native C compiler/linker) 


 Document your experience better than I have and what needs to change. 


 > This machine is quite slow, maybe it would be nice to have a version of the front end
 > that generates C without comments? :)  (I'm not saying it should be the default.)


 Yeah..there are some globals controlling it. 
 It is a tough tradeoff performance vs. debuggability...granted, the comments are gibberish 
 to most people. But I like to have the debuggability... 



 Going through C is also noticably slower. That is a downside to the ease of development
  and portability it brings. 
 One thing I'd like to do is batch it up so we pass all the C files to the compiler at once. 
 At least the out of date ones. I know that is much faster with the Microsoft C compiler -- 
 I even changed the boot archive to work that way -- I think for all targets actually. 



 - Jay




> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: M3 on Raspberry Pi cont'd...
> Date: Mon, 14 Oct 2013 16:11:31 -0700
> From: mika at async.caltech.edu
> 
> 
> A bit of success... I found that CVS had mangled RTMachine.i3 (why??) and that was causing things to go very wrong.
> 
> I did manage to upgrade my compiler to the head.
> 
> ./boot1.py ARMEL_LINUX still leads to the tree error:
> 
> make: *** No rule to make target `c-family/c-pragma.h', needed by `arm.o'.  Stop.
> 
> ./boot1.py c ARMEL_LINUX results in a new problem:
> 
> ../src/runtime/common/RTAllocator.m3", line 14: internal_begin_procedure: in_proc; C backend requires M3_FRONT_FLAGS = ["-unfold_nested_procs"] in config file
> 
> but after fixing that I get a boot archive!  Very exciting.  What do I do now?  I'm trying to run everything through cc -O3 -c
> 
> This machine is quite slow, maybe it would be nice to have a version of the front end that generates C without comments? :)  (I'm not saying it should be the default.)
> 
>       Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131014/a410a378/attachment-0002.html>