<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'><pre style="line-height: 21.3px; white-space: normal; font-family: "Segoe UI", "Segoe UI Web Regular", "Segoe UI Symbol", "Helvetica Neue", "BBAlpha Sans", "S60 Sans", Arial, sans-serif; color: rgb(68, 68, 68); font-size: 15px; background-color: rgb(255, 255, 255);">>> But I'm still pretty sure the "=>" ("1=>"?) inserted by M3Header.Parse will<br style="line-height: 21.3px;">>> never find its way into any output.</pre><div><br></div>agreed.<div>Anyway, I'm almost done with my minor change here.</div><div><br></div><div> I'm leaning toward: </div><div><br></div><div><br></div><div> cm3 -trim-target-variation  </div><div>   will set Target.TrimTargetVariation   </div><div>   will also a quake variable CM3_TRIM_TARGET_VARIATION maybe </div><div>   quake function backend() will use quake variable to pass it on to cm3cg probably   </div><div>     Unless maybe builder code knows it is calling cm3cg and will it in options there </div><div>     i.e. don't intend to push this through llvm backends at this time. </div><div><br></div><div><span style="font-size: 12pt;">  Used by M3C to turn off line directives entirely (vs. just commenting them out as it is willing to do) </span></div><div>  Used by M3C to turn off a comment as what is TARGET  </div><div> </div><div><br></div><div> cm3cg -ftrim-target-variation </div><div>  used by dbxout.c and dwarf2out.c to omit current working directory  </div><div><br></div><div><br></div><div> It is a funny name and a funny behavior and of limited use. </div><div> The exercise is somewhat useful to see how to plumb options through. </div><div> Much target variation occurs, just that slightly unnecessary variation will not, </div><div> and then targets that are nearly the same, will be closer to the same. </div><div><br></div><div><br></div><div> In particular, it likely that there are approximately one-two ABI per architecture on Posix hosts, </div><div> therefore the Posix targets are all the same -- NetBSD, OpenBSD, Solaris, Darwin, Linux, FreeBSD. </div><div> Darwin will tend to vary because it assumes newer processors so favors SSE over x87. </div><div> But still for AMD64, probably the same. </div><div> Windows tends to have different ABIs so the IR is still the same, but the assembly is not. </div><div><br></div><div><br></div><div>  - Jay </div><div><br><br><div>> Date: Fri, 1 Jul 2016 13:24:48 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: wagner@elegosoft.com; jay.krell@cornell.edu<br>> Subject: Re: [M3devel] source paths to generics?<br>> CC: m3devel@elegosoft.com<br>> <br>> <br>> <br>> On 07/01/2016 10:17 AM, Olaf Wagner wrote:<br>> > On Fri, 01 Jul 2016 10:01:51 -0500<br>> > "Rodney M. Bates" <rodney_bates@lcwb.coop> wrote:<br>> ><br>> >> On 06/30/2016 11:11 AM, Jay K wrote:<br>> >>> I put in a bunch of calls to RTIO.PutText("I'm here 1"); RTIO.Flush(), RTIO.PutText("I'm here 2"); RTIO.Flush().<br>> >>><br>> >>> When I saw those I knew I missed it somehow and looked again.<br>> >>><br>> >>> I still don't see the strings in the output though.<br>> >>><br>> >>>    - Jay<br>> >>><br>> >>><br>> >><br>> >> The missing call to M3Front.ParseImports is at cm3/src/Builder.m3:2007.<br>> >> It's in my previous grep output, plain as day.<br>> >> I must have just missed it in all the noise.<br>> >><br>> >> But I'm still pretty sure the "=>" ("1=>"?) inserted by M3Header.Parse will<br>> >> never find its way into any output.<br>> ><br>> > I'm sure there's lots of old and obsolete code in the packages, as CM3<br>> > was built upon the DEC SRC compiler sources.<br>> ><br>> <br>> I didn't make this clear, but, with the newly discovered call, my<br>> disparaging remarks about M3Header.Parse, etc. are now refuted.<br>> <br>> > The principal programmer of the compiler and Reactor is easily found<br>> > via LinkedIn: https://www.linkedin.com/in/billkalsow<br>> ><br>> > I'm not sure if he is willing to answer questions about his work, but<br>> > if you run into a real problem, it might be worthwhile to try it.<br>> ><br>> > Olaf<br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel<br></div></div>                                    </div></body>
</html>