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