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

[mika at async.caltech.edu]

Here are some notes on my experience so far.

-- After finally figuring out what was wrong with my compiler (no I
can't imagine I edited RTMachine, the two versions looked completely
incompatible besides), I was able to build the bootstrap .tgz

-- I had to add that flag we discussed yesterday -unfold_nested_procs

-- I rsynced it to the Pi and was able to compile cc -c *.o / run make

-- I had to edit the Makefile because it set cc to something other than
   cc, viz., arm-linux-gnueabi-gcc

-- the Makefile tries to build two executables in a slightly confused
   fashion: cm3 and mklib.  You get multiply defined labels for main that way.  
   Basically it has multiple targets but seems to smush them together in one big 
   mess somehow.  Easy to hack out.

-- Resulting cm3 links but segfaults immediately, I think it's because of the
   below:

raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# cc jmpbuf.c
raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# ./a.out
jmpbuf size: 392
sigjmpbuf size: 392
alignment: 8 8
raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# uname -a
Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux

Will edit stuff and re-run.

     Mika


Jay K writes:
>Mika=2C please double check this in your ARM machine:=0A=
>=0A=
>=0A=
>This is I386_DARWIN:=0A=
>jbook2:config jay$ cc jmpbuf.c=A0=0A=
>./a.out=0A=
>jbook2:config jay$ ./a.out=0A=
>jmpbuf size: 72=0A=
>sigjmpbuf size: 76=0A=
>alignment: 4 4=0A=
>jbook2:config jay$ pwd=0A=
>/Users/jay/dev2/cm3/scripts/config=0A=
>=0A=
>=0A=
>It looks like raspberry pi might use an ABI variant "ARMHF" HF for hard flo=
>at=2C=0A=
>and I wouldn't be surprised if it uses a larger jmpbuf than m3-sys/m3middle=
>/src/Target.m3 says.=0A=
>=0A=
>=0A=
>If so=2C I'd favor just growing the jmpbuf for ARMEL_LINUX and NOT introduc=
>ing ARMHF_LINUX or such.=0A=
>All the targets are almost identical=2C and we have so many=2C they mostly =
>confuse people.=0A=
>And this jmpbuf stuff will go away hopefully soon.=0A=
>=0A=
>=0A=
>=A0- Jay=0A=
>=0A=
>________________________________=0A=
>> From: jay.krell at cornell.edu =0A=
>> To: mika at async.caltech.edu =0A=
>> Date: Mon=2C 14 Oct 2013 23:55:44 +0000 =0A=
>> CC: m3devel at elegosoft.com =0A=
>> Subject: Re: [M3devel] M3 on Raspberry Pi cont'd... =0A=
>> =0A=
>>> I found that CVS had mangled RTMachine.i3 =0A=
>> =0A=
>> =0A=
>> Maybe you had edited it? =0A=
>> Maybe also I deleted it? In general we had way more than necessary =0A=
>> target-specific code and files and in general I have significantly =0A=
>> reduced it. =0A=
>> CVS doesn't deal well with merge conflicts. It leaves merge markers in=2C=
> and =0A=
>> isn't quick to remind of the need to merge. Perforce is vastly =0A=
>> superior here. =0A=
>> =0A=
>> =0A=
>> =0A=
>>> make: *** No rule to make target `c-family/c-pragma.h'=2C needed by =0A=
>> `arm.o'. Stop =0A=
>> =0A=
>> =0A=
>> This is probably easy. =0A=
>> I removed the gcc C frontends from the gcc backends. =0A=
>> But its "tentacles" could be target-specific=2C and I didn't try building=
> =0A=
>> every target. =0A=
>> =0A=
>> =0A=
>>> C backend requires M3_FRONT_FLAGS =0A=
>> =0A=
>> =0A=
>> I *might* be sitting on a small config file change. =0A=
>> I'm trying to flush my CVS checkouts of any pending changes. =0A=
>> Either way=2C not a big deal. =0A=
>> The error actually is good=2C if you know what it is talking about. =0A=
>> =0A=
>> =0A=
>> While everyone sees just cm3 with very few command line options=2C intera=
>lly =0A=
>> there are many options. If you look at the 3.6 era config files=2C you'll=
> =0A=
>> start to get an idea. Or read through all of our config files -- we do =
>=0A=
>> use two of the three options available here. =0A=
>> =0A=
>> =0A=
>> There are three orders the frontend (m3front) is wiling to output =0A=
>> nested procedures=2C =0A=
>> presumably: =0A=
>> 1 before the functions they are in =0A=
>> 2 at the point they are seen in the source =0A=
>> 3 after the functions they are in =0A=
>> =0A=
>> =0A=
>> There are advantages and disadvantages to each choice=2C and various back=
>ends =0A=
>> might require one choice or the other. The frontend is I believe =0A=
>> fairly stateful =0A=
>> so it is easy to report things in different orders. =0A=
>> =0A=
>> =0A=
>> #2 requires the backend to maintain more state=2C since it can see a func=
>tion =0A=
>> in the middle of a function. i.e. it has to merely push what it is =0A=
>> working in =0A=
>> when it sees begin_procedure=2C and pop when it sees end_procedure=2C =0A=
>> instead of =0A=
>> just maintaining a "current procedure". =0A=
>> =0A=
>> =0A=
>> I believe the gcc backend can handle any order. =0A=
>> =0A=
>> =0A=
>> Though I recall one/some of the orders introduce a psuedo call to the =0A=
>> backend "note_procedure_origin" =0A=
>> that the serializer between frontend and gcc errors on=2C deliberately. =
>=0A=
>> =0A=
>> =0A=
>> =0A=
>> The integrated backend is very simple and relatively stateless=2C so I =
>=0A=
>> think it =0A=
>> can't handle #2. Not that it is so difficult. =0A=
>> =0A=
>> =0A=
>> The C backend was originally very stateless=2C so also couldn't deal with=
> #2. =0A=
>> IF nested functions aren't declared ahead of time -- I don't remember =0A=
>> -- then =0A=
>> the original C backend required #3. =0A=
>> =0A=
>> =0A=
>> The C backend is now very stateful and I almost finished making it =0A=
>> not care about the order here. =0A=
>> But I didn't finish that quite yet. =0A=
>> It maintains an in-memory array of records corresponding to the M3CG call=
>s. =0A=
>> It loops over them multiple times. With an ability to easily filter =0A=
>> certain operations. =0A=
>> I added the ability to loop over a range (i.e. begin_procedure to =0A=
>> end_procedure)=2C =0A=
>> which should make this easy=2C but it doesn't work yet. =0A=
>> =0A=
>> =0A=
>> =0A=
>> The ramification is very minor. =0A=
>> Look for M3_FRONT in the config files. =0A=
>> I thought I already handled it based on the backend mode. =0A=
>> For that matter=2C the "builder" could or C backend initialization could =
>=0A=
>> probably make it so. =0A=
>> =0A=
>> =0A=
>> Ideally this configuration knob would go away. One order picked that =0A=
>> works and all backends =0A=
>> deal with it. =0A=
>> =0A=
>> =0A=
>> =0A=
>> As you mention=2C computers have gotten a lot faster since DEC SRC was =
>=0A=
>> designed/implemented. =0A=
>> This desire to not require backends to hold an entire "program" in =0A=
>> memory is largely antiquated. =0A=
>> Mainstream commercial C and C++ compilers regularly do whole program =0A=
>> codegen/optimization now and have been =0A=
>> doing so for over 10 years. =0A=
>> =0A=
>> =0A=
>> (our mklib.exe actually is in the way of using Visual C++'s whole =0A=
>> program codegen..it reads .obj files..=2C =0A=
>> but given our historical code quality being pretty poor anyway=2C and =0A=
>> nobody noticing=2C I'm not too worried..) =0A=
>> =0A=
>> =0A=
>> =0A=
>>> but after fixing that I get a boot archive! Very exciting. What do =0A=
>> I do now? =0A=
>> =0A=
>> =0A=
>> One of two options: =0A=
>> =0A=
>> 1) Less usual: If you have a cross C compiler/linker=2C ignore the =0A=
>> archive=2C cd into the directory =0A=
>> it was built from=2C edit the Makefile=2C make =0A=
>> I had built ARM_DARWIN this way=2C and the Makefile for that target =0A=
>> assumes it=2C just the few =0A=
>> lines at the top that set the C compiler name/flags. =0A=
>> =0A=
>> =0A=
>> 2) Usual: If you don't have a cross C compiler/linker=2C and you do have =
>=0A=
>> a native C compiler/linker=2C =0A=
>> copy the boot archive (or the directory it is built from) to the =0A=
>> target machine=2C extract it=2C cd into it=2C make=2C =0A=
>> possibly first editing the Makefile (you know=2C we don't use =0A=
>> autoconf/automake=2C and a lot =0A=
>> of what we do is duplicating them..) =0A=
>> =0A=
>> =0A=
>> If that succeeds=2C you will have cm3. =0A=
>> On the new target machine: =0A=
>> Run it =0A=
>> If it says "can't find cm3.cfg"=2C that is success so far. =0A=
>> If it doesn't say that=2C or crashes=2C debug it. =0A=
>> mkdir -p /usr/local/cm3/bin =0A=
>> cp cm3 /usr/local/cm3/bin =0A=
>> cd somewhere (again=2C on the new target machine) =0A=
>> cvs checkout =0A=
>> scripts/python/boot2.py that will build the entire system starting =0A=
>> from just the cm3 (and a native C compiler/linker) =0A=
>> =0A=
>> =0A=
>> Document your experience better than I have and what needs to change. =0A=
>> =0A=
>> =0A=
>>> This machine is quite slow=2C maybe it would be nice to have a version =
>=0A=
>> of the front end =0A=
>>> that generates C without comments? :) (I'm not saying it should be =0A=
>> the default.) =0A=
>> =0A=
>> =0A=
>> Yeah..there are some globals controlling it. =0A=
>> It is a tough tradeoff performance vs. debuggability...granted=2C the =0A=
>> comments are gibberish =0A=
>> to most people. But I like to have the debuggability... =0A=
>> =0A=
>> =0A=
>> =0A=
>> Going through C is also noticably slower. That is a downside to the =0A=
>> ease of development =0A=
>> and portability it brings. =0A=
>> One thing I'd like to do is batch it up so we pass all the C files to =0A=
>> the compiler at once. =0A=
>> At least the out of date ones. I know that is much faster with the =0A=
>> Microsoft C compiler -- =0A=
>> I even changed the boot archive to work that way -- I think for all =0A=
>> targets actually. =0A=
>> =0A=
>> =0A=
>> =0A=
>> - Jay =0A=
>> =0A=
>> =0A=
>> =0A=
>> =0A=
>>> To: jay.krell at cornell.edu =0A=
>>> CC: m3devel at elegosoft.com =0A=
>>> Subject: M3 on Raspberry Pi cont'd... =0A=
>>> Date: Mon=2C 14 Oct 2013 16:11:31 -0700 =0A=
>>> From: mika at async.caltech.edu =0A=
>>> =0A=
>>> =0A=
>>> A bit of success... I found that CVS had mangled RTMachine.i3 (why??) =
>=0A=
>> and that was causing things to go very wrong. =0A=
>>> =0A=
>>> I did manage to upgrade my compiler to the head. =0A=
>>> =0A=
>>> ./boot1.py ARMEL_LINUX still leads to the tree error: =0A=
>>> =0A=
>>> make: *** No rule to make target `c-family/c-pragma.h'=2C needed by =0A=
>> `arm.o'. Stop. =0A=
>>> =0A=
>>> ./boot1.py c ARMEL_LINUX results in a new problem: =0A=
>>> =0A=
>>> ../src/runtime/common/RTAllocator.m3"=2C line 14: =0A=
>> internal_begin_procedure: in_proc=3B C backend requires M3_FRONT_FLAGS =
>=3D =0A=
>> ["-unfold_nested_procs"] in config file =0A=
>>> =0A=
>>> but after fixing that I get a boot archive! Very exciting. What do I =0A=
>> do now? I'm trying to run everything through cc -O3 -c =0A=
>>> =0A=
>>> This machine is quite slow=2C maybe it would be nice to have a version =
>=0A=
>> of the front end that generates C without comments? :) (I'm not saying =
>=0A=
>> it should be the default.) =0A=
>>> =0A=
>>> Mika 		 	   		  =