[M3devel] building CM3 on a Raspberry Pi?

Jay K jay.krell at cornell.edu
Mon Oct 14 06:07:25 CEST 2013 

  Porting to new systems is pretty easy.  
  I had ARMEL_LINUX pretty far along.  
  I forgot how far.  
  I did have to add sort of support for 128bit integers in the gcc backend. Sort of.  
 

 > ../gcc-4.7/configure: not found 

 
  Make sure you cvs upd -dAP so you get new directories. 

 
  We should switch to the C backend though. It is just a one line change  
   in the config file. Look at the Darwin config files.  
  It is not experimental.  
  It has been essentially working for over a year (since September 2012) 
   and it is in very good shape now. 
  I have used it for a number of architectures and operating systems already, 
  like I think every Solaris architecture, Linux, Darwin, NT. 
  I'd like to see more people use it, and I'd like to drop the gcc backend entirely. 
  This is an important step in leaving Modula-3 very portable and easier to support. 
 

 - Jay

 
> To: m3devel at elegosoft.com
> Date: Sun, 13 Oct 2013 13:35:01 -0700
> From: mika at async.caltech.edu
> Subject: [M3devel] building CM3 on a Raspberry Pi?
> 
> 
> Hi everyone (mostly Jay),
> 
> Last time I tried to port CM3 to a new architecture I really got nowhere.
> 
> I thought it might be time to try again.  I have a Raspberry Pi, forty-dollar computer.
> 
> It has "Raspbian" installed on it.
> 
> The following output is probably relevant:
> 
> pi at raspberrypi ~ $ uname -a
> Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux
> 
> pi at raspberrypi ~ $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
> Target: arm-linux-gnueabihf
> Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
> Thread model: posix
> gcc version 4.6.3 (Debian 4.6.3-14+rpi1) 
> 
> 
> Further, in the CM3 tree there is something called "ARMEL_LINUX".
> I thought, from reading some old messages on this mailing list, that doing
> the following on my "big" system would result in something interesting:
> 
> 1. CVS updating to the latest version of the tree
> 
> 2. cd to scripts/python
> 
> 3. ./boot1.py ARMEL_LINUX
> 
> but all it did was mess up the cm3.cfg on my host system (FreeBSD4) and error out very quickly...
> 
> ...
> rm -f /usr/local/cm3/bin/IA64_LINUX
> rm -f /usr/local/cm3/bin/NT.common
> rm -f /usr/local/cm3/bin/SPARC32_SOLARIS.common
> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/cm3.cfg
> == package /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs ==
> 
>  +++ /usr/local/cm3/bin/cm3    -build -override -DROOT=/big/home2/mika/2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++
> --- building in ARMEL_LINUX ---
> 
>  ==> /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs done
> 
> == package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc ==
> 
>  +++ /usr/local/cm3/bin/cm3    -build -override -DROOT=/big/home2/mika/2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++
> --- building in ARMEL_LINUX ---
> 
> type make
> make is /home/mika/cm3-build-bin//make
> make --version | grep "GNU Make"
> GNU Make 3.82
> GNU_MAKE is make
> cd ../FreeBSD4-ARMEL_LINUX &&   MAKE="make -j4  "  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure     -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls
> cd ../FreeBSD4-ARMEL_LINUX &&   MAKE="make -j4  "  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure     -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls
> ../gcc-4.7/configure: not found
> "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 127: cd ../FreeBSD4-ARMEL_LINUX &&   MAKE="make -j4  "  AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure     -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls
> 
> --procedure--  -line-  -file---
> exec               --  <builtin>
> m3cc_Run          339  /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile
> include_dir       537  /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile
>                     9  /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args
> 
> Fatal Error: package build failed
>  *** execution of [<function _BuildLocalFunction at 0x82d55a4>] failed ***
> (238)rover:~/cm3-cvs-anon/cm3/scripts/python>
> 
> 
> So I'm not really sure what state porting of CM3 is in.  I think it
> would be really interesting to have it running on the Raspberry Pi,
> partly because Modula-3 and Python are in many ways similar but Modula-3
> code tends to be many times more efficient (at least in runtime) and
> the computer is slow by modern standards.
> 
> A few questions...
> 
> Is ARMEL_LINUX a real port?  Does it work?  Has it worked for anyone?  
> 
> Am I going about it the right way per latest recommendations---that is,
> trying to cross-compile from an existing CM3 installation on 32-bit
> i386 system?
> 
> Clearly just running ./boot1.py ARMEL_LINUX on the FreeBSD system is
> not the right approach... maybe someone knows what is?
> 
> Do I maybe need to upgrade the host CM3 to the head first?  (Sounds
> like a whole other can of worms but ok...)
> 
> The Pi I think is more than powerful enough to compile everything
> natively.  When I started with Modula-3, I had a 120-MHz Pentium on
> my desk with 128 MB of RAM, and that was considered a powerful
> system at the time.  This is a 700 MHz ARM with 512 MB of RAM.
> So I'm not against compiling stuff natively (in fact I think it makes
> things easier), but cross-compiling is fine too if that gets me to
> the goal easier.
> 
> I am happy to try C generating compilers but I would prefer to keep
> things as un-experimental as possible for now, because I have some
> control applications I'd like to try to build without having to debug
> lots and lots of software first.
> 
> Finally I think it would be *really* cool if we had a distribution of
> Modula-3 that was polished enough to be distributable to Raspberry Pi
> users.  Just based on the gross characteristics of the two systems,
> I think the Pi and Modula-3 ought to be a very good match for each
> other.  Basically, the Pi is a full-featured but slow hardware system
> with good networking facilities.  It could use a safe, modern, efficient
> systems programming language running on it.  Most things on it nowadays
> are written in Python from what i understand.
> 
>      Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20131014/88a90d04/attachment-0002.html>

More information about the M3devel mailing list