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

[Jay K]

Mika, please double check this in your ARM machine:


This is I386_DARWIN:
jbook2:config jay$ cc jmpbuf.c 
./a.out
jbook2:config jay$ ./a.out
jmpbuf size: 72
sigjmpbuf size: 76
alignment: 4 4
jbook2:config jay$ pwd
/Users/jay/dev2/cm3/scripts/config


It looks like raspberry pi might use an ABI variant "ARMHF" HF for hard float,
and I wouldn't be surprised if it uses a larger jmpbuf than m3-sys/m3middle/src/Target.m3 says.


If so, I'd favor just growing the jmpbuf for ARMEL_LINUX and NOT introducing ARMHF_LINUX or such.
All the targets are almost identical, and we have so many, they mostly confuse people.
And this jmpbuf stuff will go away hopefully soon.


 - Jay

________________________________
> From: jay.krell at cornell.edu 
> To: mika at async.caltech.edu 
> Date: Mon, 14 Oct 2013 23:55:44 +0000 
> CC: m3devel at elegosoft.com 
> Subject: Re: [M3devel] M3 on Raspberry Pi cont'd... 
> 
>> 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