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

[Jay]

Cool.


Makefile/mklib: recent change for amd64_nt. It worked there. I will look.
The intent was "a bunch of objs plus mklibmain, a bunch of objs plus cm3main". 
Ultimately, for packaging/distribution, this should probably be fleshed out 1 to build the entire system 2 to use dynamic linking. And maybe automake/autoconf/libtool or cmake.


arm-gcc: this is specific to arm or arm_darwin and was trying to cross compile. I did cross compile cm3 for arm_darwin. Generally there is a gcc with a name "like" this, but the exact name is very target specific.


Jmpbuf: edit m3-sys/m3middle/src/Target.m3 and update.py (overkill -- rebuild m3middle, cm3, and copy the cm3 to install it; cm3 is special and "ship" doesn't install it)

I'd like to eliminate knowing the jmpbuf size very soon.


 - Jay

On Oct 15, 2013, at 7:39 AM, <mika at async.caltech.edu> wrote:

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