[M3devel] source paths to generics?

[Jay K]

>> But I'm still pretty sure the "=>" ("1=>"?) inserted by M3Header.Parse will>> never find its way into any output.
agreed.Anyway, I'm almost done with my minor change here.
 I'm leaning toward: 

 cm3 -trim-target-variation     will set Target.TrimTargetVariation      will also a quake variable CM3_TRIM_TARGET_VARIATION maybe    quake function backend() will use quake variable to pass it on to cm3cg probably        Unless maybe builder code knows it is calling cm3cg and will it in options there      i.e. don't intend to push this through llvm backends at this time. 
  Used by M3C to turn off line directives entirely (vs. just commenting them out as it is willing to do)   Used by M3C to turn off a comment as what is TARGET   
 cm3cg -ftrim-target-variation   used by dbxout.c and dwarf2out.c to omit current working directory  

 It is a funny name and a funny behavior and of limited use.  The exercise is somewhat useful to see how to plumb options through.  Much target variation occurs, just that slightly unnecessary variation will not,  and then targets that are nearly the same, will be closer to the same. 

 In particular, it likely that there are approximately one-two ABI per architecture on Posix hosts,  therefore the Posix targets are all the same -- NetBSD, OpenBSD, Solaris, Darwin, Linux, FreeBSD.  Darwin will tend to vary because it assumes newer processors so favors SSE over x87.  But still for AMD64, probably the same.  Windows tends to have different ABIs so the IR is still the same, but the assembly is not. 

  - Jay 

> Date: Fri, 1 Jul 2016 13:24:48 -0500
> From: rodney_bates at lcwb.coop
> To: wagner at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] source paths to generics?
> CC: m3devel at elegosoft.com
> 
> 
> 
> On 07/01/2016 10:17 AM, Olaf Wagner wrote:
> > On Fri, 01 Jul 2016 10:01:51 -0500
> > "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:
> >
> >> On 06/30/2016 11:11 AM, Jay K wrote:
> >>> I put in a bunch of calls to RTIO.PutText("I'm here 1"); RTIO.Flush(), RTIO.PutText("I'm here 2"); RTIO.Flush().
> >>>
> >>> When I saw those I knew I missed it somehow and looked again.
> >>>
> >>> I still don't see the strings in the output though.
> >>>
> >>>    - Jay
> >>>
> >>>
> >>
> >> The missing call to M3Front.ParseImports is at cm3/src/Builder.m3:2007.
> >> It's in my previous grep output, plain as day.
> >> I must have just missed it in all the noise.
> >>
> >> But I'm still pretty sure the "=>" ("1=>"?) inserted by M3Header.Parse will
> >> never find its way into any output.
> >
> > I'm sure there's lots of old and obsolete code in the packages, as CM3
> > was built upon the DEC SRC compiler sources.
> >
> 
> I didn't make this clear, but, with the newly discovered call, my
> disparaging remarks about M3Header.Parse, etc. are now refuted.
> 
> > The principal programmer of the compiler and Reactor is easily found
> > via LinkedIn: https://www.linkedin.com/in/billkalsow
> >
> > I'm not sure if he is willing to answer questions about his work, but
> > if you run into a real problem, it might be worthwhile to try it.
> >
> > Olaf
> >
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20160701/56215590/attachment-0003.html>